diff options
Diffstat (limited to 'draft-schanzen-gns.xml')
-rw-r--r-- | draft-schanzen-gns.xml | 92 |
1 files changed, 48 insertions, 44 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index dff4ed7..7f14e6d 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -167,22 +167,51 @@ | |||
167 | <t> | 167 | <t> |
168 | In GNS, any user may create and manage one or more cryptographically | 168 | In GNS, any user may create and manage one or more cryptographically |
169 | secured zones (<xref target="zones"/>). | 169 | secured zones (<xref target="zones"/>). |
170 | A GNS allows the creation of signatures for zone contents | ||
171 | using a blinded public/private key pair. | ||
172 | This blinding is realized using a deterministic key | ||
173 | derivation from | ||
174 | the original public and private zone keys using record label values. | ||
175 | Specifically, the zone owner can derive private keys for each record | ||
176 | set published under a label, and a | ||
177 | resolver can derive the corresponding public keys. | ||
178 | Without knowledge of the label values and the zone public keys, the | ||
179 | different derivations are unlinkable both to the original key and to each | ||
180 | other. | ||
181 | This prevents zone enumeration and requires knowledge | ||
182 | of both the public zone key and the label to confirm affiliation with a | ||
183 | specific zone. At the same time, the blinded zone public key provides nodes | ||
184 | with the ability to verifiy the integrity of the published information | ||
185 | without disclosing the originating zone. | ||
186 | </t> | ||
187 | <t> | ||
170 | A zone can be populated with mappings from labels to resource records by | 188 | A zone can be populated with mappings from labels to resource records by |
171 | its owner (<xref target="rrecords"/>). | 189 | its owner (<xref target="rrecords"/>). |
172 | Names can be delegated to other zones using delegation records and in | 190 | Labels can be delegated to other zones using delegation records and in |
173 | order to support (legacy) applications as well as facilitate the use | 191 | order to support (legacy) applications as well as facilitate the use |
174 | of petnames, GNS defines auxiliary record types in addition to | 192 | of petnames, GNS defines auxiliary record types in addition to |
175 | supporting traditional DNS records. | 193 | supporting traditional DNS records. |
176 | Resource records of zones are grouped by label, encrypted and signed | 194 | </t> |
177 | before beging published as RRBLOCK in a distributed key-value storage | 195 | <t> |
196 | Zone contents are encrypted and signed | ||
197 | before being published as RRBLOCKs in a distributed key-value storage | ||
178 | (<xref target="publish"/>). | 198 | (<xref target="publish"/>). |
179 | In this process, unique zone identification is hidden from the network | 199 | In this process, unique zone identification is hidden from the network |
180 | through the use of key blinding. | 200 | through the use of key blinding. |
201 | It is expected that GNS implementations use distributed or decentralized | ||
202 | storages such as distributed hash tables (DHT) in order to facilitate | ||
203 | availability within a network without the need of servers. | ||
204 | Specification of such a distributed or decentralized storage is out of | ||
205 | scope of this document but possible existing implementations include those | ||
206 | based on <xref target="RFC7363" />, <xref target="Kademlia" /> or | ||
207 | <xref target="R5N" />. | ||
208 | </t> | ||
209 | <t> | ||
181 | Starting from a configurable root zone, names are resolved following zone | 210 | Starting from a configurable root zone, names are resolved following zone |
182 | delegations which are iteratively queried from the storage (<xref target="resolution"/>). | 211 | delegations which are iteratively queried from the storage (<xref target="resolution"/>). |
183 | </t> | 212 | </t> |
184 | <t> | 213 | <t> |
185 | In this document, the "implementer" refers to the developer building | 214 | In the remainder of this document, the "implementer" refers to the developer building |
186 | a GNS implementation including, for example, zone management tools and | 215 | a GNS implementation including, for example, zone management tools and |
187 | name resolution components. | 216 | name resolution components. |
188 | An "application" refers to a component which uses a GNS implementation | 217 | An "application" refers to a component which uses a GNS implementation |
@@ -192,34 +221,16 @@ | |||
192 | <section anchor="zones" numbered="true" toc="default"> | 221 | <section anchor="zones" numbered="true" toc="default"> |
193 | <name>Zones</name> | 222 | <name>Zones</name> |
194 | <t> | 223 | <t> |
195 | A zone in GNS is defined by a zone type that identifies | 224 | A zone in GNS is defined by its zone type and zone ID. |
196 | a cryptosystem and a public/private key pair where d is the private | 225 | The zone type determines a set of cryptographic functions which |
197 | key and zk the corresponding public key. | 226 | enables the creation of signatures for zone contents using a blinded |
198 | The contents of a zone are cryptographically signed before | 227 | public/private key pairs and encryption of zone contents. |
199 | being published by its owner for resolution by other parties. | 228 | Further, each zone can be represented by a Zone Top-Level Domain (zTLD) |
200 | Records are grouped by their label, and encrypted using an encryption | 229 | string. |
201 | key derived from the label and the zone public key (see <xref target="records_block"/>). | ||
202 | Instead of the zone private key d, a GNS zone MUST support the creation | ||
203 | of signatures using a blinded public/private key pair. | ||
204 | This blinding is commonly realized using a deterministic key | ||
205 | derivation scheme. | ||
206 | Such a scheme allows the deterministic derivation of keys from | ||
207 | the original public and private zone keys using record label values. | ||
208 | Specifically, the zone owner can derive private keys for each record | ||
209 | set published under a label, and a | ||
210 | resolver can derive the corresponding public keys. | ||
211 | Without knowledge of the label values and the zone public keys, the | ||
212 | different derivations are unlinkable both to the original key and to each | ||
213 | other. | ||
214 | This prevents zone enumeration and requires knowledge | ||
215 | of both the public zone key and the label to confirm affiliation with a | ||
216 | specific zone. At the same time, the blinded zone public key provides nodes | ||
217 | with the ability to verifiy the integrity of the published information | ||
218 | without disclosing the originating zone. | ||
219 | </t> | 230 | </t> |
220 | <t> | 231 | <t> |
221 | Based on the above, the following variables are associated with a zone in | 232 | In this section, the zone type, zone ID, zTLD and zone revocation is |
222 | GNS and used in the following throughout this specification. | 233 | defined. |
223 | </t> | 234 | </t> |
224 | <section anchor="ztype" numbered="true" toc="default"> | 235 | <section anchor="ztype" numbered="true" toc="default"> |
225 | <name>Zone Type</name> | 236 | <name>Zone Type</name> |
@@ -1397,30 +1408,23 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8) | |||
1397 | <t> | 1408 | <t> |
1398 | Any API which allows storing a value under a key and retrieving | 1409 | Any API which allows storing a value under a key and retrieving |
1399 | a value from the key can be used by an implementation for record storage. | 1410 | a value from the key can be used by an implementation for record storage. |
1400 | It is expected that GNS implementations use distributed or decentralized | ||
1401 | storages such as distributed hash tables (DHT) in order to facilitate | ||
1402 | availability within a network without the need of servers. | ||
1403 | Specification of such a distributed or decentralized storage is out of | ||
1404 | scope of this document but possible existing implementations include <xref target="RFC7363" />, | ||
1405 | <xref target="Kademlia" />, <xref target="R5N" /> or <xref target="Ipfs" />. | ||
1406 | </t> | ||
1407 | <t> | ||
1408 | We assume that an implementation realizes two procedures on top of a | 1411 | We assume that an implementation realizes two procedures on top of a |
1409 | storage: | 1412 | storage: |
1410 | </t> | 1413 | </t> |
1411 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1414 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1412 | PUT(key,value) | 1415 | PUT(key,value) |
1413 | value := GET(key) | 1416 | GET(key) -> value |
1414 | ]]></artwork> | 1417 | ]]></artwork> |
1415 | <t> | 1418 | <t> |
1416 | In GNS, resource records are grouped by their respective labels, | 1419 | Resource records are grouped by their respective labels, |
1417 | encrypted and published together in a single resource records block | 1420 | encrypted and published together in a single resource records block |
1418 | (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK). | 1421 | (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK). |
1419 | The key q is derived from the zone key and the respective | 1422 | The key q is derived from the zone key and the respective |
1420 | label of the contained records. The storage key derivation and records | 1423 | label of the contained records. The storage key derivation and records |
1421 | block creation is specified in the following sections. | 1424 | block creation is specified in the following sections. |
1422 | A client implementation must enable the user the manage zones and use the | 1425 | A client implementation MUST enable the user the manage zones. |
1423 | PUT storage procedure in order to update the zone contents. | 1426 | The implementation MUST use the PUT storage procedure in order to update |
1427 | the zone contents accordingly. | ||
1424 | </t> | 1428 | </t> |
1425 | <section anchor="blinding" numbered="true" toc="default"> | 1429 | <section anchor="blinding" numbered="true" toc="default"> |
1426 | <name>The Storage Key</name> | 1430 | <name>The Storage Key</name> |
@@ -2696,7 +2700,7 @@ cae1789d | |||
2696 | <date year="2002"/> | 2700 | <date year="2002"/> |
2697 | </front> | 2701 | </front> |
2698 | </reference> | 2702 | </reference> |
2699 | <reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561"> | 2703 | <!--<reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561"> |
2700 | <front> | 2704 | <front> |
2701 | <title>Ipfs-content addressed, versioned, p2p file system.</title> | 2705 | <title>Ipfs-content addressed, versioned, p2p file system.</title> |
2702 | <author initials="J." surname="Benet" fullname="Juan Benet"> | 2706 | <author initials="J." surname="Benet" fullname="Juan Benet"> |
@@ -2704,7 +2708,7 @@ cae1789d | |||
2704 | <date year="2014"/> | 2708 | <date year="2014"/> |
2705 | </front> | 2709 | </front> |
2706 | </reference> | 2710 | </reference> |
2707 | 2711 | --> | |
2708 | 2712 | ||
2709 | <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"> | 2713 | <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"> |
2710 | <front> | 2714 | <front> |