diff options
Diffstat (limited to 'draft-schanzen-gns.xml')
-rw-r--r-- | draft-schanzen-gns.xml | 42 |
1 files changed, 25 insertions, 17 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index 652ce02..7119820 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -197,10 +197,10 @@ | |||
197 | <dd> | 197 | <dd> |
198 | The rightmost label in a GNS name is a GNS Top-Level Domain (TLD). | 198 | The rightmost label in a GNS name is a GNS Top-Level Domain (TLD). |
199 | Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>), | 199 | Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>), |
200 | GNS does not use a root zone as such. Instead, | 200 | GNS does not expect all users to use the same global root zone. Instead, |
201 | with the exception of Zone Top-Level Domains (see below), | 201 | with the exception of Zone Top-Level Domains (see below), |
202 | GNS TLDs are part of the configuration of the local resolver | 202 | GNS TLDs are typically part of the configuration of the local resolver |
203 | (see <xref target="governance"/>) and may not be globally unique. | 203 | (see <xref target="governance"/>), and may thus not be globally unique. |
204 | </dd> | 204 | </dd> |
205 | <dt>Zone</dt> | 205 | <dt>Zone</dt> |
206 | <dd> | 206 | <dd> |
@@ -255,13 +255,17 @@ | |||
255 | Zones are uniquely identified by a zone key. | 255 | Zones are uniquely identified by a zone key. |
256 | Zone contents are signed using blinded private keys and | 256 | Zone contents are signed using blinded private keys and |
257 | encrypted using derived secret keys. | 257 | encrypted using derived secret keys. |
258 | The zone type determines the respectice set of cryptographic functions. | 258 | The zone type determines the respective set of cryptographic operations |
259 | and the wire formats for encrypted data, public keys and signatures. | ||
259 | </t> | 260 | </t> |
260 | <t> | 261 | <t> |
261 | A zone can be populated with mappings from labels to resource records by | 262 | A zone can be populated with mappings from labels to resource records by |
262 | its owner (<xref target="rrecords"/>). | 263 | its owner (<xref target="rrecords"/>). |
263 | Labels can be delegated to other zones using delegation records and in | 264 | A label can be mapped to a delegation record which results in the |
264 | order to support (legacy) applications as well as facilitate the use | 265 | corresponding subdomain being delegated to another zone. Circular |
266 | delegations are explicitly allowed, including delegating a subdomain | ||
267 | to its immediate parent zone. In | ||
268 | order to support (legacy) applications as well as to facilitate the use | ||
265 | of petnames, GNS defines auxiliary record types in addition to | 269 | of petnames, GNS defines auxiliary record types in addition to |
266 | supporting traditional DNS records. | 270 | supporting traditional DNS records. |
267 | </t> | 271 | </t> |
@@ -271,31 +275,35 @@ | |||
271 | (<xref target="publish"/>). | 275 | (<xref target="publish"/>). |
272 | In this process, unique zone identification is hidden from the network | 276 | In this process, unique zone identification is hidden from the network |
273 | through the use of key blinding. | 277 | through the use of key blinding. |
274 | It allows the creation of signatures for zone contents | 278 | Key blinding allows the creation of signatures for zone contents |
275 | using a blinded public/private key pair. | 279 | using a blinded public/private key pair. |
276 | This blinding is realized using a deterministic key | 280 | This blinding is realized using a deterministic key |
277 | derivation from | 281 | derivation from |
278 | the original zone key and corresponding private key using record label values. | 282 | the original zone key and corresponding private key using record label values |
279 | Specifically, the zone owner can derive private keys for each record | 283 | as blinding factors. |
284 | Specifically, the zone owner can derive blinded private keys for each record | ||
280 | set published under a label, and a | 285 | set published under a label, and a |
281 | resolver can derive the corresponding public keys. | 286 | resolver can derive the corresponding blinded public keys. |
282 | It is expected that GNS implementations use distributed or decentralized | 287 | It is expected that GNS implementations use distributed or decentralized |
283 | storages such as distributed hash tables (DHT) in order to facilitate | 288 | storages such as distributed hash tables (DHT) in order to facilitate |
284 | availability within a network without the need of servers. | 289 | availability within a network without the need for dedicated infrastructure. |
285 | Specification of such a distributed or decentralized storage is out of | 290 | Specification of such a distributed or decentralized storage is out of |
286 | scope of this document but possible existing implementations include those | 291 | scope of this document, but possible existing implementations include those |
287 | based on <xref target="RFC7363" />, <xref target="Kademlia" /> or | 292 | based on <xref target="RFC7363" />, <xref target="Kademlia" /> or |
288 | <xref target="R5N" />. | 293 | <xref target="R5N" />. |
289 | </t> | 294 | </t> |
290 | <t> | 295 | <t> |
291 | Names in GNS are domain names as defined in <xref target="RFC8499"/>. | 296 | Names in GNS are domain names as defined in <xref target="RFC8499"/>. |
292 | Starting from a configurable root zone, names are resolved following zone | 297 | Starting from a configurable root zone, names are resolved by following zone |
293 | delegations which are recursively queried from the storage (<xref target="resolution"/>). | 298 | delegations. For each label in a name, the recursive GNS resolver |
299 | fetches the respective record from the storage layer (<xref target="resolution"/>). | ||
294 | Without knowledge of the label values and the zone keys, the | 300 | Without knowledge of the label values and the zone keys, the |
295 | different derived keys are unlinkable both to the original key and to each | 301 | different derived keys are unlinkable both to the original zone key and to each |
296 | other. | 302 | other. |
297 | This prevents zone enumeration and requires knowledge | 303 | This prevents zone enumeration (except via impractical online brute |
298 | of both the zone key and the label to confirm affiliation with a | 304 | force attacks) and requires knowledge |
305 | of both the zone key and the label to confirm affiliation of a | ||
306 | query or the corresponding encrypted record set with a | ||
299 | specific zone. At the same time, the blinded zone key provides | 307 | specific zone. At the same time, the blinded zone key provides |
300 | resolvers | 308 | resolvers |
301 | with the ability to verify the integrity of the published information | 309 | with the ability to verify the integrity of the published information |