[lsd0001] branch master updated: misc edits on security considerations

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new dfc4d3f  misc edits on security considerations
dfc4d3f is described below

commit dfc4d3f3c9e2bd17dd8fe38c4b10aaea45d5dab1
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Feb 3 18:00:06 2022 +0100

    misc edits on security considerations
---
 draft-schanzen-gns.xml | 128 ++++++++++++++++++++++++++++---------------------
 1 file changed, 73 insertions(+), 55 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 98e540f..70c6209 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -2132,8 +2132,26 @@ NICK: john (Supplemental)
      </section>
      <section anchor="security" numbered="true" toc="default">
        <name>Security and Privacy Considerations</name>
-       <section anchor="security_crypto" numbered="true" toc="default">
-         <name>Cryptography</name>
+       <section anchor="security_availability" numbered="true" toc="default">
+         <name>Availability</name>
+         <t>
+           In order to ensure availability of records beyond their
+           absolute expiration times, implementations MAY allow to locally
+           define relative expiration time values of records.
+           Records can then be published recurringly with updated
+           absolute expiration times by the implementation.
+         </t>
+         <t>
+           Implementations MAY allow users to manage private records in
+           their zones.
+           Such private records should not be published in the storage,
+           making their data completely unavailable to non-local users.
+           Private records should still be considered just like
+           regular records when resolving labels in local zones.
+         </t>
+       </section>
+       <section anchor="security_agility" numbered="true" toc="default">
+         <name>Agility</name>
          <t>
            The security of cryptographic systems depends on both the strength 
of
            the cryptographic algorithms chosen and the strength of the keys 
used
@@ -2141,11 +2159,11 @@ NICK: john (Supplemental)
            of the protocol used by the system to ensure that there are no
            non-cryptographic ways to bypass the security of the overall system.
            This is why developers of applications managing GNS zones SHOULD
-           select a default zone type considered secure at the time of
+           select a default ztype considered secure at the time of
            releasing the software.
            For applications targeting end users that are not expected to
            understand cryptography, the application developer MUST NOT leave
-           the zone type selection of new zones to end users.
+           the ztype selection of new zones to end users.
          </t>
          <t>
            This document concerns itself with the selection of cryptographic
@@ -2154,10 +2172,26 @@ NICK: john (Supplemental)
            broken (in the cryptographic sense) at the current time, and
            cryptographic research so far leads us to believe that they are
            likely to remain secure into the foreseeable future.  However, this
-           isn't necessarily forever, and it is expected that new revisions of
+           is not necessarily forever, and it is expected that new revisions of
            this document will be issued from time to time to reflect the 
current
            best practices in this area.
          </t>
+         <t>
+           In terms of crypto-agility, whenever the need for an updated 
cryptographic
+           scheme arises to, for example, replace ECDSA over Curve25519 for
+           PKEY records it may simply be introduced
+           through a new record type. Such a new record type may then replace
+           the delegation record type for future records.
+           The old record type remains
+           and zones can iteratively migrate to the updated zone keys.
+           To ensure that implementations correctly generate an error message
+           when encountering a ztype that they do not support,
+           current and future delegation records must always have the
+           CRITICAL flag set.
+         </t>
+       </section>
+       <section anchor="security_cryptography" numbered="true" toc="default">
+         <name>Cryptography</name>
          <t>
            GNS PKEY zone keys use ECDSA over Curve25519.
            This is an unconventional choice,
@@ -2171,34 +2205,28 @@ NICK: john (Supplemental)
            ECDSA.  GNS uses 256-bit curves because that way the encoded 
(public)
            keys fit into a single DNS label, which is good for usability.
          </t>
-         <t>
-           In terms of crypto-agility, whenever the need for an updated 
cryptographic
-           scheme arises to, for example, replace ECDSA over Curve25519 for
-           PKEY records it may simply be introduced
-           through a new record type. Such a new record type may then replace
-           the delegation record type for future records.
-           The old record type remains
-           and zones can iteratively migrate to the updated zone keys.
-         </t>
          <t>
            In order to ensure ciphertext indistinguishability, care must be
            taken with respect to the initialization vector in the counter
            block. In our design, the IV is always the expiration time of the
            record block.
-           For blocks with relative expiration times it is implicitly
-           ensured that each time a block is published into the storage, its 
IV is
+           When applications store records with relative expiration times,
+           monotonicity is implicitly
+           ensured because each time a block is published into the storage, 
its IV is
            unique as the expiration time is calculated dynamically and 
increases
-           monotonically.
-           The implementation MUST ensure that when relative expiration times
-           are decreased that the expiration time of the next record block is
-           always after the last published block.
-           For blocks with absolute expiration times, the implementation
-           MUST ensure that the expiration time is increased when the record
-           data changes. For example, the expiration time may be increased
-           by a single microsecond.
+           monotonically with the system time. Still,
+           an implementation MUST ensure that when relative expiration times
+           are decreased, the expiration time of the next record block MUST
+           be after the last published block.
+           For records where an absolute expiration time is used, the 
implementation
+           MUST ensure that the expiration time is always increased when the 
record
+           data changes. For example, the expiration time on the wire may be 
increased
+           by a single microsecond even if the user did not request a change.
            In case of deletion of all resource records under a label, the
            implementation MUST keep track of the last absolute expiration time
