[lsd0001] branch master updated: updates

[gnunet]

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

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 5094f69  updates
5094f69 is described below

commit 5094f697b9d47e6a40525f14f4e542df67e1888d
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Dec 21 20:33:35 2021 +0100

    updates
---
 draft-schanzen-gns.xml | 70 +++++++++++++++++++++++++++++++++-----------------
 1 file changed, 46 insertions(+), 24 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 641894b..49851ab 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -876,14 +876,6 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        <t>The Counter Block Initialization Vector</t>
 
      </section>
-   </section>
-     <section anchor="gnsrecords_other" numbered="true" toc="default">
-       <name>Auxiliary Records</name>
-       <t>
-         This section defines the initial set of auxiliary GNS record types. 
Any
-         implementation MUST be able to process the specified record types
-         according to <xref target="record_processing"/>.
-       </t>
        <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
        <name>GNS2DNS</name>
        <t>It is possible to delegate a label back into DNS through a GNS2DNS 
record.
@@ -924,12 +916,29 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        </dl>
      </section>
 
+
+   </section>
+     <section anchor="gnsrecords_other" numbered="true" toc="default">
+       <name>Auxiliary Records</name>
+       <t>
+         This section defines the initial set of auxiliary GNS record types. 
Any
+         implementation MUST be able to process the specified record types
+         according to <xref target="record_processing"/>.
+       </t>
      <section anchor="gnsrecords_leho" numbered="true" toc="default">
        <name>LEHO</name>
-       <t>Legacy hostname records can be used by applications that are expected
-         to supply a DNS name at the application layer. The most common use 
case
-         is HTTP virtual hosting, which as-is would not work with GNS names as
-         those may not be globally unique.
+       <t>
+         Applications can use the GNS to lookup IPv4 or IPv6 addresses of
+         internet services.
+         However, sometimes connecting to such services does not only require
+         the knowledge of an address and port, but also requires the canonical
+         DNS name of the service to be transmitted over the transport protocol.
+         In GNS, legacy hostname records provide applications the DNS name that
+         is required to establish a connection to such a service.
+         The most common use case is HTTP virtual hosting, where a DNS name 
must
+         be supplied in the HTTP "Host"-header.
+         Using a GNS name for the "Host"-header may not work as
+         it may not be globally unique.
 
          A LEHO resource record is expected to be found together in a single
          resource record with an IPv4 or IPv6 address.
@@ -1045,17 +1054,17 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        </dl>
      </section>
      <section anchor="gnsrecords_vpn" numbered="true" toc="default">
-       <name>VPN</name>
+       <name>GTS</name>
        <t>
-         The GNUnet Virtual Public Network <xref target="GNUnet"/> can
+         The GNUnet Tunnel Record <xref target="GNUnet"/> can
          establish a tunnel between two peers in the peer-to-peer network.
          In order to facilitate the use of such tunnels, the
-         VPN record allows resolvers to automatically initiate its 
establishment
+         GTS record allows resolvers to automatically initiate its 
establishment
          and provide IP address information in the resolution process as
          specified in <xref target="resolution"/>.
        </t>
        <t>
-           A VPN DATA entry wire format is illustrated in 
+           A GTS DATA entry wire format is illustrated in 
          <xref target="figure_vpnrecord"/>.
        </t>
        <figure anchor="figure_vpnrecord">
@@ -1075,7 +1084,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
 +-----+-----+-----+-----+-----+-----+-----+-----+
            ]]></artwork>
        </figure>
-       <t>The VPN DATA Wire Format.</t>
+       <t>The GTS DATA Wire Format.</t>
        <dl>
          <dt>HOSTING PEER PUBLIC KEY</dt>
          <dd>
@@ -1321,7 +1330,14 @@ q := SHA512 (HDKD-Public(zk, label))
          In order to revoke a zone key, a signed revocation object MUST be
          published.
          This object MUST be signed using the private zone key.
-         The revocation object is flooded in the overlay network. To prevent
+         The revocation object is broadcast to the network.
+         The specification of the broadcast mechanism is out of scope of this
+         document.
+         A possible broadcast mechanism for efficient flooding in a distributed
+         network is implemented in <xref target="GNUnet"/>.
+         Alternatively, revocation objects could also be distributed via a
+         distributed ledger or a trusted central server.
+         To prevent
          flooding attacks, the revocation message MUST contain a proof of work
          (PoW).
          The revocation message including the PoW MAY be calculated
@@ -1568,7 +1584,7 @@ q := SHA512 (HDKD-Public(zk, label))
        When GNS name resolution is requested, a desired record type MAY be
        provided by the client.
        The GNS resolver will use the desired record type to guide
-       processing, for example by providing conversion of VPN records to A
+       processing, for example by providing conversion of GTS records to A
        or AAAA records, if that is desired.
 
        However, filtering of record sets according to the required record
@@ -1845,16 +1861,16 @@ example.com = zk2
            </t>
          </section>
          <section anchor="vpn_processing" numbered="true" toc="default">
-           <name>VPN</name>
+           <name>GTS</name>
            <t>
        At the end of the recursion,
              if the queried record type is either A or AAAA and the retrieved
-             record set contains at least one VPN record, the resolver SHOULD
+             record set contains at least one GTS record, the resolver SHOULD
              open a tunnel and return the IPv4 or IPv6 tunnel address,
              respectively.
-             The type of tunnel depends on the contents of the VPN record data.
+             The type of tunnel depends on the contents of the GTS record data.
              If the implementation does not have the capacity to establish
-             a VPN tunnel, for example because it is not connected to the 
GNUnet
+             a GTS tunnel, for example because it is not connected to the 
GNUnet
              network, the record set MUST be returned as retrieved from the 
network.
            </t>
          </section>
@@ -1927,6 +1943,12 @@ NICK: john (Supplemental)
            with those algorithms.  The security also depends on the engineering
            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
+           releasing the software.
+           For applications targetting 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.
          </t>
          <t>
            This document concerns itself with the selection of cryptographic
@@ -2126,7 +2148,7 @@ Number | Name    | Contact | References | Description
 65536  | PKEY    | N/A     | [This.I-D] | GNS zone delegation (PKEY)
 65537  | NICK    | N/A     | [This.I-D] | GNS zone nickname
 65538  | LEHO    | N/A     | [This.I-D] | GNS legacy hostname
-65539  | VPN     | N/A     | [This.I-D] | VPN resolution
+65539  | GTS     | N/A     | [This.I-D] | GTS resolution
 65540  | GNS2DNS | N/A     | [This.I-D] | Delegation to DNS
 65556  | EDKEY   | N/A     | [This.I-D] | GNS zone delegation (EDKEY)
 

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