commit 44a01f414b44c625b7b24a4ad6d72b2fc625d3da
parent f34be766564619034f3f8048b74cfbb81fe0e6c8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 20 May 2022 19:56:41 +0200
use cases
Diffstat:
1 file changed, 165 insertions(+), 110 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -322,7 +322,7 @@
zone key of a zone.
Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
A zTLD label sequence can only be distinguished from ordinary TLD label sequences
- by attempting to decode the labels into a zone type and zone key.
+ by attempting to decode the labels into a zone type and zone key.
</dd>
<dt>Zone Type</dt>
@@ -3203,6 +3203,169 @@ Value Symbol Symbol
</figure>
</section>
<section>
+ <name>Use Cases</name>
+ <t>
+ This section outlines a number of specific use cases which may
+ help to fill the gaps not addressed in the technical specification
+ itself.
+ </t>
+ <section anchor="day_in_zoneowner">
+ <name>Zone Dissemination</name>
+ <t>
+ In order to become a zone owner, it is sufficient to generate
+ a zone key and a corresponding secret key using a GNS implementation.
+ At this point, the zone owner can manage GNS resource records in a
+ local zone database.
+ The resource records can then be published by a GNS implementation
+ as defined in <xref target="publish"/>.
+ For other users to resolve the resource records, respective
+ zone information must be disseminated first.
+ The zone owner may decide to make the zone key and labels known
+ to a selected set of users only or to make this information available
+ to the general public.
+ </t>
+ <t>
+ Sharing zone information directly with specific users not only allows
+ to potentially preserve zone and record privacy, but also allows
+ the zone owner and the user to establish strong trust relationships.
+ For example, a bank may send a customer letter with a QR code which
+ contains the GNS zone of the bank.
+ This allows the user to scan the QR code and establish a strong
+ link to the zone of the bank and with it, for example, the IP address
+ of the online banking web site.
+ </t>
+ <t>
+ Most Internet services likely want to make their zones available
+ to the general public as efficiently as possible.
+ First, it is reasonable to assume that zones which are commanding
+ high levels of reputation and trust are likely included in the
+ default suffix-to-zone mappings of implementations.
+ Hence dissemination of a zone through delegation under such zones
+ can be a viable path in order to disseminate a zone publicly.
+ For example, it is conceivable that organizations such as ICANN
+ or country-code top-level domain registrars also manage GNS zones
+ and offer registration or delegation services.
+ </t>
+ <t>
+ Following best practices in particularly those relating to
+ security and abuse mitigation are methods which allow zone owners
+ and aspiring registrars to gain a good reputation and eventually
+ trust.
+ This includes, of course, diligent protection of private zone key
+ material.
+ Formalizing such best practices is out of scope of this
+ specification and should be addressed in a separate document and take
+ <xref target="security"/> into account.
+ </t>
+ </section>
+ <section>
+ <name>Suffix-to-zone Configuration</name>
+ <t>
+ A user is expected to install a GNS implementation if it is not already
+ provided through other means such as the operating system
+ or the browser.
+ It is likely that the implementation ships with a configurable
+ default suffix-to-name mapping.
+ This means that the user is able to resolve GNS names ending on a
+ zTLD or ending on a configured suffix-to-name mapping.
+ At this point the user may delete or otherwise modify the
+ implementation's default suffix-to-name mapping:
+ </t>
+ <t>
+ Deletion of mappings may become necessary of the
+ zone owner referenced by the mapping has lost the trust of the user.
+ For example, this could be due to lax registration policies resulting
+ in phishing activities.
+ Modification and addition of new mappings are means to heal the
+ namespace perforation which would occur in the case of a deletion
+ or to simply establish a strong direct trust relationship.
+ However, this requires the user's knowledge of the respective zone
+ keys.
+ This information must be retrieved out of band, as illustrated in
+ <xref target="day_in_zoneowner"/>:
+ A bank may send the user a letter with a QR code which contains the
+ GNS zone of the bank.
+ Other examples include scanning the QR off the device of a friend,
+ from a storefront, or an advertisement.
+ The level of trust in the respective zone is contextual and likely
+ varies from user to user.
+ Trust in a zone provided through a letter from a bank which
+ may also include a credit card is certainly different from a zone
+ found on a random advertisement in the streets.
+ However, this trust is immediately tangible to the user and can
+ be reflected in the local naming as well.
+ </t>
+ <t>
+ User clients should facilitate the suffix-to-name modification
+ process, for example by providing a QR code reader or other import
+ mechanisms.
+ Implementations are ideally implemented
+ according to best practices, particular addressing applicable points
+ from <xref target="security"/>.
+ Formalizing such best practices is out of scope of this
+ specification.
+ </t>
+ </section>
+ <section>
+ <name>Virtual Hosting</name>
+ <t>
+ HTTP virtual hosting and TLS Server Name Indication are common
+ use cases on the Web.
+ The HTTP client such as a browser supplies a DNS name in the HTTP
+ "Host"-header or the TLS handshake, respectively.
+ This allows the HTTP server to serve the indicated virtual host
+ with a matching TLS handshake.
+ Any resource record in GNS can be represented as a concatenation of
+ of a GNS label and the zTLD of the zone.
+ While not human-readable, this property of GNS names can be
+ leveraged in order to facilitate the same use cases.
+ </t>
+ <t>
+ Consider the GNS name "www.example.gns" entered in a GNS-aware
+ HTTP client.
+ At first, "www.example.gns" is resolved using GNS yielding a record
+ set.
+ Then, the HTTP client first determines the virtual host as follows:
+ </t>
+ <ol>
+ <li>If there is a LEHO record (<xref target="gnsrecords_leho"/>) in
+ the record set, then the HTTP client uses the record value in the
+ "Host"-header field of the HTTP request. Example:
+ "Host: www.example.com".</li>
+ <li>
+ If there is no LEHO record in the record set,
+ then the HTTP client tries to find the zone of the record
+ and translates the GNS name into an unabiguous
+ zTLD-representation before using it in the "Host"-header field of
+ the HTTP request. Example:
+ "Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+ </li>
+ </ol>
+ <t>
+ In order to determine a canonical representation of the record with
+ a zTLD, at most two queries are required:
+ First, it must be checked whether "www.example.com" itself points to
+ a zone delegation record which would imply that the record set which
+ was originally resolved is published under the apex label.
+ If it does, the unique GNS name is simply the zTLD representation
+ of the delegated zone: "Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W".
+ If it does not, the unique GNS name is the concatenation of the
+ label "www" and the zTLD representation of the zone as given in the
+ example above.
+ In any case, this representation is globally unique.
+ As such, it can be configured by the HTTP server administrator as a
+ virtual host name.
+ </t>
+ <t>
+ If the HTTP client is a browser, the use of a unique GNS name
+ for virtual hosting or TLS SNI does not necessarily have to be
+ shown to the user.
+ For example, the name in the URL bar may remain as "www.example.gnu"
+ even if the used unique name differs.
+ </t>
+ </section>
+ </section>
+ <section>
<name>Example flows</name>
<section>
<name>AAAA Example Resolution</name>
@@ -3329,115 +3492,7 @@ Value Symbol Symbol
<li>Return record set to application.</li>
</ol>
</section>
- <section anchor="day_in_zoneowner">
- <name>Use-case: Zone Owner</name>
- <t>
- In order to become a zone owner, it is sufficient to generate
- a zone key and a corresponding secret key using a GNS implementation.
- At this point, the zone owner can manage GNS resource records in a
- local zone database.
- The resource records can then be published by a GNS implementation
- as defined in <xref target="publish"/>.
- </t>
- <t>
- In order for other users to resolve the resource records, respective
- zone information must be disseminated first.
- The zone owner may decide to make the zone key and labels known
- to a selected set of users only or to make this information available
- to the general public.
- </t>
- <t>
- Sharing zone information directly with specific users not only allows
- to potentially preserve zone and record privacy, but also allows
- the zone owner and the user to establish strong trust relationships.
- For example, a bank may send a customer letter with a QR code which
- contains the GNS zone of the bank.
- This allows the user to scan the QR code and establish a strong
- link to the zone of the bank and with it, for example, the IP address
- of the online banking web site.
- </t>
- <t>
- Most Internet services likely want to make their zones available
- to the general public as efficiently as possible.
- First, it is reasonable to assume that zones which are commanding
- high levels of reputation and trust are likely included in the
- default suffix-to-zone mappings of implementations.
- Hence dissemination of a zone through delegation under such zones
- can be a viable path in order to disseminate a zone publicly.
- For example, it is conceivable that organizations such as ICANN
- or country-code top-level domain registrars also manage GNS zones
- and offer registration or delegation services.
- </t>
- <t>
- Following best practices in particularly those relating to
- security and abuse mitigation are methods which allow zone owners
- and aspiring registrars to gain a good reputation and eventually
- trust.
- This includes, of course, diligent protection of private zone key
- material.
- Formalizing such best practices is out of scope of this
- specification and should be addressed in a separate document addressing
- <xref target="security"/>.
- </t>
- </section>
- <section>
- <name>Use-case: End-user</name>
- <t>
- A user is expected to install a GNS implementation if it is not already
- provided through other means such as the operating system
- or the browser.
- </t>
- <t>
- It is expected that in any case, the implementation likely ships
- with a configurable default suffix-to-name mapping.
- This means that the user is able to resolve GNS names ending on a
- zTLD or ending on a configured suffix-to-name mapping.
- </t>
- <t>
- At this point the user may modify the implementation's default
- suffix-to-name mapping.
- This includes:
- </t>
- <ul>
- <li>Deletion of mappings.</li>
- <li>Modification of a mapping</li>
- <li>Addition of a new mapping</li>
- </ul>
- <t>
- The user may delete mappings. This may become necessary of the
- zone owner referenced by the mapping has lost the trust of the user.
- For example, this could be due to lax registration policies resulting
- in phishing activities.
- </t>
- <t>
- Modification and addition of new mappings are means to heal the
- namespace perforation which would occur in the case of a deletion
- or to simply establish a strong direct trust relationship.
- However, this requires the user's knowledge of respective zone
- information.
- This information must be retrieved out of band, as illustrated in
- <xref target="day_in_zoneowner"/>:
- A bank may send the user a letter with a QR code which contains the
- GNS zone of the bank.
- Other examples include scanning the QR off the device of a friend,
- from a storefront, or an advertisement.
- The level of trust in the respective zone is contextual and likely
- varies from user to user.
- Trust in a zone provided through a letter from a bank which
- may also include a credit card is certainly different from a zone
- found on a random advertisement in the streets.
- However, this trust is immediately tangible to the user and can
- be reflected in the local naming as well.
- </t>
- <t>
- User clients should facilitate the suffix-to-name modification
- process and are ideally implemented
- according to best practices, particular addressing applicable points
- from <xref target="security"/>.
- Formalizing such best practices is out of scope of this
- specification.
- </t>
- </section>
+
</section>
<section>
<name>Test Vectors</name>