-           of the last published resource block.
+           of the last published resource block.  Implementations MAY use a 
PADDING
+           record as a tombstone that preserves the last absolute expiration 
time,
+           but then MUST take care to not publish a block with just a PADDING 
record.
            When new records are added under this label later, the 
implementation
            MUST ensure that the expiration times are after the last published
            block.
@@ -2232,9 +2260,9 @@ NICK: john (Supplemental)
          <name>Zone Management</name>
          <t>
            In GNS, zone administrators need to manage and protect their zone
-           keys. Once a zone key is lost it cannot be recovered. Once it is
-           compromised it cannot be revoked (unless a revocation message was
-           pre-calculated and is still available).
+           keys. Once a zone key is lost, it cannot be recovered or revoked.
+           Revocation messages may be pre-calculated if revocation is
+           required in case a zone key is lost.
            Zone administrators, and for GNS this includes end-users, are
            required to responsibly and diligently protect their cryptographic
            keys.
@@ -2262,42 +2290,29 @@ NICK: john (Supplemental)
            namespace for a particular name, but the implementation is not
            communicating with the storage and is hence unable to resolve it.
            This situation is similar to a split-horizon DNS configuration.
-           Which storages are implemented usually depend on the application
+           Which storages are implemented usually depends on the application
            it is built for.
            The storage used will most likely depend on the specific application
            context using GNS resolution.
            For example, one application may be the resolution of hidden 
services
-           within the Tor network.
+           within the Tor network, which may suggest using Tor routers for 
storage.
+           <!-- FIXME: add non-normative reference to Tor / Tor hidden 
services here? -->
            Implementations of "aggregated" storages are conceivable, but
            are expected to be the exception.
          </t>
-         <t>
-           In order to ensure availability of records beyond their
-           absolute expiration times, implementations MAY allow to locally
-           define relative expiration time values of records.
-           Records can then be published recurringly with updated
-           absolute expiration times by the implementation.
-         </t>
-         <t>
-           Implementations MAY allow users to manage private records in
-           their zones.
-           Such private records should not be published in the storage.
-           Private records should still be considered just like
-           regular records when resolving labels in local zones.
-         </t>
        </section>
        <section anchor="security_dht" numbered="true" toc="default">
          <name>Impact of DHTs as Underlying Storage</name>
          <t>
            This document does not specify the properties of the underlying
            storage which is required by any GNS implementation.
-           For implementers using a DHT as underlying storage, it is important
-           to note that the properties of the DHT are directly inherited by the
+           It is important to note that the properties of the underlying
+           storage are directly inherited by the
            GNS implementation. This includes both security as well as
            other non-functional properties such as scalability and performance.
            Implementers should take great care when selecting or implementing
-           a DHT for use in a GNS implementation.
-           DHTs with strong security and performance guarantees exist
+           a DHT for use as storage in a GNS implementation.
+           DHTs with reasonable security and performance properties exist
            <xref target="R5N"/>.
            It should also be taken into consideration that GNS implementations
            which build upon different DHT overlays are unlikely to be
@@ -2308,18 +2323,19 @@ NICK: john (Supplemental)
          <name>Revocations</name>
          <t>
            Zone administrators are advised to pre-generate zone revocations
-           and securely store the revocation information in case the zone
+           and to securely store the revocation information in case the zone
            key is lost, compromised or replaced in the future.
            Pre-calculated revocations may become invalid due to expirations
            or protocol changes such as epoch adjustments.
-           Consequently, implementers and users must make precautions in order
+           Consequently, implementers and users must take precautions in order
            to manage revocations accordingly.
          </t>
          <t>
            Revocation payloads do NOT include a 'new' key for key replacement.
            Inclusion of such a key would have two major disadvantages:
          </t>
-         <t>
+         <ol>
+           <li>
            If revocation is used after a private key was compromised,
            allowing key replacement would be dangerous: if an
            adversary took over the private key, the adversary could then
@@ -2327,8 +2343,8 @@ NICK: john (Supplemental)
            the compromised owner would have no chance to issue even a
            revocation. Thus, allowing a revocation message to replace a private
            key makes dealing with key compromise situations worse.
-         </t>
-         <t>
+           </li>
+           <li>
            Sometimes, key revocations are used with the objective of changing
            cryptosystems. Migration to another cryptosystem by replacing keys
            via a revocation message would only be secure as long as both
@@ -2338,7 +2354,8 @@ NICK: john (Supplemental)
            migration would conclude by revoking the legacy zone key only once
            it is deemed no longer secure, and hopefully after most users have
            migrated to the replacement.
-         </t>
+           </li>
+         </ol>
        </section>
        <section anchor="privacy_labels" numbered="true" toc="default">
          <name>Label Guessing</name>
@@ -2361,7 +2378,8 @@ NICK: john (Supplemental)
            It should be noted that this attack on labels only applies if the
            zone key is somehow disclosed to the adversary. GNS itself
            does not disclose it during a lookup or when resource records are
-           published as the zone keys are blinded beforehand.
+           published as the zone keys are blinded beforehand.  However,
+           zone keys do become public during revocation.
          </t>
        </section>
      </section>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.