[lsd0001] branch master updated: small extensions, corrections

[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 b8a84e6  small extensions, corrections
b8a84e6 is described below

commit b8a84e657221e877c3071bf69ff6d0c73c6d40ad
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun May 17 23:20:52 2020 +0200

    small extensions, corrections
---
 draft-schanzen-gns.xml | 32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a9a9689..12f111e 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1450,6 +1450,18 @@ example.com = zk2
            this document will be issued from time to time to reflect the 
current
            best practices in this area.
          </t>
+         <t>
+           GNS uses ECDSA over Curve25519. This is an unconventional choice,
+           as ECDSA is usually used with other curves.  However, traditional
+           ECDSA curves are problematic for a range of reasons described in
+           the Curve25519 and EdDSA papers.  Using EdDSA directly is also
+           not possible, as a hash function is used on the private key which
+           destroys the linearity that the GNU Name System depends upon.
+           We are not aware of anyone suggesting that using Curve25519 instead
+           of another common curve of similar size would lower the security of
+           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>
        </section>
        <section anchor="security_abuse" numbered="true" toc="default">
          <name>Abuse mitigation</name>
@@ -1468,6 +1480,7 @@ example.com = zk2
            However, the same mechanisms can also be abused in order to impose
            state censorship, which ist one of the motivations behind GNS.
            Hence, such a seizure is, by design, difficult to impossible in GNS.
+           In particular, GNS does not support WHOIS (<xref target="RFC3912" 
/>).
          </t>
        </section>
        <section anchor="security_keymanagement" numbered="true" toc="default">
@@ -1475,11 +1488,13 @@ example.com = zk2
          <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 was
+           compromised it cannot be revoked (unless a revocation message was
            pre-calculated and is still available).
            Zone administrators, and for GNS this includes end-users, are
            required to responsibly and dilligently protect their cryptographic
-           keys.
+           keys.  Offline signing is in principle possible, but GNS does not
+           support separate zone signing and key-signing keys
+           (as in <xref target="RFC6781" />) in order to provide usable 
security.
          </t>
          <t>
            Similarly, users are required to manage their local root zone.
@@ -1519,16 +1534,16 @@ example.com = zk2
            key is lost, compromised or replaced in the furture.
            Pre-calculated revocations may become invalid due to expirations
            or protocol changes such as epoch adjustments.
-           Conseuquently, implementors and users must make precautions in order
+           Consequently, implementors and users must make precautions in order
            to manage revocations accordingly.
          </t>
          <t>
            Revocation payloads do NOT include a 'new' key for key replacement.
-           In inclusion of such a key would have two major disadvantages:
+           Inclusion of such a key would have two major disadvantages:
          </t>
          <t>
            If revocation is used after a private key was compromised,
-           allowing key replacement would be dangerous, because if an
+           allowing key replacement would be dangerous: if an
            adversary took over the private key, the adversary could then
            broadcast a revocation with a key replacement. For the replacement,
            the compromised owner would have no chance to issue even a
@@ -1552,7 +1567,7 @@ example.com = zk2
        <name>GANA Considerations</name>
        <t>
          GANA is requested to create an "GNU Name System Record Types" 
registry.
-The registry shall record for each entry:
+         The registry shall record for each entry:
        </t>
        <ul>
          <li>Name: The name of the record type (case-insensitive ASCII
@@ -1581,11 +1596,10 @@ Number | Name    | Contact | References | Description
 65540  | GNS2DNS | N/A     | [This.I-D] | Delegation to DNS
 65541  | BOX     | N/A     | [This.I-D] | Boxed record
            ]]></artwork>
-         <!--        <postamble>which is a very simple example.</postamble>-->
        </figure>
 
      </section>
-     <!-- iana -->
+     <!-- gana -->
      <section>
        <name>Test Vectors</name>
        <t>
@@ -1677,9 +1691,11 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
        &RFC2119;
        &RFC3629;
        &RFC3826;
+       &RFC3912;
        &RFC5869;
        &RFC5890;
        &RFC5891;
+       &RFC6781;
        &RFC6895;
        &RFC6979;
        &RFC7748;

-- 
To stop receiving notification emails like this one, please contact
address@hidden.