[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: use cases
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: use cases |
|
Date: |
Fri, 20 May 2022 19:56:45 +0200 |
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 44a01f4 use cases
44a01f4 is described below
commit 44a01f414b44c625b7b24a4ad6d72b2fc625d3da
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri May 20 19:56:41 2022 +0200
use cases
---
draft-schanzen-gns.xml | 275 +++++++++++++++++++++++++++++--------------------
1 file changed, 165 insertions(+), 110 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8d29003..10009a7 100644
--- 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>
@@ -3202,6 +3202,169 @@ Value Symbol Symbol
]]></artwork>
</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>
@@ -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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: use cases,
gnunet <=