commit 51d627798b6442abc52a447c3f58b8b992813753
parent 851c23ca418972d8efcea52fdd56764debbee99b
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 7 Dec 2023 15:05:57 +0100
add draft
Diffstat:
| A | draft-nadler-sbox.xml | | | 420 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 420 insertions(+), 0 deletions(-)
diff --git a/draft-nadler-sbox.xml b/draft-nadler-sbox.xml
@@ -0,0 +1,420 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE rfc [
+ <!ENTITY nbsp " ">
+ <!ENTITY zwsp "​">
+ <!ENTITY nbhy "‑">
+ <!ENTITY wj "⁠">
+]>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
+ category="info"
+ docName="draft-schanzen-gns-28"
+ ipr="trust200902"
+ obsoletes=""
+ updates=""
+ sortRefs="false"
+ submissionType="independent"
+ symRefs="true"
+ tocDepth="3"
+ tocInclude="true"
+ xml:lang="en"
+ version="3">
+
+ <!-- xml2rfc v2v3 conversion 2.26.0 -->
+ <front>
+ <title abbrev="The GNS SBOX Record Type">The GNS SBOX Record Type</title>
+ <seriesInfo name="LSD" value="0001" />
+ <author fullname="Sebastian Nadler" initials="S." surname="Nadler">
+ <organization>Technische Universität München</organization>
+ <address>
+ <email>sebastian.nadler@tum.de</email>
+ </address>
+ </author>
+ <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
+ <organization>Fraunhofer AISEC</organization>
+ <address>
+ <postal>
+ <street>Lichtenbergstrasse 11</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>martin.schanzenbach@aisec.fraunhofer.de</email>
+ </address>
+ </author>
+ <date month="December" year="2023" />
+ <workgroup>GNUnet</workgroup>
+ <keyword>name systems</keyword>
+
+ <abstract>
+ <t> This document provides an extension to the GNU Name System (GNS) technical specification <xref
+ target="RFC9498" />. GNS is a decentralized and censorship-resistant domain name
+ resolution protocol that provides a privacy-enhancing alternative to the Domain Name System
+ (DNS) protocols. </t>
+ <t>
+ This document defines the normative wire format of an additional resource record
+ and a modifyed resolution processes for use by implementers.
+ </t>
+ <t>
+ This specification was developed outside the IETF and does not have
+ IETF consensus. It is published here to inform readers about the
+ function of GNS, guide future GNS implementations, and ensure
+ interoperability among implementations (for example, pre-existing
+ GNUnet implementations).
+ </t>
+ <!--<t>
+ Additionally, this is the continued-maintenance version of RFC 9498 which
+ is being updated as the work progresses: The Living Standards Document 0010 (LSD0010).
+ </t>-->
+ </abstract>
+ </front>
+ <middle>
+ <section anchor="introduction">
+ <name>Introduction</name>
+ <t> This specification describes additions to the GNU Name System (GNS) <xref target="RFC9498" />,
+ a censorship-resistant, privacy-preserving, and decentralized domain name resolution
+ protocol. GNS cryptographically secures the binding of names to arbitrary tokens, enabling
+ it to double in some respects as an alternative to some of today's public key
+ infrastructures. </t>
+ <!--<t>
+ Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS roughly follows the idea of
+ a local
+ root zone deployment (see <xref target="RFC8806"/>), with the
+ difference that the design encourages alternative roots and
+ does not expect all deployments to use the same or any specific
+ root zone. In the GNS reference implementation, users can
+ autonomously and freely delegate control of names to zones
+ through their local configurations.
+ GNS expects each user to be in control of their setup.
+ By following the guidelines in <xref target="namespace_ambiguity"/>,
+ users should manage to avoid any confusion as to how names are
+ resolved.
+ </t>
+ <t>
+ Name resolution and zone dissemination are based on the
+ principle of a petname system where users can assign local
+ names to zones. The GNS has its roots in ideas from the Simple
+ Distributed Security Infrastructure <xref target="SDSI"/>,
+ enabling the decentralized mapping of secure identifiers to
+ memorable names. One of the first academic descriptions of the
+ cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
+ </t>-->
+ <t>
+ This document defines the normative wire format of resource
+ records and resolution processes for use by implementers.
+ </t>
+ <section>
+ <name>Requirements Notation</name>
+ <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
+ "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD
+ NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>",
+ and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
+ BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, they
+ appear in all capitals, as shown here.</t>
+ </section>
+ </section>
+ <section>
+ <name>Terminology</name>
+ <t>The terminology defined in <xref target="RFC9498" /> also applies to this document.</t>
+ </section>
+ <section anchor="rrecords">
+ <name>Resource Records</name>
+ <section anchor="gnsrecords_other">
+ <name>Auxiliary Records</name>
+ <t> This section defines an additional auxiliary GNS record type. Any implementation <bcp14>
+ SHOULD</bcp14> be able to process the specified record types according to <xref
+ target="record_processing" />. </t>
+ <section anchor="gnsrecords_sbox">
+ <name>SBOX</name>
+ <t>
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This avoids unnecessary additional
+ lookups and cryptographically ties together information that belongs
+ together, making it impossible for an adversarial storage entity to provide
+ partial answers that might omit information critical for security.
+ </t>
+ <t>
+ This general strategy is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with.</t>
+ <t>This way of handling and storing restricts the allowed and processable underscore
+ labels to the format of "_SERVICE._PROTOCOL" as well as only services registered in
+ the corresponding IANA registry. To support labels
+ "c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._smimecert"
+ for the intended use of SMIMEA record, a new SBOX record is proposed. The SBOX
+ record is supposed to handle all variations of underscore labels. The underlying idea is
+ instead
+ of storing the service and protocol numbers, the string representation of the underscore
+ label and all subsequent labels is stored. A SBOX record boxes the records type, the
+ records
+ data and the underscore label and subsequent labels and adds them to the record set
+ of the associated label. For example, a URI record for "_scheme._trust.exampel.com"
+ will be stored as an SBOX record in the record set of "example.com" with the label
+ "_schema._trust" and record type URI and the URI records data</t>
+ <t>For reference, see also <xref target="RFC8552" />. A SBOX DATA entry is illustrated in <xref
+ target="figure_boxrecord" />. </t>
+ <figure anchor="figure_boxrecord">
+ <name>The SBOX DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TYPE | LABEL /
++-----------+-----------+ /
+/ /
+/ /
++-----------------------------------------------+
+/ RECORD DATA /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>TYPE:</dt>
+ <dd>
+ The 32-bit record type of the boxed record in network byte order.
+ </dd>
+ <dt>LABEL:</dt>
+ <dd> A variable-length field containing the first underscore label and all subsequent
+ labels. Characters are encoded as c-strings and <bcp14>MUST</bcp14> be null
+ terminated. </dd>
+ <dt>RECORD DATA:</dt>
+ <dd> A variable-length field containing the "DATA" format of TYPE as defined for the
+ respective TYPE. Thus, for TYPE values below 2<sup>16</sup>, the format is the same as
+ the respective record type's binary format in DNS. </dd>
+ </dl>
+ </section>
+ </section>
+ </section>
+ <section anchor="resolution">
+ <name>Name Resolution</name>
+ <section anchor="record_processing">
+ <name>Record Processing</name>
+ <t> The first step in processing the records remains the same as described in <xref
+ target="RFC9498" /> Section 4.1. </t>
+ <t> The next step depends on the context of the name being resolved. Case 3, as defined in <xref
+ target="RFC9498" /> Section 4.1, is modified and Case 6 is added to the list: </t>
+ <dl newline="false">
+ <dt>Case 3:</dt>
+ <dd>If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the
+ record set contains one or more matching BOX records, the records in the BOX records are
+ part of the final result and the recursion is processed as described in <xref
+ target="box_processing" />. An additional check for "Case 6" <bcp14>MUST</bcp14> be
+ made if the record set contains SBOX records.</dd>
+ </dl>
+ <dl newline="false">
+ <dt>Case 6:</dt>
+ <dd>If the remainder of the name to be resolved is strating with "_" and the record set
+ contains one or more matching SBOX records, the records in the SBOX records are part of
+ the final result and the recursion is processed as described in <xref
+ target="sbox_processing" />. An additional check for "Case 3" <bcp14>MUST</bcp14> be
+ made if the record set contains BOX records.</dd>
+ </dl>
+ <section anchor="box_processing">
+ <name>BOX</name>
+ <t>
+ When a BOX record is received, a GNS resolver must unbox it if the
+ name to be resolved continues with "_SERVICE._PROTO".
+ Otherwise, the BOX record is to be left untouched. This way, TLSA
+ (and SRV) records do not require a separate network request, and
+ TLSA records become inseparable from the corresponding address
+ records.
+ </t>
+ </section>
+ <section anchor="sbox_processing">
+ <name>SBOX</name>
+ <t>
+ When a SBOX record is received, a GNS resolver must unbox it if the
+ name to be resolved continues with "_" at the start of the next label.
+ Otherwise, the SBOX record is to be left untouched.
+ </t>
+ </section>
+ </section>
+ </section>
+ <section anchor="gana">
+ <name>GANA Considerations</name>
+ <section anchor="gana_gnsrr">
+ <name>GNS Record Types Registry</name>
+ <t> GANA <xref target="GANA" /> manages the "GNS Record Types" registry. </t>
+ <t>Each entry has the following format:
+ </t>
+ <dl newline="false">
+ <dt>Name:</dt>
+ <dd>The name of the record type (case-insensitive ASCII
+ string, restricted to alphanumeric characters). For zone delegation
+ records, the assigned number represents the ztype value of the zone.</dd>
+ <dt>Number:</dt>
+ <dd>A 32-bit number above 65535.</dd>
+ <dt>Comment:</dt>
+ <dd>Optionally, brief English text describing the purpose of
+ the record type (in UTF-8).</dd>
+ <dt>Contact:</dt>
+ <dd>Optionally, the contact information for a person to contact for
+ further information.</dd>
+ <dt>References:</dt>
+ <dd>Optionally, references (such as an RFC) describing the record type.</dd>
+ </dl>
+ <t> GANA has assigned a number for the record type SBOX defined in this specification in the
+ "GNS Record Types" registry as listed in <xref target="tab_rrtypenums" />. </t>
+
+ <table anchor="tab_rrtypenums">
+ <name>The GANA GNS Record Types Registry</name>
+ <thead>
+ <tr>
+ <th>Number</th>
+ <th>Name</th>
+ <th>Contact</th>
+ <th>References</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>65536</td>
+ <td>PKEY</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone delegation (PKEY)</td>
+ </tr>
+ <tr>
+ <td>65537</td>
+ <td>NICK</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone nickname</td>
+ </tr>
+ <tr>
+ <td>65538</td>
+ <td>LEHO</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS legacy hostname</td>
+ </tr>
+ <tr>
+ <td>65540</td>
+ <td>GNS2DNS</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Delegation to DNS</td>
+ </tr>
+ <tr>
+ <td>65541</td>
+ <td>BOX</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Box records</td>
+ </tr>
+ <tr>
+ <td>65547</td>
+ <td>SBOX</td>
+ <td>(*)</td>
+ <td>LSD 0010</td>
+ <td>SBox records</td>
+ </tr>
+ <tr>
+ <td>65551</td>
+ <td>REDIRECT</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Redirection record</td>
+ </tr>
+ <tr>
+ <td>65556</td>
+ <td>EDKEY</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone delegation (EDKEY)</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="5">(*): gns-registry@gnunet.org</td>
+ </tr>
+ </tfoot>
+ </table>
+ </section>
+ </section>
+ </middle>
+ <back>
+ <references>
+ <name>References</name>
+ <references>
+ <name>Normative References</name>
+
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml" />
+
+ <reference anchor="GANA" target="https://gana.gnunet.org/">
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023" />
+ </front>
+ </reference>
+ </references>
+ <references>
+ <name>Informative References</name>
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" />
+ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9498.xml" />
+
+ <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280-9_9">
+ <front>
+ <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date month="October" year="2014" />
+ </front>
+ <refcontent>13th International Conference on Cryptology and Network Security (CANS)</refcontent>
+ <seriesInfo name="DOI" value="10.13140/2.1.4642.3044" />
+ </reference>
+
+ <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git">
+ <front>
+ <title>gnunet.git - GNUnet core repository</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023" />
+ </front>
+ </reference>
+
+ <reference anchor="GNUnet" target="https://gnunet.org">
+ <front>
+ <title>The GNUnet Project (Home Page)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023" />
+ </front>
+ </reference>
+ </references>
+ </references>
+ </back>
+</rfc>
