commit a1bd60c51857b3648fad752b2ba75080835fdf09
parent b16cec0b26fd851d467f202f07c0df9ad7e96d1a
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
Date: Sun, 17 May 2020 22:07:57 +0200
update date; remove compile targets
Diffstat:
3 files changed, 1 insertion(+), 4922 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1,3129 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" class="Internet-Draft">
-<head>
-<meta charset="utf-8">
-<meta content="Common,Latin" name="scripts">
-<meta content="initial-scale=1.0" name="viewport">
-<title>The GNU Name System Specification</title>
-<meta content="Martin Schanzenbach" name="author">
-<meta content="Christian Grothoff" name="author">
-<meta content="Bernd Fix" name="author">
-<meta content="
- This document contains the GNU Name System (GNS) technical specification.
- " name="description">
-<meta content="xml2rfc 2.39.0" name="generator">
-<meta content="name systems" name="keyword">
-<meta content="draft-schanzen-gns-00" name="ietf.draft">
-<link href="draft-schanzen-gns.xml" rel="alternate" type="application/rfc+xml">
-<link href="#copyright" rel="license">
-<style type="text/css">/*
-
- NOTE: Changes at the bottom of this file overrides some earlier settings.
-
- Once the style has stabilized and has been adopted as an official RFC style,
- this can be consolidated so that style settings occur only in one place, but
- for now the contents of this file consists first of the initial CSS work as
- provided to the RFC Formatter (xml2rfc) work, followed by itemized and
- commented changes found necssary during the development of the v3
- formatters.
-
-*/
-
-/* fonts */
-@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
-@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
-@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */
-
-@viewport {
- zoom: 1.0;
- width: extend-to-zoom;
-}
-@-ms-viewport {
- width: extend-to-zoom;
- zoom: 1.0;
-}
-/* general and mobile first */
-html {
-}
-body {
- max-width: 90%;
- margin: 1.5em auto;
- color: #222;
- background-color: #fff;
- font-size: 14px;
- font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
- line-height: 1.6;
- scroll-behavior: smooth;
-}
-.ears {
- display: none;
-}
-
-/* headings */
-#title, h1, h2, h3, h4, h5, h6 {
- margin: 1em 0 0.5em;
- font-weight: bold;
- line-height: 1.3;
-}
-#title {
- clear: both;
- border-bottom: 1px solid #ddd;
- margin: 0 0 0.5em 0;
- padding: 1em 0 0.5em;
-}
-.author {
- padding-bottom: 4px;
-}
-h1 {
- font-size: 26px;
- margin: 1em 0;
-}
-h2 {
- font-size: 22px;
- margin-top: -20px; /* provide offset for in-page anchors */
- padding-top: 33px;
-}
-h3 {
- font-size: 18px;
- margin-top: -36px; /* provide offset for in-page anchors */
- padding-top: 42px;
-}
-h4 {
- font-size: 16px;
- margin-top: -36px; /* provide offset for in-page anchors */
- padding-top: 42px;
-}
-h5, h6 {
- font-size: 14px;
-}
-#n-copyright-notice {
- border-bottom: 1px solid #ddd;
- padding-bottom: 1em;
- margin-bottom: 1em;
-}
-/* general structure */
-p {
- padding: 0;
- margin: 0 0 1em 0;
- text-align: left;
-}
-div, span {
- position: relative;
-}
-div {
- margin: 0;
-}
-.alignRight.art-text {
- background-color: #f9f9f9;
- border: 1px solid #eee;
- border-radius: 3px;
- padding: 1em 1em 0;
- margin-bottom: 1.5em;
-}
-.alignRight.art-text pre {
- padding: 0;
-}
-.alignRight {
- margin: 1em 0;
-}
-.alignRight > *:first-child {
- border: none;
- margin: 0;
- float: right;
- clear: both;
-}
-.alignRight > *:nth-child(2) {
- clear: both;
- display: block;
- border: none;
-}
-svg {
- display: block;
-}
-.alignCenter.art-text {
- background-color: #f9f9f9;
- border: 1px solid #eee;
- border-radius: 3px;
- padding: 1em 1em 0;
- margin-bottom: 1.5em;
-}
-.alignCenter.art-text pre {
- padding: 0;
-}
-.alignCenter {
- margin: 1em 0;
-}
-.alignCenter > *:first-child {
- border: none;
- /* this isn't optimal, but it's an existence proof. PrinceXML doesn't
- support flexbox yet.
- */
- display: table;
- margin: 0 auto;
-}
-
-/* lists */
-ol, ul {
- padding: 0;
- margin: 0 0 1em 2em;
-}
-ol ol, ul ul, ol ul, ul ol {
- margin-left: 1em;
-}
-li {
- margin: 0 0 0.25em 0;
-}
-.ulCompact li {
- margin: 0;
-}
-ul.empty, .ulEmpty {
- list-style-type: none;
-}
-ul.empty li, .ulEmpty li {
- margin-top: 0.5em;
-}
-ul.compact, .ulCompact,
-ol.compact, .olCompact {
- line-height: 100%;
- margin: 0 0 0 2em;
-}
-
-/* definition lists */
-dl {
-}
-dl > dt {
- float: left;
- margin-right: 1em;
-}
-/*
-dl.nohang > dt {
- float: none;
-}
-*/
-dl > dd {
- margin-bottom: .8em;
- min-height: 1.3em;
-}
-dl.compact > dd, .dlCompact > dd {
- margin-bottom: 0em;
-}
-dl > dd > dl {
- margin-top: 0.5em;
- margin-bottom: 0em;
-}
-
-/* links */
-a {
- text-decoration: none;
-}
-a[href] {
- color: #22e; /* Arlen: WCAG 2019 */
-}
-a[href]:hover {
- background-color: #f2f2f2;
-}
-figcaption a[href],
-a[href].selfRef {
- color: #222;
-}
-/* XXX probably not this:
-a.selfRef:hover {
- background-color: transparent;
- cursor: default;
-} */
-
-/* Figures */
-tt, code, pre, code {
- background-color: #f9f9f9;
- font-family: 'Roboto Mono', monospace;
-}
-pre {
- border: 1px solid #eee;
- margin: 0;
- padding: 1em;
-}
-img {
- max-width: 100%;
-}
-figure {
- margin: 0;
-}
-figure blockquote {
- margin: 0.8em 0.4em 0.4em;
-}
-figcaption {
- font-style: italic;
- margin: 0 0 1em 0;
-}
-@media screen {
- pre {
- overflow-x: auto;
- max-width: 100%;
- max-width: calc(100% - 22px);
- }
-}
-
-/* aside, blockquote */
-aside, blockquote {
- margin-left: 0;
- padding: 1.2em 2em;
-}
-blockquote {
- background-color: #f9f9f9;
- color: #111; /* Arlen: WCAG 2019 */
- border: 1px solid #ddd;
- border-radius: 3px;
- margin: 1em 0;
-}
-cite {
- display: block;
- text-align: right;
- font-style: italic;
-}
-
-/* tables */
-table {
- width: 100%;
- margin: 0 0 1em;
- border-collapse: collapse;
- border: 1px solid #eee;
-}
-th, td {
- text-align: left;
- vertical-align: top;
- padding: 0.5em 0.75em;
-}
-th {
- text-align: left;
- background-color: #e9e9e9;
-}
-tr:nth-child(2n+1) > td {
- background-color: #f5f5f5;
-}
-table caption {
- font-style: italic;
- margin: 0;
- padding: 0;
- text-align: left;
-}
-table p {
- /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
- be allowed within tables more generally, it would be far better to select on a class. */
- margin: 0;
-}
-
-/* pilcrow */
-a.pilcrow {
- color: #666; /* Arlen: AHDJ 2019 */
- text-decoration: none;
- visibility: hidden;
- user-select: none;
- -ms-user-select: none;
- -o-user-select:none;
- -moz-user-select: none;
- -khtml-user-select: none;
- -webkit-user-select: none;
- -webkit-touch-callout: none;
-}
-@media screen {
- aside:hover > a.pilcrow,
- p:hover > a.pilcrow,
- blockquote:hover > a.pilcrow,
- div:hover > a.pilcrow,
- li:hover > a.pilcrow,
- pre:hover > a.pilcrow {
- visibility: visible;
- }
- a.pilcrow:hover {
- background-color: transparent;
- }
-}
-
-/* misc */
-hr {
- border: 0;
- border-top: 1px solid #eee;
-}
-.bcp14 {
- font-variant: small-caps;
-}
-
-.role {
- font-variant: all-small-caps;
-}
-
-/* info block */
-#identifiers {
- margin: 0;
- font-size: 0.9em;
-}
-#identifiers dt {
- width: 3em;
- clear: left;
-}
-#identifiers dd {
- float: left;
- margin-bottom: 0;
-}
-#identifiers .authors .author {
- display: inline-block;
- margin-right: 1.5em;
-}
-#identifiers .authors .org {
- font-style: italic;
-}
-
-/* The prepared/rendered info at the very bottom of the page */
-.docInfo {
- color: #666; /* Arlen: WCAG 2019 */
- font-size: 0.9em;
- font-style: italic;
- margin-top: 2em;
-}
-.docInfo .prepared {
- float: left;
-}
-.docInfo .prepared {
- float: right;
-}
-
-/* table of contents */
-#toc {
- padding: 0.75em 0 2em 0;
- margin-bottom: 1em;
-}
-nav.toc ul {
- margin: 0 0.5em 0 0;
- padding: 0;
- list-style: none;
-}
-nav.toc li {
- line-height: 1.3em;
- margin: 0.75em 0;
- padding-left: 1.2em;
- text-indent: -1.2em;
-}
-/* references */
-.references dt {
- text-align: right;
- font-weight: bold;
- min-width: 7em;
-}
-.references dd {
- margin-left: 8em;
- overflow: auto;
-}
-
-.refInstance {
- margin-bottom: 1.25em;
-}
-
-.references .ascii {
- margin-bottom: 0.25em;
-}
-
-/* index */
-.index ul {
- margin: 0 0 0 1em;
- padding: 0;
- list-style: none;
-}
-.index ul ul {
- margin: 0;
-}
-.index li {
- margin: 0;
- text-indent: -2em;
- padding-left: 2em;
- padding-bottom: 5px;
-}
-.indexIndex {
- margin: 0.5em 0 1em;
-}
-.index a {
- font-weight: 700;
-}
-/* make the index two-column on all but the smallest screens */
-@media (min-width: 600px) {
- .index ul {
- -moz-column-count: 2;
- -moz-column-gap: 20px;
- }
- .index ul ul {
- -moz-column-count: 1;
- -moz-column-gap: 0;
- }
-}
-
-/* authors */
-address.vcard {
- font-style: normal;
- margin: 1em 0;
-}
-
-address.vcard .nameRole {
- font-weight: 700;
- margin-left: 0;
-}
-address.vcard .label {
- font-family: "Noto Sans",Arial,Helvetica,sans-serif;
- margin: 0.5em 0;
-}
-address.vcard .type {
- display: none;
-}
-.alternative-contact {
- margin: 1.5em 0 1em;
-}
-hr.addr {
- border-top: 1px dashed;
- margin: 0;
- color: #ddd;
- max-width: calc(100% - 16px);
-}
-
-/* temporary notes */
-.rfcEditorRemove::before {
- position: absolute;
- top: 0.2em;
- right: 0.2em;
- padding: 0.2em;
- content: "The RFC Editor will remove this note";
- color: #9e2a00; /* Arlen: WCAG 2019 */
- background-color: #ffd; /* Arlen: WCAG 2019 */
-}
-.rfcEditorRemove {
- position: relative;
- padding-top: 1.8em;
- background-color: #ffd; /* Arlen: WCAG 2019 */
- border-radius: 3px;
-}
-.cref {
- background-color: #ffd; /* Arlen: WCAG 2019 */
- padding: 2px 4px;
-}
-.crefSource {
- font-style: italic;
-}
-/* alternative layout for smaller screens */
-@media screen and (max-width: 1023px) {
- body {
- padding-top: 2em;
- }
- #title {
- padding: 1em 0;
- }
- h1 {
- font-size: 24px;
- }
- h2 {
- font-size: 20px;
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 38px;
- }
- #identifiers dd {
- max-width: 60%;
- }
- #toc {
- position: fixed;
- z-index: 2;
- top: 0;
- right: 0;
- padding: 0;
- margin: 0;
- background-color: inherit;
- border-bottom: 1px solid #ccc;
- }
- #toc h2 {
- margin: -1px 0 0 0;
- padding: 4px 0 4px 6px;
- padding-right: 1em;
- min-width: 190px;
- font-size: 1.1em;
- text-align: right;
- background-color: #444;
- color: white;
- cursor: pointer;
- }
- #toc h2::before { /* css hamburger */
- float: right;
- position: relative;
- width: 1em;
- height: 1px;
- left: -164px;
- margin: 6px 0 0 0;
- background: white none repeat scroll 0 0;
- box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
- content: "";
- }
- #toc nav {
- display: none;
- padding: 0.5em 1em 1em;
- overflow: auto;
- height: calc(100vh - 48px);
- border-left: 1px solid #ddd;
- }
-}
-
-/* alternative layout for wide screens */
-@media screen and (min-width: 1024px) {
- body {
- max-width: 724px;
- margin: 42px auto;
- padding-left: 1.5em;
- padding-right: 29em;
- }
- #toc {
- position: fixed;
- top: 42px;
- right: 42px;
- width: 25%;
- margin: 0;
- padding: 0 1em;
- z-index: 1;
- }
- #toc h2 {
- border-top: none;
- border-bottom: 1px solid #ddd;
- font-size: 1em;
- font-weight: normal;
- margin: 0;
- padding: 0.25em 1em 1em 0;
- }
- #toc nav {
- display: block;
- height: calc(90vh - 84px);
- bottom: 0;
- padding: 0.5em 0 0;
- overflow: auto;
- }
- img { /* future proofing */
- max-width: 100%;
- height: auto;
- }
-}
-
-/* pagination */
-@media print {
- body {
-
- width: 100%;
- }
- p {
- orphans: 3;
- widows: 3;
- }
- #n-copyright-notice {
- border-bottom: none;
- }
- #toc, #n-introduction {
- page-break-before: always;
- }
- #toc {
- border-top: none;
- padding-top: 0;
- }
- figure, pre {
- page-break-inside: avoid;
- }
- figure {
- overflow: scroll;
- }
- h1, h2, h3, h4, h5, h6 {
- page-break-after: avoid;
- }
- h2+*, h3+*, h4+*, h5+*, h6+* {
- page-break-before: avoid;
- }
- pre {
- white-space: pre-wrap;
- word-wrap: break-word;
- font-size: 10pt;
- }
- table {
- border: 1px solid #ddd;
- }
- td {
- border-top: 1px solid #ddd;
- }
-}
-
-/* This is commented out here, as the string-set: doesn't
- pass W3C validation currently */
-/*
-.ears thead .left {
- string-set: ears-top-left content();
-}
-
-.ears thead .center {
- string-set: ears-top-center content();
-}
-
-.ears thead .right {
- string-set: ears-top-right content();
-}
-
-.ears tfoot .left {
- string-set: ears-bottom-left content();
-}
-
-.ears tfoot .center {
- string-set: ears-bottom-center content();
-}
-
-.ears tfoot .right {
- string-set: ears-bottom-right content();
-}
-*/
-
-@page :first {
- padding-top: 0;
- @top-left {
- content: normal;
- border: none;
- }
- @top-center {
- content: normal;
- border: none;
- }
- @top-right {
- content: normal;
- border: none;
- }
-}
-
-@page {
- size: A4;
- margin-bottom: 45mm;
- padding-top: 20px;
- /* The follwing is commented out here, but set appropriately by in code, as
- the content depends on the document */
- /*
- @top-left {
- content: 'Internet-Draft';
- vertical-align: bottom;
- border-bottom: solid 1px #ccc;
- }
- @top-left {
- content: string(ears-top-left);
- vertical-align: bottom;
- border-bottom: solid 1px #ccc;
- }
- @top-center {
- content: string(ears-top-center);
- vertical-align: bottom;
- border-bottom: solid 1px #ccc;
- }
- @top-right {
- content: string(ears-top-right);
- vertical-align: bottom;
- border-bottom: solid 1px #ccc;
- }
- @bottom-left {
- content: string(ears-bottom-left);
- vertical-align: top;
- border-top: solid 1px #ccc;
- }
- @bottom-center {
- content: string(ears-bottom-center);
- vertical-align: top;
- border-top: solid 1px #ccc;
- }
- @bottom-right {
- content: '[Page ' counter(page) ']';
- vertical-align: top;
- border-top: solid 1px #ccc;
- }
- */
-
-}
-
-/* Changes introduced to fix issues found during implementation */
-/* Make sure links are clickable even if overlapped by following H* */
-a {
- z-index: 2;
-}
-/* Separate body from document info even without intervening H1 */
-section {
- clear: both;
-}
-
-
-/* Top align author divs, to avoid names without organization dropping level with org names */
-.author {
- vertical-align: top;
-}
-
-/* Leave room in document info to show Internet-Draft on one line */
-#identifiers dt {
- width: 8em;
-}
-
-/* Don't waste quite as much whitespace between label and value in doc info */
-#identifiers dd {
- margin-left: 1em;
-}
-
-/* Give floating toc a background color (needed when it's a div inside section */
-#toc {
- background-color: white;
-}
-
-/* Make the collapsed ToC header render white on gray also when it's a link */
-@media screen and (max-width: 1023px) {
- #toc h2 a,
- #toc h2 a:link,
- #toc h2 a:focus,
- #toc h2 a:hover,
- #toc a.toplink,
- #toc a.toplink:hover {
- color: white;
- background-color: #444;
- text-decoration: none;
- }
-}
-
-/* Give the bottom of the ToC some whitespace */
-@media screen and (min-width: 1024px) {
- #toc {
- padding: 0 0 1em 1em;
- }
-}
-
-/* Style section numbers with more space between number and title */
-.section-number {
- padding-right: 0.5em;
-}
-
-/* prevent monospace from becoming overly large */
-tt, code, pre, code {
- font-size: 95%;
-}
-
-/* Fix the height/width aspect for ascii art*/
-pre.sourcecode,
-.art-text pre {
- line-height: 1.12;
-}
-
-
-/* Add styling for a link in the ToC that points to the top of the document */
-a.toplink {
- float: right;
- margin-right: 0.5em;
-}
-
-/* Fix the dl styling to match the RFC 7992 attributes */
-dl > dt,
-dl.dlParallel > dt {
- float: left;
- margin-right: 1em;
-}
-dl.dlNewline > dt {
- float: none;
-}
-
-/* Provide styling for table cell text alignment */
-table td.text-left,
-table th.text-left {
- text-align: left;
-}
-table td.text-center,
-table th.text-center {
- text-align: center;
-}
-table td.text-right,
-table th.text-right {
- text-align: right;
-}
-
-/* Make the alternative author contact informatio look less like just another
- author, and group it closer with the primary author contact information */
-.alternative-contact {
- margin: 0.5em 0 0.25em 0;
-}
-address .non-ascii {
- margin: 0 0 0 2em;
-}
-
-/* With it being possible to set tables with alignment
- left, center, and right, { width: 100%; } does not make sense */
-table {
- width: auto;
-}
-
-/* Avoid reference text that sits in a block with very wide left margin,
- because of a long floating dt label.*/
-.references dd {
- overflow: visible;
-}
-
-/* Control caption placement */
-caption {
- caption-side: bottom;
-}
-
-/* Limit the width of the author address vcard, so names in right-to-left
- script don't end up on the other side of the page. */
-
-address.vcard {
- max-width: 30em;
- margin-right: auto;
-}
-
-/* For address alignment dependent on LTR or RTL scripts */
-address div.left {
- text-align: left;
-}
-address div.right {
- text-align: right;
-}
-
-/* Provide table alignment support. We can't use the alignX classes above
- since they do unwanted things with caption and other styling. */
-table.right {
- margin-left: auto;
- margin-right: 0;
-}
-table.center {
- margin-left: auto;
- margin-right: auto;
-}
-table.left {
- margin-left: 0;
- margin-right: auto;
-}
-
-/* Give the table caption label the same styling as the figcaption */
-caption a[href] {
- color: #222;
-}
-
-@media print {
- .toplink {
- display: none;
- }
-
- /* avoid overwriting the top border line with the ToC header */
- #toc {
- padding-top: 1px;
- }
-
- /* Avoid page breaks inside dl and author address entries */
- .vcard {
- page-break-inside: avoid;
- }
-
-}
-/* Avoid wrapping of URLs in references */
-@media screen {
- .references a {
- white-space: nowrap;
- }
-}
-/* Tweak the bcp14 keyword presentation */
-.bcp14 {
- font-variant: small-caps;
- font-weight: bold;
- font-size: 0.9em;
-}
-/* Tweak the invisible space above H* in order not to overlay links in text above */
- h2 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 31px;
- }
- h3 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
- h4 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
-/* Float artwork pilcrow to the right */
-@media screen {
- .artwork a.pilcrow {
- display: block;
- line-height: 0.7;
- margin-top: 0.15em;
- }
-}
-/* Make pilcrows on dd visible */
-@media screen {
- dd:hover > a.pilcrow {
- visibility: visible;
- }
-}
-/* Make the placement of figcaption match that of a table's caption
- by removing the figure's added bottom margin */
-.alignLeft.art-text,
-.alignCenter.art-text,
-.alignRight.art-text {
- margin-bottom: 0;
-}
-.alignLeft,
-.alignCenter,
-.alignRight {
- margin: 1em 0 0 0;
-}
-/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
- possibly even requiring a new line */
-@media print {
- a.pilcrow {
- display: none;
- }
-}
-/* Styling for the external metadata */
-div#external-metadata {
- background-color: #eee;
- padding: 0.5em;
- margin-bottom: 0.5em;
- display: none;
-}
-div#internal-metadata {
- padding: 0.5em; /* to match the external-metadata padding */
-}
-/* Styling for title RFC Number */
-h1#rfcnum {
- clear: both;
- margin: 0 0 -1em;
- padding: 1em 0 0 0;
-}
-/* Make .olPercent look the same as <ol><li> */
-dl.olPercent > dd {
- margin: 0 0 0.25em 0;
- min-height: initial;
-}
-/* Give aside some styling to set it apart */
-aside {
- border-left: 1px solid #ddd;
- margin: 1em 0 1em 2em;
- padding: 0.2em 2em;
-}
-aside > dl,
-aside > ol,
-aside > ul,
-aside > table,
-aside > p {
- margin-bottom: 0.5em;
-}
-/* Additional page break settings */
-@media print {
- figcaption, table caption {
- page-break-before: avoid;
- }
-}
-/* Font size adjustments for print */
-@media print {
- body { font-size: 10pt; line-height: normal; max-width: 96%; }
- h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
- h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */
- h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */
- h4 { font-size: 1em; padding-top: 1.5em; }
- h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; }
-}
-/* Sourcecode margin in print, when there's no pilcrow */
-@media print {
- .artwork,
- .sourcecode {
- margin-bottom: 1em;
- }
-}
-/*
- The margin-left: 0 on <dd> removes all distinction
- between levels from nested <dl>s. Undo that.
-*/
-dl.olPercent > dd,
-dd {
- margin-left: revert;
-}
-/* Avoid narrow tables forcing too narrow table captions, which may render badly */
-table {
- min-width: 20em;
-}</style>
-<link href="rfc-local.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<script src="metadata.min.js"></script>
-<table class="ears">
-<thead><tr>
-<td class="left">Internet-Draft</td>
-<td class="center">The GNU Name System</td>
-<td class="right">November 2019</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Schanzenbach, et al.</td>
-<td class="center">Expires 13 May 2020</td>
-<td class="right">[Page]</td>
-</tr></tfoot>
-</table>
-<div id="external-metadata" class="document-information"></div>
-<div id="internal-metadata" class="document-information">
-<dl id="identifiers">
-<dt class="label-workgroup">Workgroup:</dt>
-<dd class="workgroup">Independent Stream</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">draft-schanzen-gns-00</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2019-11-10" class="published">10 November 2019</time>
- </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Informational</dd>
-<dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2020-05-13">13 May 2020</time></dd>
-<dt class="label-authors">Authors:</dt>
-<dd class="authors">
-<div class="author">
- <div class="author-name">M. Schanzenbach</div>
-<div class="org">GNUnet e.V.</div>
-</div>
-<div class="author">
- <div class="author-name">C. Grothoff</div>
-<div class="org">Berner Fachhochschule</div>
-</div>
-<div class="author">
- <div class="author-name">B. Fix</div>
-<div class="org">GNUnet e.V.</div>
-</div>
-</dd>
-</dl>
-</div>
-<h1 id="title">The GNU Name System Specification</h1>
-<section id="section-abstract">
- <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
-<p id="section-abstract-1">This document contains the GNU Name System (GNS) technical specification.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
-</section>
-<div id="status-of-memo">
-<section id="section-boilerplate.1">
- <h2 id="name-status-of-this-memo">
-<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
- </h2>
-<p id="section-boilerplate.1-1">
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-2">
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF). Note that other groups may also distribute working
- documents as Internet-Drafts. The list of current Internet-Drafts is
- at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-3">
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-4">
- This Internet-Draft will expire on 13 May 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="copyright">
-<section id="section-boilerplate.2">
- <h2 id="name-copyright-notice">
-<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
- </h2>
-<p id="section-boilerplate.2-1">
- Copyright (c) 2019 IETF Trust and the persons identified as the
- document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.2-2">
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document. Code Components extracted from this
- document must include Simplified BSD License text as described in
- Section 4.e of the Trust Legal Provisions and are provided without
- warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="toc">
-<section id="section-toc.1">
- <a href="#" onclick="scroll(0,0)" class="toplink">â–²</a><h2 id="name-table-of-contents">
-<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
- </h2>
-<nav class="toc"><ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.1">
- <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.2">
- <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-zones" class="xref">Zones</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3">
- <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-resource-records" class="xref">Resource Records</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
- <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-record-types" class="xref">Record Types</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
- <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-pkey" class="xref">PKEY</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
- <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-gns2dns" class="xref">GNS2DNS</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.4">
- <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-leho" class="xref">LEHO</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.5">
- <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-nick" class="xref">NICK</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.6">
- <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-box" class="xref">BOX</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.3.2.7">
- <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-vpn" class="xref">VPN</a><a href="#section-toc.1-1.3.2.7.1" class="pilcrow">¶</a></p>
-</li>
-</ul>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.4">
- <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-publishing-records" class="xref">Publishing Records</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
- <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-key-derivations" class="xref">Key Derivations</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
- <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-resource-records-block" class="xref">Resource Records Block</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
- <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-record-data-encryption-and-" class="xref">Record Data Encryption and Decryption</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
-</li>
-</ul>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.5">
- <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-internationalization-and-ch" class="xref">Internationalization and Character Encoding</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6">
- <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-name-resolution" class="xref">Name Resolution</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
- <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-recursion" class="xref">Recursion</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
- <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-record-processing" class="xref">Record Processing</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.1">
- <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-pkey-2" class="xref">PKEY</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.2">
- <p id="section-toc.1-1.6.2.2.2.2.1"><a href="#section-6.2.2" class="xref">6.2.2</a>.  <a href="#name-gns2dns-2" class="xref">GNS2DNS</a><a href="#section-toc.1-1.6.2.2.2.2.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.3">
- <p id="section-toc.1-1.6.2.2.2.3.1"><a href="#section-6.2.3" class="xref">6.2.3</a>.  <a href="#name-cname" class="xref">CNAME</a><a href="#section-toc.1-1.6.2.2.2.3.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.4">
- <p id="section-toc.1-1.6.2.2.2.4.1"><a href="#section-6.2.4" class="xref">6.2.4</a>.  <a href="#name-box-2" class="xref">BOX</a><a href="#section-toc.1-1.6.2.2.2.4.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.5">
- <p id="section-toc.1-1.6.2.2.2.5.1"><a href="#section-6.2.5" class="xref">6.2.5</a>.  <a href="#name-vpn-2" class="xref">VPN</a><a href="#section-toc.1-1.6.2.2.2.5.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.6">
- <p id="section-toc.1-1.6.2.2.2.6.1"><a href="#section-6.2.6" class="xref">6.2.6</a>.  <a href="#name-nick-2" class="xref">NICK</a><a href="#section-toc.1-1.6.2.2.2.6.1" class="pilcrow">¶</a></p>
-</li>
-</ul>
-</li>
-</ul>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.7">
- <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-zone-revocation" class="xref">Zone Revocation</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.8">
- <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-determining-the-root-zone-a" class="xref">Determining the Root Zone and Zone Governance</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.9">
- <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
- <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-cryptography" class="xref">Cryptography</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
- <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-abuse-mitigation" class="xref">Abuse mitigation</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
- <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-zone-management" class="xref">Zone management</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.4">
- <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-impact-of-underlying-dht" class="xref">Impact of underlying DHT</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.5">
- <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-revocations" class="xref">Revocations</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
-</li>
-</ul>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.10">
- <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-gana-considerations" class="xref">GANA Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.11">
- <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-test-vectors" class="xref">Test Vectors</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.12">
- <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
-</li>
-<li class="toc ulEmpty" id="section-toc.1-1.13">
- <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
-</li>
-</ul>
-</nav>
-</section>
-</div>
-<div id="introduction">
-<section id="section-1">
- <h2 id="name-introduction">
-<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
- </h2>
-<p id="section-1-1">
- The Domain Name System (DNS) is a unique distributed database and a vital
- service for most Internet applications. While DNS is distributed, it
- relies on centralized, trusted registrars to provide globally unique
- names. As the awareness of the central role DNS plays on the Internet
- rises, various institutions are using their power (including legal means)
- to engage in attacks on the DNS, thus threatening the global availability
- and integrity of information on the Internet.<a href="#section-1-1" class="pilcrow">¶</a></p>
-<p id="section-1-2">
- DNS was not designed with security as a goal. This makes it very
- vulnerable, especially to attackers that have the technical capabilities
- of an entire nation state at their disposal.
- This specification describes a censorship-resistant, privacy-preserving
- and decentralized name system: The GNU Name System (GNS). It is designed
- to provide a secure alternative to DNS, especially when censorship or
- manipulation is encountered. GNS can bind names to any kind of
- cryptographically secured token, enabling it to double in some respects as
- even as an alternative to some of today's Public Key Infrastructures, in
- particular X.509 for the Web.<a href="#section-1-2" class="pilcrow">¶</a></p>
-<p id="section-1-3">
- This document contains the GNU Name System (GNS) technical specification
- of the GNU Name System <span>[<a href="#GNS" class="xref">GNS</a>]</span>, a fully decentralized and censorship-resistant
- name system. GNS provides a privacy-enhancing alternative to the Domain
- Name System (DNS). The design of GNS incorporates the capability to
- integrate and coexist with DNS. GNS is based on the principle of a petname
- system and builds on ideas from the Simple Distributed Security
- Infrastructure (SDSI), addressing a central issue with the decentralized
- mapping of secure identifiers to memorable names: namely the impossibility
- of providing a global, secure and memorable mapping without a trusted
- authority. GNS uses the transitivity in the SDSI design to replace the
- trusted root with secure delegation of authority thus making petnames
- useful to other users while operating under a very strong adversary model.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<p id="section-1-4">
- This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementors.<a href="#section-1-4" class="pilcrow">¶</a></p>
-<p id="section-1-5">
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
- NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
- "OPTIONAL" in this document are to be interpreted as described
- in <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
-<p id="section-1-6"><a href="#section-1-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="zones">
-<section id="section-2">
- <h2 id="name-zones">
-<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-zones" class="section-name selfRef">Zones</a>
- </h2>
-<p id="section-2-1">
- A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
- where d is the private key and zk the corresponding public key.
- GNS employs the curve parameters of the twisted edwards representation
- of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> (a.k.a. edwards25519)
- with the ECDSA scheme (<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>).
- In the following, we use the following naming convention for our
- cryptographic primitives:<a href="#section-2-1" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-2-2">
- <dt id="section-2-2.1">d</dt>
-<dd id="section-2-2.2">
- is a 256-bit ECDSA private key.
- In GNS, records are signed using a key derived from "d" as described in
- <a href="#publish" class="xref">Section 4</a>.<a href="#section-2-2.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-2-2.3">p</dt>
-<dd id="section-2-2.4">
- is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, i.e.
- 2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-2-2.5">B</dt>
-<dd id="section-2-2.6">
- is the group generator (X(P),Y(P)) of edwards25519 as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-2-2.7">L</dt>
-<dd id="section-2-2.8">
- is the prime-order subgroup of edwards25519 in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8" class="pilcrow">¶</a>
-</dd>
-<dt id="section-2-2.9">zk</dt>
-<dd id="section-2-2.10">
- is the ECDSA public key corresponding to d. It is defined in
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the curve point d*B where B is the group
- generator of the elliptic curve.
- The public key is used to uniquely identify a GNS zone and is referred to
- as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="rrecords">
-<section id="section-3">
- <h2 id="name-resource-records">
-<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-resource-records" class="section-name selfRef">Resource Records</a>
- </h2>
-<p id="section-3-1">
- A GNS implementor MUST provide a mechanism to create and manage resource
- records for local zones. A local zone is established by creating a zone
- key pair. Records may be added to each zone, hence a (local) persistency
- mechanism for resource records and zones must be provided.
- This local zone database is used by the GNS resolver implementation
- and to publish record information.<a href="#section-3-1" class="pilcrow">¶</a></p>
-<p id="section-3-2">
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:<a href="#section-3-2" class="pilcrow">¶</a></p>
-<div id="figure_gnsrecord">
-<figure id="figure-1">
- <div class="artwork art-text alignLeft" id="section-3-3.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| EXPIRATION |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| DATA SIZE | TYPE |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| FLAGS | DATA /
-+-----+-----+-----+-----+ /
-/ /
-/ /
- </pre>
-</div>
-<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
-</div>
-<p id="section-3-4">where:<a href="#section-3-4" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3-5">
- <dt id="section-3-5.1">EXPIRATION</dt>
-<dd id="section-3-5.2">
- denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-5.3">DATA SIZE</dt>
-<dd id="section-3-5.4">
- denotes the 32-bit size of the DATA field in bytes and in network byte
- order.<a href="#section-3-5.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-5.5">TYPE</dt>
-<dd id="section-3-5.6">
- is the 32-bit resource record type. This type can be one of the GNS resource
- records as defined in <a href="#rrecords" class="xref">Section 3</a> or a DNS record
- type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> or any of the
- complementary standardized DNS resource record types. This value must be
- stored in network byte order. Note that values
- below 2^16 are reserved for allocation via IANA (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-5.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-5.7">FLAGS</dt>
-<dd id="section-3-5.8">
- is a 32-bit resource record flags field (see below).<a href="#section-3-5.8" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-5.9">DATA</dt>
-<dd id="section-3-5.10">
- the variable-length resource record data payload. The contents are defined
- by the
- respective type of the resource record.<a href="#section-3-5.10" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-3-6">
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:<a href="#section-3-6" class="pilcrow">¶</a></p>
-<div id="figure_flag">
-<figure id="figure-2">
- <div class="artwork art-text alignLeft" id="section-3-7.1">
-<pre>
-... 5 4 3 2 1 0
-------+--------+--------+--------+--------+--------+
-/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
-------+--------+--------+--------+--------+--------+
- </pre>
-</div>
-<figcaption><a href="#figure-2" class="selfRef">Figure 2</a></figcaption></figure>
-</div>
-<p id="section-3-8">
- where:<a href="#section-3-8" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3-9">
- <dt id="section-3-9.1">SHADOW</dt>
-<dd id="section-3-9.2">
- If this flag is set, this record should be ignored by resolvers unless all (other)
- records of the same record type have expired. Used to allow zone publishers to
- facilitate good performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can propagate and may be
- cached before the transition becomes active.<a href="#section-3-9.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-9.3">EXPREL</dt>
-<dd id="section-3-9.4">
- The expiration time value of the record is a relative time (still in microseconds)
- and not an absolute time. This flag should never be encountered by a resolver
- for records obtained from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.<a href="#section-3-9.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-9.5">
- SUPPL
- </dt>
-<dd id="section-3-9.6">
- This is a supplemental record. It is provided in addition to the
- other records. This flag indicates that this record is not explicitly
- managed alongside the other records under the respective name but
- may be useful for the application. This flag should only be encountered
- by a resolver for records obtained from the DHT.<a href="#section-3-9.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3-9.7">PRIVATE</dt>
-<dd id="section-3-9.8">
- This is a private record of this peer and it should thus not be
- published in the DHT. Thus, this flag should never be encountered by
- a resolver for records obtained from the DHT.
- Private records should still be considered just like
- regular records when resolving labels in local zones.<a href="#section-3-9.8" class="pilcrow">¶</a>
-</dd>
-</dl>
-<div id="gnsrecords_numbers">
-<section id="section-3.1">
- <h3 id="name-record-types">
-<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-record-types" class="section-name selfRef">Record Types</a>
- </h3>
-<p id="section-3.1-1">
- A registry of GNS Record Types is described in Section 10. The
- registration policy for this registry is "First Come First Served", as
- described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. When requesting new entries, careful
- consideration of the following criteria is strongly advised:
- FIXME: ausdenken was wir da gerne haetten.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="gnsrecords_pkey">
-<section id="section-3.2">
- <h3 id="name-pkey">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-pkey" class="section-name selfRef">PKEY</a>
- </h3>
-<p id="section-3.2-1">In GNS, a delegation of a label to a zone is represented through a PKEY
- record. A PKEY resource record contains the public key of the zone to
- delegate to. A PKEY record MUST be the only record under a label. No other
- records are allowed. A PKEY DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
-<div id="figure_pkeyrecord">
-<figure id="figure-3">
- <div class="artwork art-text alignLeft" id="section-3.2-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PUBLIC KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
-</div>
-<p id="section-3.2-3">
- where:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.2-4">
- <dt id="section-3.2-4.1">PUBLIC KEY</dt>
-<dd id="section-3.2-4.2">
- A 256-bit ECDSA zone key.<a href="#section-3.2-4.2" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="gnsrecords_gns2dns">
-<section id="section-3.3">
- <h3 id="name-gns2dns">
-<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
- </h3>
-<p id="section-3.3-1">It is possible to delegate a label back into DNS through a GNS2DNS record.
- The resource record contains a DNS name for the resolver to continue with
- in DNS followed by a DNS server. Both names are in the format defined in
- <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
- A GNS2DNS DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
-<div id="figure_gns2dnsrecord">
-<figure id="figure-4">
- <div class="artwork art-text alignLeft" id="section-3.3-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| DNS NAME |
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| DNS SERVER NAME |
-/ /
-/ /
-| |
-+-----------------------------------------------+
- </pre>
-</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
-</div>
-<p id="section-3.3-3">
- where:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.3-4">
- <dt id="section-3.3-4.1">DNS NAME</dt>
-<dd id="section-3.3-4.2">
- The name to continue with in DNS (0-terminated).<a href="#section-3.3-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.3-4.3">DNS SERVER NAME</dt>
-<dd id="section-3.3-4.4">
- The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
- form or a DNS name. It may also be a relative GNS name ending with a
- "+" top-level domain. The value is UTF-8 encoded (also for DNS names)
- and 0-terminated.<a href="#section-3.3-4.4" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="gnsrecords_leho">
-<section id="section-3.4">
- <h3 id="name-leho">
-<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-leho" class="section-name selfRef">LEHO</a>
- </h3>
-<p id="section-3.4-1">Legacy hostname records can be used by applications that are expected
- to supply a DNS name on the application layer. The most common use case
- is HTTP virtual hosting, which as-is would not work with GNS names as
- those may not be globally unique.
-
- A LEHO resource record is expected to be found together in a single
- resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
-<div id="figure_lehorecord">
-<figure id="figure-5">
- <div class="artwork art-text alignLeft" id="section-3.4-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| LEGACY HOSTNAME |
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
-</div>
-<p id="section-3.4-3">
- where:<a href="#section-3.4-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.4-4">
- <dt id="section-3.4-4.1">LEGACY HOSTNAME</dt>
-<dd id="section-3.4-4.2">
- A UTF-8 string (which is not 0-terminated) representing the legacy hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-3.4-5">
- NOTE: If an application uses a LEHO value in an HTTP request header
- (e.g. "Host:" header) it must be converted to a punycode representation
- <span>[<a href="#RFC5891" class="xref">RFC5891</a>]</span>.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="gnsrecords_nick">
-<section id="section-3.5">
- <h3 id="name-nick">
-<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-nick" class="section-name selfRef">NICK</a>
- </h3>
-<p id="section-3.5-1">
- Nickname records can be used by zone administrators to publish an
- indication on what label this zone prefers to be referred to.
- This is a suggestion to other zones what label to use when creating a
- PKEY (<a href="#gnsrecords_pkey" class="xref">Section 3.2</a>) record containing this zone's
- public zone key.
- This record SHOULD only be stored under the empty label "@" but MAY be
- returned with record sets under any label as a supplemental record.
- <a href="#nick_processing" class="xref">Section 6.2.6</a> details how a resolver must process
- supplemental and non-supplemental NICK records.
- A NICK DATA entry has the following format:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
-<div id="figure_nickrecord">
-<figure id="figure-6">
- <div class="artwork art-text alignLeft" id="section-3.5-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| NICKNAME |
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure>
-</div>
-<p id="section-3.5-3">
- where:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.5-4">
- <dt id="section-3.5-4.1">NICKNAME</dt>
-<dd id="section-3.5-4.2">
- A UTF-8 string (which is not 0-terminated) representing the preferred
- label of the zone. This string MUST NOT include a "." character.<a href="#section-3.5-4.2" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="gnsrecords_box">
-<section id="section-3.6">
- <h3 id="name-box">
-<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-box" class="section-name selfRef">BOX</a>
- </h3>
-<p id="section-3.6-1">
- In GNS, every "." in a name delegates to another zone, and
- GNS lookups are expected to return all of the required useful
- information in one record set. This 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. For example, a
- TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
- (tcp) and record TYPE "TLSA".
- For reference, see also <span>[<a href="#RFC2782" class="xref">RFC2782</a>]</span>.
- A BOX DATA entry has the following format:<a href="#section-3.6-1" class="pilcrow">¶</a></p>
-<div id="figure_boxrecord">
-<figure id="figure-7">
- <div class="artwork art-text alignLeft" id="section-3.6-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PROTO | SVC | TYPE |
-+-----------+-----------------------------------+
-| RECORD DATA |
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure 7</a></figcaption></figure>
-</div>
-<p id="section-3.6-3">
- where:<a href="#section-3.6-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.6-4">
- <dt id="section-3.6-4.1">PROTO</dt>
-<dd id="section-3.6-4.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.6-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.6-4.3">SVC</dt>
-<dd id="section-3.6-4.4">
- the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.6-4.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.6-4.5">TYPE</dt>
-<dd id="section-3.6-4.6">
- is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.6-4.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.6-4.7">RECORD DATA</dt>
-<dd id="section-3.6-4.8">
- is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.6-4.8" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="gnsrecords_vpn">
-<section id="section-3.7">
- <h3 id="name-vpn">
-<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-vpn" class="section-name selfRef">VPN</a>
- </h3>
-<p id="section-3.7-1">
- A VPN DATA entry has the following format:<a href="#section-3.7-1" class="pilcrow">¶</a></p>
-<div id="figure_vpnrecord">
-<figure id="figure-8">
- <div class="artwork art-text alignLeft" id="section-3.7-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| HOSTING PEER PUBLIC KEY |
-| (256 bits) |
-| |
-| |
-+-----------+-----------------------------------+
-| PROTO | SERVICE NAME |
-+-----------+ +
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
-</div>
-<p id="section-3.7-3">
- where:<a href="#section-3.7-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.7-4">
- <dt id="section-3.7-4.1">HOSTING PEER PUBLIC KEY</dt>
-<dd id="section-3.7-4.2">
- is a 256-bit EdDSA public key identifying the peer hosting the
- service.<a href="#section-3.7-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.7-4.3">PROTO</dt>
-<dd id="section-3.7-4.4">
- the 16-bit protocol number, e.g. 6 for TCP. In network byte order.<a href="#section-3.7-4.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-3.7-4.5">SERVICE NAME</dt>
-<dd id="section-3.7-4.6">
- a shared secret used to identify the service at the hosting peer,
- used to derive the port number requird to connect to the service.
- The service name MUST be a 0-terminated UTF-8 string.<a href="#section-3.7-4.6" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-</section>
-</div>
-<div id="publish">
-<section id="section-4">
- <h2 id="name-publishing-records">
-<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-publishing-records" class="section-name selfRef">Publishing Records</a>
- </h2>
-<p id="section-4-1">
- GNS resource records are published in a distributed hash table (DHT).
- We assume that a DHT provides two functions: GET(key) and PUT(key,value).
- In GNS, resource records are grouped by their respective labels,
- encrypted and published together in a single resource records block
- (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
- The key "q" which is derived from the zone key "zk" and the respective
- label of the contained records.<a href="#section-4-1" class="pilcrow">¶</a></p>
-<div id="blinding">
-<section id="section-4.1">
- <h3 id="name-key-derivations">
-<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-key-derivations" class="section-name selfRef">Key Derivations</a>
- </h3>
-<p id="section-4.1-1">
- Given a label, the DHT key "q" is derived as follows:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.1-2">
-<pre>
-PRK_h := HKDF-Extract ("key-derivation", zk)
-h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-d_h := h * d mod L
-zk_h := h mod L * zk
-q := SHA512 (zk_h)
- </pre><a href="#section-4.1-2" class="pilcrow">¶</a>
-</div>
-<p id="section-4.1-3">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.1-4">
- <dt id="section-4.1-4.1">PRK_h</dt>
-<dd id="section-4.1-4.2">
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "zk" as initial
- keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.3">h</dt>
-<dd id="section-4.1-4.4">
- is the 512-bit HKDF expansion result. The expansion info input is a
- concatenation of the label and string "gns".<a href="#section-4.1-4.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.5">d</dt>
-<dd id="section-4.1-4.6">
- is the 256-bit private zone key as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.7">label</dt>
-<dd id="section-4.1-4.8">
- is a UTF-8 string under which the resource records are published.<a href="#section-4.1-4.8" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.9">d_h</dt>
-<dd id="section-4.1-4.10">
- is a 256-bit private key derived from the "d" using the
- keying material "h".<a href="#section-4.1-4.10" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.11">zk_h</dt>
-<dd id="section-4.1-4.12">
- is a 256-bit public key derived from the zone key "zk" using the
- keying material "h".<a href="#section-4.1-4.12" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.13">L</dt>
-<dd id="section-4.1-4.14">
- is the prime-order subgroup as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-4.14" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.1-4.15">q</dt>
-<dd id="section-4.1-4.16">
- Is the 512-bit DHT key under which the resource records block is
- published.
- It is the SHA512 hash over the public key "zk_h" corresponding to the
- derived private key "d_h".<a href="#section-4.1-4.16" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-4.1-5">
- We point out that the multiplication of "zk" with "h" is a point multiplication,
- while the multiplication of "d" with "h" is a scalar multiplication.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="wire">
-<section id="section-4.2">
- <h3 id="name-resource-records-block">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-resource-records-block" class="section-name selfRef">Resource Records Block</a>
- </h3>
-<p id="section-4.2-1">
- GNS records are grouped by their labels and published as a single
- block in the DHT. The grouped record sets MAY be paired with any
- number of supplemental records. Supplemental records must have the
- supplemental flag set (See <a href="#rrecords" class="xref">Section 3</a>).
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS implementation must publish RRBLOCKs
- in accordance to the properties and recommendations of the underlying
- DHT. This may include a periodic refresh publication.
- A GNS RRBLOCK has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
-<div id="figure_record_block">
-<figure id="figure-9">
- <div class="artwork art-text alignLeft" id="section-4.2-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIGNATURE |
-| |
-| |
-| |
-| |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PUBLIC KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIZE | PURPOSE |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| EXPIRATION |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| BDATA /
-/ /
-/ |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
-</div>
-<p id="section-4.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.2-4">
- <dt id="section-4.2-4.1">SIGNATURE</dt>
-<dd id="section-4.2-4.2">
- A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The signature is computed over the data
- following the PUBLIC KEY field.
- The signature is created using the derived private key "d_h" (see
- <a href="#publish" class="xref">Section 4</a>).<a href="#section-4.2-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.2-4.3">PUBLIC KEY</dt>
-<dd id="section-4.2-4.4">
- is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
- wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.2-4.5">SIZE</dt>
-<dd id="section-4.2-4.6">
- A 32-bit value containing the length of the signed data following the
- PUBLIC KEY field in network byte order. This value always includes the
- length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
- addition to the length of the BDATA. While a 32-bit value is used,
- implementations MAY refuse to publish blocks beyond a certain
- size significantly below 4 GB. However, a minimum block size of
- 62 kilobytes MUST be supported.<a href="#section-4.2-4.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.2-4.7">PURPOSE</dt>
-<dd id="section-4.2-4.8">
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.2-4.9">EXPIRATION</dt>
-<dd id="section-4.2-4.10">
- Specifies when the RRBLOCK expires and the encrypted block
- SHOULD be removed from the DHT and caches as it is likely stale.
- However, applications MAY continue to use non-expired individual
- records until they expire. The value MUST be set to the
- expiration time of the resource record contained within this block with the
- smallest expiration time.
- If a records block includes shadow records, then the maximum
- expiration time of all shadow records with matching type and the
- expiration times of the non-shadow records is considered.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.<a href="#section-4.2-4.10" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.2-4.11">BDATA</dt>
-<dd id="section-4.2-4.12">
- The encrypted resource records with a total size of SIZE - 16.<a href="#section-4.2-4.12" class="pilcrow">¶</a>
-</dd>
-</dl>
-</section>
-</div>
-<div id="recordencryption">
-<section id="section-4.3">
- <h3 id="name-record-data-encryption-and-">
-<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-record-data-encryption-and-" class="section-name selfRef">Record Data Encryption and Decryption</a>
- </h3>
-<p id="section-4.3-1">
- A symmetric encryption scheme is used to encrypt the resource records
- set RDATA into the BDATA field of a GNS RRBLOCK.
- The wire format of the RDATA looks as follows:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
-<div id="figure_rdata">
-<figure id="figure-10">
- <div class="artwork art-text alignLeft" id="section-4.3-2.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| RR COUNT | EXPIRA- /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-/ -TION | DATA SIZE |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TYPE | FLAGS |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| DATA /
-/ /
-/ |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| EXPIRATION |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| DATA SIZE | TYPE |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| FLAGS | DATA /
-+-----+-----+-----+-----+ /
-/ +-----------------------/
-/ | /
-+-----------------------+ /
-/ PADDING /
-/ /
- </pre>
-</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
-</div>
-<p id="section-4.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.3-4">
- <dt id="section-4.3-4.1">RR COUNT</dt>
-<dd id="section-4.3-4.2">
- A 32-bit value containing the number of variable-length resource
- records which are
- following after this field in network byte order.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.3-4.3">EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
-<dd id="section-4.3-4.4">
- These fields were defined
- in the resource record format in <a href="#rrecords" class="xref">Section 3</a>.
- There MUST be a total of RR COUNT of these resource records
- present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-4.3-4.5">PADDING</dt>
-<dd id="section-4.3-4.6">
- The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA WITHOUT the RR
- COUNT field is a power of two.
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST NOT
- contain other records.<a href="#section-4.3-4.6" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-4.3-5">
- The symmetric keys and initialization vectors are derived from the
- record label and the zone key "zk". For decryption of the resource
- records block payload, the key material "K" and initialization vector
- "IV" for the symmetric cipher are derived as follows:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-6">
-<pre>
-PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
-PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
-K := HKDF-Expand (PRK_k, label, 512 / 8);
-IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
-</div>
-<p id="section-4.3-7">
- HKDF is a hash-based key derivation function as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
- extraction phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vectors.
- We divide the resulting keying material "K" into a 256-bit AES
- <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
- and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-7" class="pilcrow">¶</a></p>
-<div id="figure_hkdf_keys">
-<figure id="figure-11">
- <div class="artwork art-text alignLeft" id="section-4.3-8.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| AES KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TWOFISH KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure>
-</div>
-<p id="section-4.3-9">
- Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
-<div id="figure_hkdf_ivs">
-<figure id="figure-12">
- <div class="artwork art-text alignLeft" id="section-4.3-10.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| AES IV |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TWOFISH IV |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure 12</a></figcaption></figure>
-</div>
-<p id="section-4.3-11">
- The keys and IVs are used for a CFB128-AES-256 and
- CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
- Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-11" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-12">
-<pre>
-RDATA := AES(K[0:31], IV[0:15],
- TWOFISH(K[32:63], IV[16:31], BDATA))
-BDATA := TWOFISH(K[32:63], IV[16:31],
- AES(K[0:31], IV[0:15], RDATA))
- </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="encoding">
-<section id="section-5">
- <h2 id="name-internationalization-and-ch">
-<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-internationalization-and-ch" class="section-name selfRef">Internationalization and Character Encoding</a>
- </h2>
-<p id="section-5-1">
- All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>.
- This does not include any DNS names found in DNS records, such as CNAME
- records, which are internationalized through the IDNA specifications
- <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="resolution">
-<section id="section-6">
- <h2 id="name-name-resolution">
-<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-name-resolution" class="section-name selfRef">Name Resolution</a>
- </h2>
-<p id="section-6-1">
- Names in GNS are resolved by recursively querying the DHT record storage.
- In the following, we define how resolution is initiated and each
- iteration in the resolution is processed.<a href="#section-6-1" class="pilcrow">¶</a></p>
-<p id="section-6-2">
- GNS resolution of a name must start in a given starting zone indicated using
- a zone public key.
- Details on how the starting zone may be determined is discussed in
- <a href="#governance" class="xref">Section 8</a>.<a href="#section-6-2" class="pilcrow">¶</a></p>
-<p id="section-6-3">
- When GNS name resolution is requested, a desired record type MAY be
- provided by the client.
- The GNS resolver will use the desired record type to guide
- processing, for example by providing conversion of VPN records to A
- or AAAA records, if that is desired.
-
- However, filtering of record sets according to the required record
- types MUST still be done by the client after the resource record set
- is retrieved.<a href="#section-6-3" class="pilcrow">¶</a></p>
-<div id="recursion">
-<section id="section-6.1">
- <h3 id="name-recursion">
-<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-recursion" class="section-name selfRef">Recursion</a>
- </h3>
-<p id="section-6.1-1">
- In each step of the recursive name resolution, there is an
- authoritative zone zk and a name to resolve. The name may be empty.
- Initially, the authoritative zone is the start zone. If the name
- is empty, it is interpreted as the apex label "@".<a href="#section-6.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.1-2">
- From here, the following steps are recursively executed, in order:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.1-3">
- <li id="section-6.1-3.1">Extract the right-most label from the name to look up.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
-</li>
-<li id="section-6.1-3.2">Calculate q using the label and zk as defined in
- <a href="#blinding" class="xref">Section 4.1</a>.<a href="#section-6.1-3.2" class="pilcrow">¶</a>
-</li>
-<li id="section-6.1-3.3">Perform a DHT query GET(q) to retrieve the RRBLOCK.<a href="#section-6.1-3.3" class="pilcrow">¶</a>
-</li>
-<li id="section-6.1-3.4">Verify and process the RRBLOCK and decrypt the BDATA contained
- in it as defined in <a href="#recordencryption" class="xref">Section 4.3</a>.<a href="#section-6.1-3.4" class="pilcrow">¶</a>
-</li>
-</ol>
-<p id="section-6.1-4">
- Upon receiving the RRBLOCK from the DHT, apart from verifying the
- provided signature, the resolver MUST check that the authoritative
- zone key was used to sign the record:
- The derived zone key "h*zk" MUST match the public key provided in
- the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT lookup
- GET(q) MUST continue.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="record_processing">
-<section id="section-6.2">
- <h3 id="name-record-processing">
-<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-record-processing" class="section-name selfRef">Record Processing</a>
- </h3>
-<p id="section-6.2-1">
- Record processing occurs at the end of a single recursion. We assume
- that the RRBLOCK has been cryptographically verified and decrypted.
- At this point, we must first determine if we have received a valid
- record set in the context of the name we are trying to resolve:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.2-2">
- <li id="section-6.2-2.1">
- Case 1:
- If the remainder of the name to resolve is empty and the record set
- does not consist of a PKEY, CNAME or DNS2GNS record, the record set
- is the result and the recursion is concluded.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
-</li>
-<li id="section-6.2-2.2">
- Case 2:
- If 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 the result and the recusion
- is concluded (<a href="#box_processing" class="xref">Section 6.2.4</a>).<a href="#section-6.2-2.2" class="pilcrow">¶</a>
-</li>
-<li id="section-6.2-2.3">
- Case 3:
- If the remainder of the name to resolve is not empty and
- does not match the "_SERVICE._PROTO" syntax, then the current record set
- MUST consist of a single PKEY record (<a href="#pkey_processing" class="xref">Section 6.2.1</a>),
- a single CNAME record (<a href="#cname_processing" class="xref">Section 6.2.3</a>),
- or one or more GNS2DNS records (<a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
- which are processed as described in the respective sections below.
- The record set may include any number of supplemental records.
- Otherwise, resolution fails
- and the resolver MUST return an empty record set.
-
- Finally, after the recursion terminates, the client preferences
- for the record type SHOULD be considered. If a VPN record is found
- and the client requests an A or AAAA record, the VPN record
- SHOULD be converted (<a href="#vpn_processing" class="xref">Section 6.2.5</a>)
- if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
-</li>
-</ol>
-<div id="pkey_processing">
-<section id="section-6.2.1">
- <h4 id="name-pkey-2">
-<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-pkey-2" class="section-name selfRef">PKEY</a>
- </h4>
-<p id="section-6.2.1-1">
- When the resolver encounters a PKEY record and the remainder of
- the name is not empty, resolution continues
- recursively with the remainder of the name in the
- GNS zone specified in the PKEY record.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-2">
- If the remainder of the name to resolve is empty and we have
- received a record set containing only a single PKEY record, the
- recursion is continued with the PKEY as authoritative zone and
- the empty apex label "@" as remaining name, except in the case
- where the desired record type is PKEY, in which case the PKEY
- record is returned and the resolution is concluded without
- resolving the empty apex label.<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="gns2dns_processing">
-<section id="section-6.2.2">
- <h4 id="name-gns2dns-2">
-<a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a href="#name-gns2dns-2" class="section-name selfRef">GNS2DNS</a>
- </h4>
-<p id="section-6.2.2-1">
- When a resolver encounters one or more GNS2DNS records and the remaining name
- is empty and the desired record type is GNS2DNS, the GNS2DNS
- records are returned.<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-2">
- Otherwise, it is expected that the resolver first resolves the
- IP(s) of the specified DNS name server(s). GNS2DNS records MAY
- contain numeric IPv4 or IPv6 addresses, allowing the resolver to
- skip this step.
- The DNS server names may themselves be names in GNS or DNS.
- If the DNS server name ends in ".+", the rest of the name is to be
- interpreted relative to the zone of the GNS2DNS record.
- If the DNS server name ends in ".<Base32(zk)>", the DNS
- server name is to be resolved against the GNS zone zk.<a href="#section-6.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-3">
- Multiple GNS2DNS records may be stored under the same label,
- in which case the resolver MUST try all of them.
- The resolver MAY try them in any order or even in parallel.
- If multiple GNS2DNS records are present, the DNS name MUST be
- identical for all of them, if not the resolution fails and an
- emtpy record set is returned as the record set is invalid.<a href="#section-6.2.2-3" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-4">
- Once the IP addresses of the DNS servers have been determined,
- the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the DNS name server(s). As the DNS servers
- specified are possibly authoritative DNS servers, the GNS resolver MUST
- support recursive resolution and MUST NOT delegate this to the
- authoritative DNS servers.
- The first successful recursive name resolution result
- is returned to the client.
- In addition, the resolver returns the queried DNS name as a
- supplemental LEHO record (<a href="#gnsrecords_leho" class="xref">Section 3.4</a>) with a
- relative expiration time of one hour.<a href="#section-6.2.2-4" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-5">
- GNS resolvers SHOULD offer a configuration
- option to disable DNS processing to avoid information leakage
- and provide a consistent security profile for all name resolutions.
- Such resolvers would return an empty record set upon encountering
- a GNS2DNS record during the recursion. However, if GNS2DNS records
- are encountered in the record set for the apex and a GNS2DNS record
- is expicitly requested by the application, such records MUST
- still be returned, even if DNS support is disabled by the
- GNS resolver configuration.<a href="#section-6.2.2-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="cname_processing">
-<section id="section-6.2.3">
- <h4 id="name-cname">
-<a href="#section-6.2.3" class="section-number selfRef">6.2.3. </a><a href="#name-cname" class="section-name selfRef">CNAME</a>
- </h4>
-<p id="section-6.2.3-1">
- If a CNAME record is encountered, the canonical name is
- appended to the remaining name, except if the remaining name
- is empty and the desired record type is CNAME, in which case
- the resolution concludes with the CNAME record.
- If the canonical name ends in ".+",
- resolution continues in GNS with the new name in the
- current zone. Otherwise, the resulting name is resolved via the
- default operating system name resolution process.
- This may in turn again trigger a GNS resolution process depending
- on the system configuration.<a href="#section-6.2.3-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.3-2">
- The recursive DNS resolution process may yield a CNAME as well
- which in turn may either point into the DNS or GNS namespace
- (if it ends in a ".<Base32(zk)>").
- In order to prevent infinite loops, the resolver MUST
- implement loop detections or limit the number of recursive
- resolution steps.
- If the last CNAME was a DNS name, the resolver returns the DNS name
- as a supplemental LEHO record (<a href="#gnsrecords_leho" class="xref">Section 3.4</a>)
- with a relative expiration time of one hour.<a href="#section-6.2.3-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="box_processing">
-<section id="section-6.2.4">
- <h4 id="name-box-2">
-<a href="#section-6.2.4" class="section-number selfRef">6.2.4. </a><a href="#name-box-2" class="section-name selfRef">BOX</a>
- </h4>
-<p id="section-6.2.4-1">
- 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.<a href="#section-6.2.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="vpn_processing">
-<section id="section-6.2.5">
- <h4 id="name-vpn-2">
-<a href="#section-6.2.5" class="section-number selfRef">6.2.5. </a><a href="#name-vpn-2" class="section-name selfRef">VPN</a>
- </h4>
-<p id="section-6.2.5-1">
- At the end of the recursion,
- if the queried record type is either A or AAAA and the retrieved
- record set contains at least one VPN record, the resolver SHOULD
- open a tunnel and return the IPv4 or IPv6 tunnel address,
- respectively.
- The type of tunnel depends on the contents of the VPN record data.
- The VPN record MUST be returned if the resolver implementation
- does not support setting up a tunnnel.<a href="#section-6.2.5-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="nick_processing">
-<section id="section-6.2.6">
- <h4 id="name-nick-2">
-<a href="#section-6.2.6" class="section-number selfRef">6.2.6. </a><a href="#name-nick-2" class="section-name selfRef">NICK</a>
- </h4>
-<p id="section-6.2.6-1">
- NIICK records are only relevant to the recursive resolver
- if the record set in question is the final result which is to
- be returned to the client. The encountered NICK records may either
- be supplemental (see <a href="#rrecords" class="xref">Section 3</a>) or
- non-supplemental.
- If the NICK record is supplemental, the resolver only returns the
- record set if one of the non-supplemental records matches the
- queried record type.<a href="#section-6.2.6-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.6-2">
- The differentiation between a supplemental and non-supplemental
- NICK record allows the client to match the record to the
- authoritative zone. Consider the following example:<a href="#section-6.2.6-2" class="pilcrow">¶</a></p>
-<figure id="figure-13">
- <div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
-<pre>
-Query: alice.doe (type=A)
-Result:
-A: 1.2.3.4
-NICK: eve
- </pre>
-</div>
-<figcaption><a href="#figure-13" class="selfRef">Figure 13</a></figcaption></figure>
-<p id="section-6.2.6-4">
- In this example, the returned NICK record is non-supplemental.
- For the client, this means that the NICK belongs to the zone
- "alice.doe" and is published under the empty label along with an A
- record. The NICK record should be interpreted as: The zone defined by
- "alice.doe" wants to be referred to as "eve".
- In contrast, consider the following:<a href="#section-6.2.6-4" class="pilcrow">¶</a></p>
-<figure id="figure-14">
- <div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
-<pre>
-Query: alice.doe (type=A)
-Result:
-A: 1.2.3.4
-NICK: john (Supplemental)
- </pre>
-</div>
-<figcaption><a href="#figure-14" class="selfRef">Figure 14</a></figcaption></figure>
-<p id="section-6.2.6-6">
- In this case, the NICK record is marked as supplemental. This means that
- the NICK record belongs to the zone "doe" and is published under the
- label "alice" along with an A record. The NICK record should be
- interpreted as: The zone defined by "doe" wants to be referred to as
- "john". This distinction is likely useful for other records published as
- supplemental.<a href="#section-6.2.6-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="revocation">
-<section id="section-7">
- <h2 id="name-zone-revocation">
-<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-zone-revocation" class="section-name selfRef">Zone Revocation</a>
- </h2>
-<p id="section-7-1">
- Whenever a recursive resolver encounters a new GNS zone, it MUST
- check against the local revocation list whether the respective
- zone key has been revoked. If the zone key was revoked, the
- resolution MUST fail with an empty result set.<a href="#section-7-1" class="pilcrow">¶</a></p>
-<p id="section-7-2">
- In order to revoke a zone key, a signed revocation object SHOULD be
- published.
- This object MUST be signed using the private zone key.
- The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message MUST contain a proof of work
- (PoW).
- The revocation message including the PoW MAY be calculated
- ahead of time to support timely revocation.<a href="#section-7-2" class="pilcrow">¶</a></p>
-<p id="section-7-3">
- For all occurences below, "Argon2d" is the Password-based Key
- Derivation Function as defined in <span>[<a href="#Argon2" class="xref">Argon2</a>]</span>. For the
- PoW calculations the algorithm is instantiated with the
- following parameters:<a href="#section-7-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-7-4">
-<pre>
-S := "gnunet-revocation-proof-of-work" /* Salt */
-t := 3 /* Iterations */
-m := 1024 /* Memory size, 1 MiB */
-T := 64 /* Tag (=output) length in bytes */
-p := 1 /* Parallelization parameter */
-v := 0x13 /* Version */
-y := 0 /* Type (Argon2d) */
-X, K is unused
- </pre><a href="#section-7-4" class="pilcrow">¶</a>
-</div>
-<p id="section-7-5">
- The following is the message string "P" on which the PoW is
- calculated:<a href="#section-7-5" class="pilcrow">¶</a></p>
-<div id="figure_revocation">
-<figure id="figure-15">
- <div class="artwork art-text alignLeft" id="section-7-6.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| POW |
-+-----------------------------------------------+
-| TIMESTAMP |
-+-----------------------------------------------+
-| PUBLIC KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-15" class="selfRef">Figure 15</a></figcaption></figure>
-</div>
-<p id="section-7-7">where:<a href="#section-7-7" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-8">
- <dt id="section-7-8.1">POW</dt>
-<dd id="section-7-8.2">
- A 64-bit solution to the PoW.<a href="#section-7-8.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-8.3">TIMESTAMP</dt>
-<dd id="section-7-8.4">
- denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-7-8.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-8.5">PUBLIC KEY</dt>
-<dd id="section-7-8.6">
- A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the public zone zk of the zone
- which is revoked and corresponds to the key used in the PoW.
- The signature is created using the private zone key "d" (see
- <a href="#zones" class="xref">Section 2</a>).<a href="#section-7-8.6" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-7-9">
- Traditionally, PoW schemes require to find a "POW" such that
- at least D leading zeroes are found in the hash result.
- D is then referred to as the "difficulty" of the PoW.
- In order to reduce the variance in time it takes to calculate the
- PoW, we require that a number "Z" different PoWs must be
- found that on average have "D" leading zeroes.<a href="#section-7-9" class="pilcrow">¶</a></p>
-<p id="section-7-10">
- The resulting proofs may then published and disseminated. The concrete
- dissemination and publication methods are out of scope of this
- document. Given an average difficulty of "D", the proofs have an
- expiration time of EPOCH. With each additional bit difficulty, the
- lifetime of the proof is prolonged for another EPOCH.
- Consequently, by calculating a more difficult PoW, the lifetime of the
- proof can be increased on demand by the zone owner.<a href="#section-7-10" class="pilcrow">¶</a></p>
-<p id="section-7-11">
- The parameters are defined as follows:<a href="#section-7-11" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-12">
- <dt id="section-7-12.1">Z</dt>
-<dd id="section-7-12.2">The number of PoWs required is fixed at 32.<a href="#section-7-12.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-12.3">D</dt>
-<dd id="section-7-12.4">The difficulty is fixed at 25.<a href="#section-7-12.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-12.5">EPOCH</dt>
-<dd id="section-7-12.6">A single epoch is fixed at 365 days.<a href="#section-7-12.6" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-7-13">
- Given that proof has been found, a revocation data object is defined
- as follows:<a href="#section-7-13" class="pilcrow">¶</a></p>
-<div id="figure_revocationdata">
-<figure id="figure-16">
- <div class="artwork art-text alignLeft" id="section-7-14.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TIMESTAMP |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TTL |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| POW_0 |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| ... |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| POW_Z-1 |
-+-----------------------------------------------+
-| SIGNATURE |
-| |
-| |
-| |
-| |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PUBLIC KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-16" class="selfRef">Figure 16</a></figcaption></figure>
-</div>
-<p id="section-7-15">where:<a href="#section-7-15" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-16">
- <dt id="section-7-16.1">TIMESTAMP</dt>
-<dd id="section-7-16.2">
- denotes the absolute 64-bit expiration date of the revocation.
- In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-7-16.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-16.3">TTL</dt>
-<dd id="section-7-16.4">
- denotes the relative 64-bit time to live of of the record in
- microseconds also in network byte order. This field is informational
- for a verifier. The verifier may discard revocation if the TTL
- indicates that it is already expired. However, the actual TTL of the
- revocation must be determined by examining the leading zeros in the
- proof of work calculation.<a href="#section-7-16.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-16.5">POW_i</dt>
-<dd id="section-7-16.6">
- The values calculated as part of the PoW. Each POW_i MUST
- be unique in the set of POW values.<a href="#section-7-16.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-16.7">SIGNATURE</dt>
-<dd id="section-7-16.8">
- A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the public zone zk of the zone
- which is revoked and corresponds to the key used in the PoW.
- The signature is created using the private zone key "d" (see
- <a href="#zones" class="xref">Section 2</a>).<a href="#section-7-16.8" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-16.9">PUBLIC KEY</dt>
-<dd id="section-7-16.10">
- is the 256-bit public key "zk" of the zone which is being revoked and
- the key to be used to verify SIGNATURE. The
- wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-7-16.10" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-7-17">
- The signature over the public key covers a 32 bit pseudo header
- conceptually prefixed to the public key. The pseudo header includes
- the key length and signature purpose:<a href="#section-7-17" class="pilcrow">¶</a></p>
-<div id="figure_revsigwithpseudo">
-<figure id="figure-17">
- <div class="artwork art-text alignLeft" id="section-7-18.1">
-<pre>
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIZE (0x30) | PURPOSE (0x03) |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PUBLIC KEY |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TIMESTAMP |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
-</div>
-<figcaption><a href="#figure-17" class="selfRef">Figure 17</a></figcaption></figure>
-</div>
-<p id="section-7-19">where:<a href="#section-7-19" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-20">
- <dt id="section-7-20.1">SIZE</dt>
-<dd id="section-7-20.2">
- A 32-bit value containing the length of the signed data in bytes
- (48 bytes) in network byte order.<a href="#section-7-20.2" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-20.3">PURPOSE</dt>
-<dd id="section-7-20.4">
- A 32-bit signature purpose flag. This field MUST be 3 (in network
- byte order).<a href="#section-7-20.4" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-20.5">PUBLIC KEY / TIMESTAMP</dt>
-<dd id="section-7-20.6">Both values as defined in the revocation data object above.<a href="#section-7-20.6" class="pilcrow">¶</a>
-</dd>
-</dl>
-<p id="section-7-21">
- In order to verify a revocation the following steps must be taken,
- in order:<a href="#section-7-21" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-7-22">
- <li id="section-7-22.1">The current time MUST be between TIMESTAMP and
- TIMESTAMP+TTL.<a href="#section-7-22.1" class="pilcrow">¶</a>
-</li>
-<li id="section-7-22.2">The signature MUST match the public key.<a href="#section-7-22.2" class="pilcrow">¶</a>
-</li>
-<li id="section-7-22.3">The set of POW values MUST NOT contain duplicates.<a href="#section-7-22.3" class="pilcrow">¶</a>
-</li>
-<li id="section-7-22.4">The average number of leading zeroes resulting from the provided
- POW values D' MUST be greater than D.<a href="#section-7-22.4" class="pilcrow">¶</a>
-</li>
-<li id="section-7-22.5">The validation period (TTL) of the revocation is calculated as
- (D'-D) * EPOCH * 1.1. The EPOCH is extended by
- 10% in order to deal with unsynchronized clocks.
- The TTL added on top of the TIMESTAMP yields the
- expiration date.<a href="#section-7-22.5" class="pilcrow">¶</a>
-</li>
-</ol>
-</section>
-</div>
-<div id="governance">
-<section id="section-8">
- <h2 id="name-determining-the-root-zone-a">
-<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-determining-the-root-zone-a" class="section-name selfRef">Determining the Root Zone and Zone Governance</a>
- </h2>
-<p id="section-8-1">
- The resolution of a GNS name must start in a given start zone
- indicated to the resolver using any public zone key.
- The local resolver may have a local start zone configured/hard-coded
- which points to a local or remote start zone key.
- A resolver client may also determine the start zone from the
- suffix of the name given for resolution or using information
- retrieved out of band.
- The governance model of any zone is at the sole discretion
- of the zone owner. However, the choice of start zone(s) is at the sole
- discretion of the local system administrator or user.<a href="#section-8-1" class="pilcrow">¶</a></p>
-<p id="section-8-2">
- This is an important distinguishing factor from the Domain Name System
- where root zone governance is centralized at the Internet Corporation
- for Assigned Names and Numbers (ICANN).
- In DNS terminology, GNS roughly follows the idea of a hyper-hyper
- local root zone deployment, with the difference that it is not
- expected that all deployments use the same local root zone.<a href="#section-8-2" class="pilcrow">¶</a></p>
-<p id="section-8-3">
- In the following, we give examples how a local client resolver SHOULD
- discover the start zone. The process given is not exhaustive and
- clients MAY suppliement it with other mechanisms or ignore it if the
- particular application requires a different process.<a href="#section-8-3" class="pilcrow">¶</a></p>
-<p id="section-8-4">
- GNS clients SHOULD first try to interpret the top-level domain of
- a GNS name as a zone key.
- For example. if the top-level domain is a Base32-encoded public zone
- key "zk", the root zone of the resolution process is implicitly given
- by the name:<a href="#section-8-4" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8-5">
-<pre>
-Example name: www.example.<Base32(zk)>
-=> Root zone: zk
-=> Name to resolve from root zone: www.example
- </pre><a href="#section-8-5" class="pilcrow">¶</a>
-</div>
-<p id="section-8-6">
- In GNS, users MAY own and manage their own zones.
- Each local zone SHOULD be associated with a single GNS label,
- but users MAY choose to use longer names consisting of
- multiple labels.
- If the name of a locally managed zone matches the suffix
- of the name to be resolved,
- resolution SHOULD start from the respective local zone:<a href="#section-8-6" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8-7">
-<pre>
-Example name: www.example.gnu
-Local zones:
-fr = (d0,zk0)
-gnu = (d1,zk1)
-com = (d2,zk2)
-...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www.example
- </pre><a href="#section-8-7" class="pilcrow">¶</a>
-</div>
-<p id="section-8-8">
- Finally, additional "suffix to zone" mappings MAY be configured.
- Suffix to zone key mappings SHOULD be configurable through a local
- configuration file or database by the user or system administrator.
- The suffix MAY consist of multiple GNS labels concatenated with a
- ".". If multiple suffixes match the name to resolve, the longest
- matching suffix MUST BE used. The suffix length of two results
- cannot be equal, as this would indicate a misconfiguration.
- If both a locally managed zone and a configuration entry exist
- for the same suffix, the locally managed zone MUST have priority.<a href="#section-8-8" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8-9">
-<pre>
-Example name: www.example.gnu
-Local suffix mappings:
-gnu = zk0
-example.gnu = zk1
-example.com = zk2
-...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www
- </pre><a href="#section-8-9" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="security">
-<section id="section-9">
- <h2 id="name-security-considerations">
-<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
- </h2>
-<div id="security_crypto">
-<section id="section-9.1">
- <h3 id="name-cryptography">
-<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-cryptography" class="section-name selfRef">Cryptography</a>
- </h3>
-<p id="section-9.1-1">
- The security of cryptographic systems depends on both the strength of
- the cryptographic algorithms chosen and the strength of the keys used
- with those algorithms. The security also depends on the engineering
- of the protocol used by the system to ensure that there are no
- non-cryptographic ways to bypass the security of the overall system.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
-<p id="section-9.1-2">
- This document concerns itself with the selection of cryptographic
- algorithms for use in GNS.
- The algorithms identified in this document are not known to be
- broken (in the cryptographic sense) at the current time, and
- cryptographic research so far leads us to believe that they are
- likely to remain secure into the foreseeable future. However, this
- isn't necessarily forever, and it is expected that new revisions of
- this document will be issued from time to time to reflect the current
- best practices in this area.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="security_abuse">
-<section id="section-9.2">
- <h3 id="name-abuse-mitigation">
-<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-abuse-mitigation" class="section-name selfRef">Abuse mitigation</a>
- </h3>
-<p id="section-9.2-1">
- GNS names are UTF-8 strings. Consequently, GNS faces similar issues
- with respect to name spoofing as DNS does for internationalized
- domain names.
- In DNS, attackers may register similar sounding or looking
- names (see above) in order to execute phishing attacks.
- GNS zone administrators must take into account this attack vector and
- incorporate rules in order to mitigate it.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
-<p id="section-9.2-2">
- Further, DNS can be used to combat illegal content on the internet
- by having the respective domains seized by authorities.
- However, the same mechanisms can also be abused in order to impose
- state censorship, which ist one of the motivations behind GNS.
- Hence, such a seizure is, by design, difficult to impossible in GNS.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="security_keymanagement">
-<section id="section-9.3">
- <h3 id="name-zone-management">
-<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-zone-management" class="section-name selfRef">Zone management</a>
- </h3>
-<p id="section-9.3-1">
- In GNS, zone administrators need to manage and protect their zone
- keys. Once a zone key is lost it cannot be recovered. Once it is
- compromised it cannot be revoked (unless a revocation was
- pre-calculated and is still available).
- Zone administrators, and for GNS this includes end-users, are
- required to responsibly and dilligently protect their cryptographic
- keys.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
-<p id="section-9.3-2">
- Similarly, users are required to manage their local root zone.
- In order to ensure integrity and availability or names, users must
- ensure that their local root zone information is not compromised or
- outdated.
- It can be expected that the processing of zone revocations and an
- initial root zone is provided with a GNS client implementation
- ("drop shipping").
- Extension and customization of the zone is at the full discretion of
- the user.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="security_dht">
-<section id="section-9.4">
- <h3 id="name-impact-of-underlying-dht">
-<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-impact-of-underlying-dht" class="section-name selfRef">Impact of underlying DHT</a>
- </h3>
-<p id="section-9.4-1">
- This document does not specifiy the properties of the underlying
- distributed hash table (DHT) which is required by any GNS
- implementation. For implementors, it is important to note that
- the properties of the DHT are directly inherited by the
- GNS implementation. This includes both security as well as
- other non-functional properties such as scalability and performance.
- Implementors should take great care when selecting or implementing
- a DHT for use in a GNS implementation.
- DHTs with string security and performance guarantees exist
- <span>[<a href="#R5N" class="xref">R5N</a>]</span>.
- It should also be taken into consideration that GNS implementations
- which build upon different DHT overlays are unlikely to be
- interoperable with each other.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="security_rev">
-<section id="section-9.5">
- <h3 id="name-revocations">
-<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-revocations" class="section-name selfRef">Revocations</a>
- </h3>
-<p id="section-9.5-1">
- Zone administrators are advised to pre-generate zone revocations
- and securely store the revocation information in case the zone
- key is lost, compromised or replaced in the furture.
- Pre-calculated revocations may become invalid due to expirations
- or protocol changes such as epoch adjustments.
- Conseuquently, implementors and users must make precautions in order
- to manage revocations accordingly.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
-<p id="section-9.5-2">
- Revocation payloads do NOT include a 'new' key for key replacement.
- In inclusion of such a key would have two major disadvantages:<a href="#section-9.5-2" class="pilcrow">¶</a></p>
-<p id="section-9.5-3">
- If revocation is used after a private key was compromised,
- allowing key replacement would be dangerous, because if an
- adversary took over the private key, the adversary could then
- broadcast a revocation with a key replacement. For the replacement,
- the compromised owner would have no chance to issue even a
- revocation. Thus, allowing a revocation message to replace a private
- key makes dealing with key compromise situations worse.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
-<p id="section-9.5-4">
- Sometimes, key revocations are used with the objective of changing
- cryptosystems. Migration to another cryptosystem by replacing keys
- via a revocation message would only be secure as long as both
- cryptosystems are still secure against forgery. Such a planned,
- non-emergency migration to another cryptosystem should be done by
- running zones for both ciphersystems in parallel for a while. The
- migration would conclude by revoking the legacy zone key only once
- it is deemed no longer secure, and hopefully after most users have
- migrated to the replacement.<a href="#section-9.5-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="iana">
-<section id="section-10">
- <h2 id="name-gana-considerations">
-<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-gana-considerations" class="section-name selfRef">GANA Considerations</a>
- </h2>
-<p id="section-10-1">
- GANA is requested to create an "GNU Name System Record Types" registry.
-The registry shall record for each entry:<a href="#section-10-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-10-2.1">Name: The name of the record type (case-insensitive ASCII
- string, restricted to alphanumeric characters<a href="#section-10-2.1" class="pilcrow">¶</a>
-</li>
-<li id="section-10-2.2">Number: 32-bit, above 65535<a href="#section-10-2.2" class="pilcrow">¶</a>
-</li>
-<li id="section-10-2.3">Comment: Optionally, a brief English text describing the purpose of
- the record type (in UTF-8)<a href="#section-10-2.3" class="pilcrow">¶</a>
-</li>
-<li id="section-10-2.4">Contact: Optionally, the contact information of a person to contact for
- further information<a href="#section-10-2.4" class="pilcrow">¶</a>
-</li>
-<li id="section-10-2.5">References: Optionally, references describing the record type
- (such as an RFC)<a href="#section-10-2.5" class="pilcrow">¶</a>
-</li>
-</ul>
-<p id="section-10-3">
- The registration policy for this sub-registry is "First Come First
- Served", as described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
- GANA is requested to populate this registry as follows:<a href="#section-10-3" class="pilcrow">¶</a></p>
-<div id="figure_rrtypenums">
-<figure id="figure-18">
- <div class="artwork art-text alignLeft" id="section-10-4.1">
-<pre>
-Number | Name | Contact | References | Description
--------+---------+---------+------------+-------------------------
-65536 | PKEY | N/A | [This.I-D] | GNS zone delegation
-65537 | NICK | N/A | [This.I-D] | GNS zone nickname
-65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
-65539 | VPN | N/A | [This.I-D] | VPN resolution
-65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
-65541 | BOX | N/A | [This.I-D] | Boxed record
- </pre>
-</div>
-<figcaption><a href="#figure-18" class="selfRef">Figure 18</a></figcaption></figure>
-</div>
-</section>
-</div>
-<section id="section-11">
- <h2 id="name-test-vectors">
-<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
- </h2>
-<p id="section-11-1">
- The following represents a test vector for a record set with a DNS
- record of type "A" as well as a GNS record of type "PKEY"
- under the label "test".<a href="#section-11-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-11-2">
-<pre>
-
-Zone private key (d):
-WGb/eoy8BDWvaK2vRab0xTlqvS0+PeS5HG5Rh4z4cWI=
-Zone public key (zk):
-n7TNZeJ+Ks6wQymnwjZXR/cj0ae8NZMZ/PcuDVrONAo=
-Label: test
-RRCOUNT: 2
-
-Record #0
-EXPIRATION: 1589117218087117
-DATA_SIZE: 4
-TYPE: 1
-FLAGS: 0
-DATA (base64):
-AQIDBA==
-DATA (Human readable):
-1.2.3.4
-
-Record #1
-EXPIRATION: 1589117218087117
-DATA_SIZE: 32
-TYPE: 65536
-FLAGS: 2
-DATA (base64):
-+AT14h9SMRAwkor+azlHpE8DkvsUyeQyN49NEmsOXew=
-DATA (Human readable):
-Z02FBRGZA8RH0C4JHBZ6PEA7MH7G74QV2K4Y8CHQHX6H4TREBQP0
-
-RDATA:
-AAWlSy9KYM0AAAAEAAAAAQAAAAABAgMEAAWlSy9KYM0AAAAgAAEAAAAAAAL4BPXi
-H1IxEDCSiv5rOUekTwOS+xTJ5DI3j00Saw5d7AAAAAAAAAAAAAAAAAAAAAAAAAAA
-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-
-BDATA:
-5e5936fttKU61GByslXav57Zgi4rac2N0F6VJCKC7NVn1YPJyiL/0+f2vZSUfHpk
-ZfRPv9clYgzO4m+PdRcYFpkG0vqmrFnDNJQRd/y9V2Wfg4ud82FK3CT9lcMpu6Sd
-fbZyE8PmL7cySfdMa/RsNWCVAES98UOvNJ7CaBDJlY2mb6iA
-
-RRBLOCK:
-Cqk3xJHTNxM1EE69iH33z0dK78FrhK+gUHMIUY//WHYCPZmbdgJc5Avb9uVTAAyT
-5No5uINZwxXuWpL72Xh4IIqWAE/BdKHS9deQusO6CSiZN1swM5zsupJq1qjgHusG
-AAAAlAAAAA8ABaVLL0pgzeXufd+n7bSlOtRgcrJV2r+e2YIuK2nNjdBelSQiguzV
-Z9WDycoi/9Pn9r2UlHx6ZGX0T7/XJWIMzuJvj3UXGBaZBtL6pqxZwzSUEXf8vVdl
-n4OLnfNhStwk/ZXDKbuknX22chPD5i+3Mkn3TGv0bDVglQBEvfFDrzSewmgQyZWN
-pm+ogA==
-
- </pre><a href="#section-11-2" class="pilcrow">¶</a>
-</div>
-<p id="section-11-3">
- The following is an example revocation for a zone:<a href="#section-11-3" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-11-4">
-<pre>
-
-Zone private key (d):
-SLZnT2NK3cusTfuI0CM+XJiP4U43ZsCAv+Lk3FbIXHc=
-
-Zone public key (zk):
-bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
-
-Difficulty (5 base difficulty + 2 epochs): 7
-
-Proof:
-AAWkvp6KGBVAxXvM//8AALpHh010jxRdukeHTXSPEhq6R4dNdI8VDbpHh010jxUy
-ukeHTXSPGNK6R4dNdI8ZXLpHh010jxTTukeHTXSPFSW6R4dNdI8VarpHh010jxV3
-ukeHTXSPFnC6R4dNdI8X5rpHh010jxoJukeHTXSPGqm6R4dNdI8aurpHh010jxwD
-ukeHTXSPHGm6R4dNdI8cvLpHh010jxdGukeHTXSPF426R4dNdI8XxrpHh010jxif
-ukeHTXSPGL26R4dNdI8ZJLpHh010jxlTukeHTXSPGsa6R4dNdI8bfLpHh010jxuV
-ukeHTXSPHCi6R4dNdI8eC7pHh010jx4VukeHTXSPHhsJejeXmcDe4jcfEkWLqwIA
-8zG/gFIxNYu34usglSp+7w8bbtTgMD5hLGiR+xxhgpPh36dGz1KBZ9kAh9pz77yS
-bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
-
- </pre><a href="#section-11-4" class="pilcrow">¶</a>
-</div>
-</section>
-<section id="section-12">
- <h2 id="name-normative-references">
-<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
- </h2>
-<dl class="references">
-<dt id="RFC1034">[RFC1034]</dt>
-<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - concepts and facilities"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1034</span>, <span class="seriesInfo">DOI 10.17487/RFC1034</span>, <time datetime="1987-11">November 1987</time>, <span><<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>></span>. </dd>
-<dt id="RFC1035">[RFC1035]</dt>
-<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11">November 1987</time>, <span><<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>></span>. </dd>
-<dt id="RFC2782">[RFC2782]</dt>
-<dd>
-<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, P.</span><span class="refAuthor">, and L. Esibov</span>, <span class="refTitle">"A DNS RR for specifying the location of services (DNS SRV)"</span>, <span class="seriesInfo">RFC 2782</span>, <span class="seriesInfo">DOI 10.17487/RFC2782</span>, <time datetime="2000-02">February 2000</time>, <span><<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>></span>. </dd>
-<dt id="RFC2119">[RFC2119]</dt>
-<dd>
-<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span><<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>></span>. </dd>
-<dt id="RFC3629">[RFC3629]</dt>
-<dd>
-<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11">November 2003</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>></span>. </dd>
-<dt id="RFC3826">[RFC3826]</dt>
-<dd>
-<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino, F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC 3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time datetime="2004-06">June 2004</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3826">https://www.rfc-editor.org/info/rfc3826</a>></span>. </dd>
-<dt id="RFC5869">[RFC5869]</dt>
-<dd>
-<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>. </dd>
-<dt id="RFC5890">[RFC5890]</dt>
-<dd>
-<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"</span>, <span class="seriesInfo">RFC 5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time datetime="2010-08">August 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5890">https://www.rfc-editor.org/info/rfc5890</a>></span>. </dd>
-<dt id="RFC5891">[RFC5891]</dt>
-<dd>
-<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names in Applications (IDNA): Protocol"</span>, <span class="seriesInfo">RFC 5891</span>, <span class="seriesInfo">DOI 10.17487/RFC5891</span>, <time datetime="2010-08">August 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5891">https://www.rfc-editor.org/info/rfc5891</a>></span>. </dd>
-<dt id="RFC6895">[RFC6895]</dt>
-<dd>
-<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>, <span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time datetime="2013-04">April 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6895">https://www.rfc-editor.org/info/rfc6895</a>></span>. </dd>
-<dt id="RFC6979">[RFC6979]</dt>
-<dd>
-<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>. </dd>
-<dt id="RFC7748">[RFC7748]</dt>
-<dd>
-<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, M.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>></span>. </dd>
-<dt id="RFC8032">[RFC8032]</dt>
-<dd>
-<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01">January 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>></span>. </dd>
-<dt id="RFC8126">[RFC8126]</dt>
-<dd>
-<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>></span>. </dd>
-<dt id="TWOFISH">[TWOFISH]</dt>
-<dd>
-<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition"</span>, <time datetime="1999-03">March 1999</time>. </dd>
-<dt id="GNS">[GNS]</dt>
-<dd>
-<span class="refAuthor">Wachs, M.</span><span class="refAuthor">, Schanzenbach, M.</span><span class="refAuthor">, and C. Grothoff</span>, <span class="refTitle">"A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System"</span>, <time datetime="2014">2014</time>, <span><<a href="https://doi.org/10.1007/978-3-319-12280-9_9">https://doi.org/10.1007/978-3-319-12280-9_9</a>></span>. </dd>
-<dt id="R5N">[R5N]</dt>
-<dd>
-<span class="refAuthor">Evans, N. S.</span><span class="refAuthor"> and C. Grothoff</span>, <span class="refTitle">"R5N: Randomized recursive routing for restricted-route networks"</span>, <time datetime="2011">2011</time>, <span><<a href="https://doi.org/10.1109/ICNSS.2011.6060022">https://doi.org/10.1109/ICNSS.2011.6060022</a>></span>. </dd>
-<dt id="Argon2">[Argon2]</dt>
-<dd>
-<span class="refAuthor">Biryukov, A.</span><span class="refAuthor">, Dinu, D.</span><span class="refAuthor">, Khovratovich, D.</span><span class="refAuthor">, and S. Josefsson</span>, <span class="refTitle">"The memory-hard Argon2 password hash and proof-of-work function"</span>, <time datetime="2020-03">March 2020</time>, <span><<a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/">https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/</a>></span>. </dd>
-</dl>
-</section>
-<div id="authors-addresses">
-<section id="section-appendix.a">
- <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
- </h2>
-<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Martin Schanzenbach</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
-<div dir="auto" class="left">
-<span class="postal-code">85748</span> <span class="locality">Garching</span>
-</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:schanzen@gnunet.org" class="email">schanzen@gnunet.org</a>
-</div>
-</address>
-<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Christian Grothoff</span></div>
-<div dir="auto" class="left"><span class="org">Berner Fachhochschule</span></div>
-<div dir="auto" class="left"><span class="street-address">Hoeheweg 80</span></div>
-<div dir="auto" class="left">
-<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
-</div>
-<div dir="auto" class="left"><span class="country-name">Switzerland</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:schanzen@gnunet.org" class="email">schanzen@gnunet.org</a>
-</div>
-</address>
-<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Bernd Fix</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
-<div dir="auto" class="left">
-<span class="postal-code">85748</span> <span class="locality">Garching</span>
-</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:fix@gnunet.org" class="email">fix@gnunet.org</a>
-</div>
-</address>
-</section>
-</div>
-<script>var toc = document.getElementById("toc");
-var tocToggle = toc.querySelector("h2");
-var tocNav = toc.querySelector("nav");
-
-// mobile menu toggle
-tocToggle.onclick = function(event) {
- if (window.innerWidth < 1024) {
- var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
- if (tocNavDisplay == "none") {
- tocNav.style.display = "block";
- } else {
- tocNav.style.display = "none";
- }
- }
-}
-
-// toc anchor scroll to anchor
-tocNav.addEventListener("click", function (event) {
- event.preventDefault();
- if (event.target.nodeName == 'A') {
- if (window.innerWidth < 1024) {
- tocNav.style.display = "none";
- }
- var href = event.target.getAttribute("href");
- var anchorId = href.substr(1);
- var anchor = document.getElementById(anchorId);
- anchor.scrollIntoView(true);
- window.history.pushState("","",href);
- }
-});
-
-// switch toc mode when window resized
-window.onresize = function () {
- if (window.innerWidth < 1024) {
- tocNav.style.display = "none";
- } else {
- tocNav.style.display = "block";
- }
-}
-</script>
-</body>
-</html>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -1,1792 +0,0 @@
-
-
-
-
-Independent Stream M. Schanzenbach
-Internet-Draft GNUnet e.V.
-Intended status: Informational C. Grothoff
-Expires: 13 May 2020 Berner Fachhochschule
- B. Fix
- GNUnet e.V.
- 10 November 2019
-
-
- The GNU Name System Specification
- draft-schanzen-gns-00
-
-Abstract
-
- This document contains the GNU Name System (GNS) technical
- specification.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at https://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on 13 May 2020.
-
-Copyright Notice
-
- Copyright (c) 2019 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents (https://trustee.ietf.org/
- license-info) in effect on the date of publication of this document.
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document. Code Components
- extracted from this document must include Simplified BSD License text
- as described in Section 4.e of the Trust Legal Provisions and are
- provided without warranty as described in the Simplified BSD License.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 1]
-
-Internet-Draft The GNU Name System November 2019
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 6
- 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 10
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 10
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 11
- 4.3. Record Data Encryption and Decryption . . . . . . . . . . 13
- 5. Internationalization and Character Encoding . . . . . . . . . 15
- 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.2. Record Processing . . . . . . . . . . . . . . . . . . . . 16
- 6.2.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.6. NICK . . . . . . . . . . . . . . . . . . . . . . . . 19
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
- 8. Determining the Root Zone and Zone Governance . . . . . . . . 24
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
- 9.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 25
- 9.2. Abuse mitigation . . . . . . . . . . . . . . . . . . . . 26
- 9.3. Zone management . . . . . . . . . . . . . . . . . . . . . 26
- 9.4. Impact of underlying DHT . . . . . . . . . . . . . . . . 26
- 9.5. Revocations . . . . . . . . . . . . . . . . . . . . . . . 27
- 10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 28
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 30
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 2]
-
-Internet-Draft The GNU Name System November 2019
-
-
-1. Introduction
-
- The Domain Name System (DNS) is a unique distributed database and a
- vital service for most Internet applications. While DNS is
- distributed, it relies on centralized, trusted registrars to provide
- globally unique names. As the awareness of the central role DNS
- plays on the Internet rises, various institutions are using their
- power (including legal means) to engage in attacks on the DNS, thus
- threatening the global availability and integrity of information on
- the Internet.
-
- DNS was not designed with security as a goal. This makes it very
- vulnerable, especially to attackers that have the technical
- capabilities of an entire nation state at their disposal. This
- specification describes a censorship-resistant, privacy-preserving
- and decentralized name system: The GNU Name System (GNS). It is
- designed to provide a secure alternative to DNS, especially when
- censorship or manipulation is encountered. GNS can bind names to any
- kind of cryptographically secured token, enabling it to double in
- some respects as even as an alternative to some of today's Public Key
- Infrastructures, in particular X.509 for the Web.
-
- This document contains the GNU Name System (GNS) technical
- specification of the GNU Name System [GNS], a fully decentralized and
- censorship-resistant name system. GNS provides a privacy-enhancing
- alternative to the Domain Name System (DNS). The design of GNS
- incorporates the capability to integrate and coexist with DNS. GNS
- is based on the principle of a petname system and builds on ideas
- from the Simple Distributed Security Infrastructure (SDSI),
- addressing a central issue with the decentralized mapping of secure
- identifiers to memorable names: namely the impossibility of providing
- a global, secure and memorable mapping without a trusted authority.
- GNS uses the transitivity in the SDSI design to replace the trusted
- root with secure delegation of authority thus making petnames useful
- to other users while operating under a very strong adversary model.
-
- This document defines the normative wire format of resource records,
- resolution processes, cryptographic routines and security
- considerations for use by implementors.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 3]
-
-Internet-Draft The GNU Name System November 2019
-
-
-2. Zones
-
- A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
- where d is the private key and zk the corresponding public key. GNS
- employs the curve parameters of the twisted edwards representation of
- Curve25519 [RFC7748] (a.k.a. edwards25519) with the ECDSA scheme
- ([RFC6979]). In the following, we use the following naming
- convention for our cryptographic primitives:
-
- d is a 256-bit ECDSA private key. In GNS, records are signed using
- a key derived from "d" as described in Section 4.
-
- p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- - 19.
-
- B is the group generator (X(P),Y(P)) of edwards25519 as defined in
- [RFC7748].
-
- L is the prime-order subgroup of edwards25519 in [RFC7748].
-
- zk is the ECDSA public key corresponding to d. It is defined in
- [RFC6979] as the curve point d*B where B is the group generator of
- the elliptic curve. The public key is used to uniquely identify a
- GNS zone and is referred to as the "zone key".
-
-3. Resource Records
-
- A GNS implementor MUST provide a mechanism to create and manage
- resource records for local zones. A local zone is established by
- creating a zone key pair. Records may be added to each zone, hence a
- (local) persistency mechanism for resource records and zones must be
- provided. This local zone database is used by the GNS resolver
- implementation and to publish record information.
-
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 4]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Figure 1
-
- where:
-
- EXPIRATION denotes the absolute 64-bit expiration date of the
- record. In microseconds since midnight (0 hour), January 1, 1970
- in network byte order.
-
- DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
- network byte order.
-
- TYPE is the 32-bit resource record type. This type can be one of
- the GNS resource records as defined in Section 3 or a DNS record
- type as defined in [RFC1035] or any of the complementary
- standardized DNS resource record types. This value must be stored
- in network byte order. Note that values below 2^16 are reserved
- for allocation via IANA ([RFC6895]).
-
- FLAGS is a 32-bit resource record flags field (see below).
-
- DATA the variable-length resource record data payload. The contents
- are defined by the respective type of the resource record.
-
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:
-
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
-
- Figure 2
-
- where:
-
- SHADOW If this flag is set, this record should be ignored by
- resolvers unless all (other) records of the same record type have
- expired. Used to allow zone publishers to facilitate good
- performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can
- propagate and may be cached before the transition becomes active.
-
- EXPREL The expiration time value of the record is a relative time
- (still in microseconds) and not an absolute time. This flag
- should never be encountered by a resolver for records obtained
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 5]
-
-Internet-Draft The GNU Name System November 2019
-
-
- from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.
-
- SUPPL This is a supplemental record. It is provided in addition to
- the other records. This flag indicates that this record is not
- explicitly managed alongside the other records under the
- respective name but may be useful for the application. This flag
- should only be encountered by a resolver for records obtained from
- the DHT.
-
- PRIVATE This is a private record of this peer and it should thus not
- be published in the DHT. Thus, this flag should never be
- encountered by a resolver for records obtained from the DHT.
- Private records should still be considered just like regular
- records when resolving labels in local zones.
-
-3.1. Record Types
-
- A registry of GNS Record Types is described in Section 10. The
- registration policy for this registry is "First Come First Served",
- as described in [RFC8126]. When requesting new entries, careful
- consideration of the following criteria is strongly advised: FIXME:
- ausdenken was wir da gerne haetten.
-
-3.2. PKEY
-
- In GNS, a delegation of a label to a zone is represented through a
- PKEY record. A PKEY resource record contains the public key of the
- zone to delegate to. A PKEY record MUST be the only record under a
- label. No other records are allowed. A PKEY DATA entry has the
- following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 3
-
- where:
-
- PUBLIC KEY A 256-bit ECDSA zone key.
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 6]
-
-Internet-Draft The GNU Name System November 2019
-
-
-3.3. GNS2DNS
-
- It is possible to delegate a label back into DNS through a GNS2DNS
- record. The resource record contains a DNS name for the resolver to
- continue with in DNS followed by a DNS server. Both names are in the
- format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
- the following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS NAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DNS SERVER NAME |
- / /
- / /
- | |
- +-----------------------------------------------+
-
- Figure 4
-
- where:
-
- DNS NAME The name to continue with in DNS (0-terminated).
-
- DNS SERVER NAME The DNS server to use. May be an IPv4/IPv6 address
- in dotted decimal form or a DNS name. It may also be a relative
- GNS name ending with a "+" top-level domain. The value is UTF-8
- encoded (also for DNS names) and 0-terminated.
-
-3.4. LEHO
-
- Legacy hostname records can be used by applications that are expected
- to supply a DNS name on the application layer. The most common use
- case is HTTP virtual hosting, which as-is would not work with GNS
- names as those may not be globally unique. A LEHO resource record is
- expected to be found together in a single resource record with an
- IPv4 or IPv6 address. A LEHO DATA entry has the following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | LEGACY HOSTNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 7]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Figure 5
-
- where:
-
- LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
- representing the legacy hostname.
-
- NOTE: If an application uses a LEHO value in an HTTP request header
- (e.g. "Host:" header) it must be converted to a punycode
- representation [RFC5891].
-
-3.5. NICK
-
- Nickname records can be used by zone administrators to publish an
- indication on what label this zone prefers to be referred to. This
- is a suggestion to other zones what label to use when creating a PKEY
- (Section 3.2) record containing this zone's public zone key. This
- record SHOULD only be stored under the empty label "@" but MAY be
- returned with record sets under any label as a supplemental record.
- Section 6.2.6 details how a resolver must process supplemental and
- non-supplemental NICK records. A NICK DATA entry has the following
- format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | NICKNAME |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 6
-
- where:
-
- NICKNAME A UTF-8 string (which is not 0-terminated) representing the
- preferred label of the zone. This string MUST NOT include a "."
- character.
-
-3.6. BOX
-
- In GNS, every "." in a name delegates to another zone, and GNS
- lookups are expected to return all of the required useful information
- in one record set. This 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. For example, a TLSA
- record for "_https._tcp.foo.gnu" will be stored in the record set of
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 8]
-
-Internet-Draft The GNU Name System November 2019
-
-
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
- (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also
- [RFC2782]. A BOX DATA entry has the following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PROTO | SVC | TYPE |
- +-----------+-----------------------------------+
- | RECORD DATA |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 7
-
- where:
-
- PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
- order.
-
- SVC the 16-bit service value of the boxed record, i.e. the port
- number. In network byte order.
-
- TYPE is the 32-bit record type of the boxed record. In network byte
- order.
-
- RECORD DATA is a variable length field containing the "DATA" format
- of TYPE as defined for the respective TYPE in DNS.
-
-3.7. VPN
-
- A VPN DATA entry has the following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | HOSTING PEER PUBLIC KEY |
- | (256 bits) |
- | |
- | |
- +-----------+-----------------------------------+
- | PROTO | SERVICE NAME |
- +-----------+ +
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 9]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Figure 8
-
- where:
-
- HOSTING PEER PUBLIC KEY is a 256-bit EdDSA public key identifying
- the peer hosting the service.
-
- PROTO the 16-bit protocol number, e.g. 6 for TCP. In network byte
- order.
-
- SERVICE NAME a shared secret used to identify the service at the
- hosting peer, used to derive the port number requird to connect to
- the service. The service name MUST be a 0-terminated UTF-8
- string.
-
-4. Publishing Records
-
- GNS resource records are published in a distributed hash table (DHT).
- We assume that a DHT provides two functions: GET(key) and
- PUT(key,value). In GNS, resource records are grouped by their
- respective labels, encrypted and published together in a single
- resource records block (RRBLOCK) in the DHT under a key "q": PUT(q,
- RRBLOCK). The key "q" which is derived from the zone key "zk" and
- the respective label of the contained records.
-
-4.1. Key Derivations
-
- Given a label, the DHT key "q" is derived as follows:
-
- PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d_h := h * d mod L
- zk_h := h mod L * zk
- q := SHA512 (zk_h)
-
- We use a hash-based key derivation function (HKDF) as defined in
- [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
- SHA256 for the expansion phase.
-
- PRK_h is key material retrieved using an HKDF using the string "key-
- derivation" as salt and the public zone key "zk" as initial keying
- material.
-
- h is the 512-bit HKDF expansion result. The expansion info input is
- a concatenation of the label and string "gns".
-
- d is the 256-bit private zone key as defined in Section 2.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 10]
-
-Internet-Draft The GNU Name System November 2019
-
-
- label is a UTF-8 string under which the resource records are
- published.
-
- d_h is a 256-bit private key derived from the "d" using the keying
- material "h".
-
- zk_h is a 256-bit public key derived from the zone key "zk" using
- the keying material "h".
-
- L is the prime-order subgroup as defined in Section 2.
-
- q Is the 512-bit DHT key under which the resource records block is
- published. It is the SHA512 hash over the public key "zk_h"
- corresponding to the derived private key "d_h".
-
- We point out that the multiplication of "zk" with "h" is a point
- multiplication, while the multiplication of "d" with "h" is a scalar
- multiplication.
-
-4.2. Resource Records Block
-
- GNS records are grouped by their labels and published as a single
- block in the DHT. The grouped record sets MAY be paired with any
- number of supplemental records. Supplemental records must have the
- supplemental flag set (See Section 3). The contained resource
- records are encrypted using a symmetric encryption scheme. A GNS
- implementation must publish RRBLOCKs in accordance to the properties
- and recommendations of the underlying DHT. This may include a
- periodic refresh publication. A GNS RRBLOCK has the following
- format:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 11]
-
-Internet-Draft The GNU Name System November 2019
-
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 9
-
- where:
-
- SIGNATURE A 512-bit ECDSA deterministic signature compliant with
- [RFC6979]. The signature is computed over the data following the
- PUBLIC KEY field. The signature is created using the derived
- private key "d_h" (see Section 4).
-
- PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify
- SIGNATURE. The wire format of this value is defined in [RFC8032],
- Section 5.1.5.
-
- SIZE A 32-bit value containing the length of the signed data
- following the PUBLIC KEY field in network byte order. This value
- always includes the length of the fields SIZE (4), PURPOSE (4) and
- EXPIRATION (8) in addition to the length of the BDATA. While a
- 32-bit value is used, implementations MAY refuse to publish blocks
- beyond a certain size significantly below 4 GB. However, a
- minimum block size of 62 kilobytes MUST be supported.
-
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
- network byte order).
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 12]
-
-Internet-Draft The GNU Name System November 2019
-
-
- EXPIRATION Specifies when the RRBLOCK expires and the encrypted
- block SHOULD be removed from the DHT and caches as it is likely
- stale. However, applications MAY continue to use non-expired
- individual records until they expire. The value MUST be set to
- the expiration time of the resource record contained within this
- block with the smallest expiration time. If a records block
- includes shadow records, then the maximum expiration time of all
- shadow records with matching type and the expiration times of the
- non-shadow records is considered. This is a 64-bit absolute date
- in microseconds since midnight (0 hour), January 1, 1970 in
- network byte order.
-
- BDATA The encrypted resource records with a total size of SIZE - 16.
-
-4.3. Record Data Encryption and Decryption
-
- A symmetric encryption scheme is used to encrypt the resource records
- set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
- the RDATA looks as follows:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
-
- Figure 10
-
- where:
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 13]
-
-Internet-Draft The GNU Name System November 2019
-
-
- RR COUNT A 32-bit value containing the number of variable-length
- resource records which are following after this field in network
- byte order.
-
- EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA These fields were
- defined in the resource record format in Section 3. There MUST be
- a total of RR COUNT of these resource records present.
-
- PADDING The padding MUST contain the value 0 in all octets. The
- padding MUST ensure that the size of the RDATA WITHOUT the RR
- COUNT field is a power of two. As a special exception, record
- sets with (only) a PKEY record type are never padded. Note that a
- record set with a PKEY record MUST NOT contain other records.
-
- The symmetric keys and initialization vectors are derived from the
- record label and the zone key "zk". For decryption of the resource
- records block payload, the key material "K" and initialization vector
- "IV" for the symmetric cipher are derived as follows:
-
- PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
- PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
- K := HKDF-Expand (PRK_k, label, 512 / 8);
- IV := HKDF-Expand (PRK_iv, label, 256 / 8)
-
- HKDF is a hash-based key derivation function as defined in [RFC5869].
- Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-
- SHA256 for the expansion phase. The output keying material is 64
- octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
- the initialization vectors. We divide the resulting keying material
- "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
- key:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 11
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 14]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Similarly, we divide "IV" into a 128-bit initialization vector and a
- 128-bit initialization vector:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 12
-
- The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
- chained symmetric cipher. Both ciphers are used in Cipher FeedBack
- (CFB) mode [RFC3826].
-
- RDATA := AES(K[0:31], IV[0:15],
- TWOFISH(K[32:63], IV[16:31], BDATA))
- BDATA := TWOFISH(K[32:63], IV[16:31],
- AES(K[0:31], IV[0:15], RDATA))
-
-5. Internationalization and Character Encoding
-
- All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
- include any DNS names found in DNS records, such as CNAME records,
- which are internationalized through the IDNA specifications
- [RFC5890].
-
-6. Name Resolution
-
- Names in GNS are resolved by recursively querying the DHT record
- storage. In the following, we define how resolution is initiated and
- each iteration in the resolution is processed.
-
- GNS resolution of a name must start in a given starting zone
- indicated using a zone public key. Details on how the starting zone
- may be determined is discussed in Section 8.
-
- When GNS name resolution is requested, a desired record type MAY be
- provided by the client. The GNS resolver will use the desired record
- type to guide processing, for example by providing conversion of VPN
- records to A or AAAA records, if that is desired. However, filtering
- of record sets according to the required record types MUST still be
- done by the client after the resource record set is retrieved.
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 15]
-
-Internet-Draft The GNU Name System November 2019
-
-
-6.1. Recursion
-
- In each step of the recursive name resolution, there is an
- authoritative zone zk and a name to resolve. The name may be empty.
- Initially, the authoritative zone is the start zone. If the name is
- empty, it is interpreted as the apex label "@".
-
- From here, the following steps are recursively executed, in order:
-
- 1. Extract the right-most label from the name to look up.
-
- 2. Calculate q using the label and zk as defined in Section 4.1.
-
- 3. Perform a DHT query GET(q) to retrieve the RRBLOCK.
-
- 4. Verify and process the RRBLOCK and decrypt the BDATA contained in
- it as defined in Section 4.3.
-
- Upon receiving the RRBLOCK from the DHT, apart from verifying the
- provided signature, the resolver MUST check that the authoritative
- zone key was used to sign the record: The derived zone key "h*zk"
- MUST match the public key provided in the RRBLOCK, otherwise the
- RRBLOCK MUST be ignored and the DHT lookup GET(q) MUST continue.
-
-6.2. Record Processing
-
- Record processing occurs at the end of a single recursion. We assume
- that the RRBLOCK has been cryptographically verified and decrypted.
- At this point, we must first determine if we have received a valid
- record set in the context of the name we are trying to resolve:
-
- 1. Case 1: If the remainder of the name to resolve is empty and the
- record set does not consist of a PKEY, CNAME or DNS2GNS record,
- the record set is the result and the recursion is concluded.
-
- 2. Case 2: If 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 the
- result and the recusion is concluded (Section 6.2.4).
-
- 3. Case 3: If the remainder of the name to resolve is not empty and
- does not match the "_SERVICE._PROTO" syntax, then the current
- record set MUST consist of a single PKEY record (Section 6.2.1),
- a single CNAME record (Section 6.2.3), or one or more GNS2DNS
- records (Section 6.2.2), which are processed as described in the
- respective sections below. The record set may include any number
- of supplemental records. Otherwise, resolution fails and the
- resolver MUST return an empty record set. Finally, after the
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 16]
-
-Internet-Draft The GNU Name System November 2019
-
-
- recursion terminates, the client preferences for the record type
- SHOULD be considered. If a VPN record is found and the client
- requests an A or AAAA record, the VPN record SHOULD be converted
- (Section 6.2.5) if possible.
-
-6.2.1. PKEY
-
- When the resolver encounters a PKEY record and the remainder of the
- name is not empty, resolution continues recursively with the
- remainder of the name in the GNS zone specified in the PKEY record.
-
- If the remainder of the name to resolve is empty and we have received
- a record set containing only a single PKEY record, the recursion is
- continued with the PKEY as authoritative zone and the empty apex
- label "@" as remaining name, except in the case where the desired
- record type is PKEY, in which case the PKEY record is returned and
- the resolution is concluded without resolving the empty apex label.
-
-6.2.2. GNS2DNS
-
- When a resolver encounters one or more GNS2DNS records and the
- remaining name is empty and the desired record type is GNS2DNS, the
- GNS2DNS records are returned.
-
- Otherwise, it is expected that the resolver first resolves the IP(s)
- of the specified DNS name server(s). GNS2DNS records MAY contain
- numeric IPv4 or IPv6 addresses, allowing the resolver to skip this
- step. The DNS server names may themselves be names in GNS or DNS.
- If the DNS server name ends in ".+", the rest of the name is to be
- interpreted relative to the zone of the GNS2DNS record. If the DNS
- server name ends in ".<Base32(zk)>", the DNS server name is to be
- resolved against the GNS zone zk.
-
- Multiple GNS2DNS records may be stored under the same label, in which
- case the resolver MUST try all of them. The resolver MAY try them in
- any order or even in parallel. If multiple GNS2DNS records are
- present, the DNS name MUST be identical for all of them, if not the
- resolution fails and an emtpy record set is returned as the record
- set is invalid.
-
- Once the IP addresses of the DNS servers have been determined, the
- DNS name from the GNS2DNS record is appended to the remainder of the
- name to be resolved, and resolved by querying the DNS name server(s).
- As the DNS servers specified are possibly authoritative DNS servers,
- the GNS resolver MUST support recursive resolution and MUST NOT
- delegate this to the authoritative DNS servers. The first successful
- recursive name resolution result is returned to the client. In
- addition, the resolver returns the queried DNS name as a supplemental
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 17]
-
-Internet-Draft The GNU Name System November 2019
-
-
- LEHO record (Section 3.4) with a relative expiration time of one
- hour.
-
- GNS resolvers SHOULD offer a configuration option to disable DNS
- processing to avoid information leakage and provide a consistent
- security profile for all name resolutions. Such resolvers would
- return an empty record set upon encountering a GNS2DNS record during
- the recursion. However, if GNS2DNS records are encountered in the
- record set for the apex and a GNS2DNS record is expicitly requested
- by the application, such records MUST still be returned, even if DNS
- support is disabled by the GNS resolver configuration.
-
-6.2.3. CNAME
-
- If a CNAME record is encountered, the canonical name is appended to
- the remaining name, except if the remaining name is empty and the
- desired record type is CNAME, in which case the resolution concludes
- with the CNAME record. If the canonical name ends in ".+",
- resolution continues in GNS with the new name in the current zone.
- Otherwise, the resulting name is resolved via the default operating
- system name resolution process. This may in turn again trigger a GNS
- resolution process depending on the system configuration.
-
- The recursive DNS resolution process may yield a CNAME as well which
- in turn may either point into the DNS or GNS namespace (if it ends in
- a ".<Base32(zk)>"). In order to prevent infinite loops, the resolver
- MUST implement loop detections or limit the number of recursive
- resolution steps. If the last CNAME was a DNS name, the resolver
- returns the DNS name as a supplemental LEHO record (Section 3.4) with
- a relative expiration time of one hour.
-
-6.2.4. BOX
-
- 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.
-
-6.2.5. VPN
-
- At the end of the recursion, if the queried record type is either A
- or AAAA and the retrieved record set contains at least one VPN
- record, the resolver SHOULD open a tunnel and return the IPv4 or IPv6
- tunnel address, respectively. The type of tunnel depends on the
- contents of the VPN record data. The VPN record MUST be returned if
- the resolver implementation does not support setting up a tunnnel.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 18]
-
-Internet-Draft The GNU Name System November 2019
-
-
-6.2.6. NICK
-
- NIICK records are only relevant to the recursive resolver if the
- record set in question is the final result which is to be returned to
- the client. The encountered NICK records may either be supplemental
- (see Section 3) or non-supplemental. If the NICK record is
- supplemental, the resolver only returns the record set if one of the
- non-supplemental records matches the queried record type.
-
- The differentiation between a supplemental and non-supplemental NICK
- record allows the client to match the record to the authoritative
- zone. Consider the following example:
-
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: eve
-
- Figure 13
-
- In this example, the returned NICK record is non-supplemental. For
- the client, this means that the NICK belongs to the zone "alice.doe"
- and is published under the empty label along with an A record. The
- NICK record should be interpreted as: The zone defined by "alice.doe"
- wants to be referred to as "eve". In contrast, consider the
- following:
-
- Query: alice.doe (type=A)
- Result:
- A: 1.2.3.4
- NICK: john (Supplemental)
-
- Figure 14
-
- In this case, the NICK record is marked as supplemental. This means
- that the NICK record belongs to the zone "doe" and is published under
- the label "alice" along with an A record. The NICK record should be
- interpreted as: The zone defined by "doe" wants to be referred to as
- "john". This distinction is likely useful for other records
- published as supplemental.
-
-7. Zone Revocation
-
- Whenever a recursive resolver encounters a new GNS zone, it MUST
- check against the local revocation list whether the respective zone
- key has been revoked. If the zone key was revoked, the resolution
- MUST fail with an empty result set.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 19]
-
-Internet-Draft The GNU Name System November 2019
-
-
- In order to revoke a zone key, a signed revocation object SHOULD be
- published. This object MUST be signed using the private zone key.
- The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message MUST contain a proof of work
- (PoW). The revocation message including the PoW MAY be calculated
- ahead of time to support timely revocation.
-
- For all occurences below, "Argon2d" is the Password-based Key
- Derivation Function as defined in [Argon2]. For the PoW calculations
- the algorithm is instantiated with the following parameters:
-
- S := "gnunet-revocation-proof-of-work" /* Salt */
- t := 3 /* Iterations */
- m := 1024 /* Memory size, 1 MiB */
- T := 64 /* Tag (=output) length in bytes */
- p := 1 /* Parallelization parameter */
- v := 0x13 /* Version */
- y := 0 /* Type (Argon2d) */
- X, K is unused
-
- The following is the message string "P" on which the PoW is
- calculated:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW |
- +-----------------------------------------------+
- | TIMESTAMP |
- +-----------------------------------------------+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 15
-
- where:
-
- POW A 64-bit solution to the PoW.
-
- TIMESTAMP denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in
- network byte order.
-
- PUBLIC KEY A 512-bit ECDSA deterministic signature compliant with
- [RFC6979] over the public zone zk of the zone which is revoked and
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 20]
-
-Internet-Draft The GNU Name System November 2019
-
-
- corresponds to the key used in the PoW. The signature is created
- using the private zone key "d" (see Section 2).
-
- Traditionally, PoW schemes require to find a "POW" such that at least
- D leading zeroes are found in the hash result. D is then referred to
- as the "difficulty" of the PoW. In order to reduce the variance in
- time it takes to calculate the PoW, we require that a number "Z"
- different PoWs must be found that on average have "D" leading zeroes.
-
- The resulting proofs may then published and disseminated. The
- concrete dissemination and publication methods are out of scope of
- this document. Given an average difficulty of "D", the proofs have
- an expiration time of EPOCH. With each additional bit difficulty,
- the lifetime of the proof is prolonged for another EPOCH.
- Consequently, by calculating a more difficult PoW, the lifetime of
- the proof can be increased on demand by the zone owner.
-
- The parameters are defined as follows:
-
- Z The number of PoWs required is fixed at 32.
-
- D The difficulty is fixed at 25.
-
- EPOCH A single epoch is fixed at 365 days.
-
- Given that proof has been found, a revocation data object is defined
- as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TTL |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_0 |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | POW_Z-1 |
- +-----------------------------------------------+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 16
-
- where:
-
- TIMESTAMP denotes the absolute 64-bit expiration date of the
- revocation. In microseconds since midnight (0 hour), January 1,
- 1970 in network byte order.
-
- TTL denotes the relative 64-bit time to live of of the record in
- microseconds also in network byte order. This field is
- informational for a verifier. The verifier may discard revocation
- if the TTL indicates that it is already expired. However, the
- actual TTL of the revocation must be determined by examining the
- leading zeros in the proof of work calculation.
-
- POW_i The values calculated as part of the PoW. Each POW_i MUST be
- unique in the set of POW values.
-
- SIGNATURE A 512-bit ECDSA deterministic signature compliant with
- [RFC6979] over the public zone zk of the zone which is revoked and
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 22]
-
-Internet-Draft The GNU Name System November 2019
-
-
- corresponds to the key used in the PoW. The signature is created
- using the private zone key "d" (see Section 2).
-
- PUBLIC KEY is the 256-bit public key "zk" of the zone which is being
- revoked and the key to be used to verify SIGNATURE. The wire
- format of this value is defined in [RFC8032], Section 5.1.5.
-
- The signature over the public key covers a 32 bit pseudo header
- conceptually prefixed to the public key. The pseudo header includes
- the key length and signature purpose:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIZE (0x30) | PURPOSE (0x03) |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TIMESTAMP |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 17
-
- where:
-
- SIZE A 32-bit value containing the length of the signed data in
- bytes (48 bytes) in network byte order.
-
- PURPOSE A 32-bit signature purpose flag. This field MUST be 3 (in
- network byte order).
-
- PUBLIC KEY / TIMESTAMP Both values as defined in the revocation data
- object above.
-
- In order to verify a revocation the following steps must be taken, in
- order:
-
- 1. The current time MUST be between TIMESTAMP and TIMESTAMP+TTL.
-
- 2. The signature MUST match the public key.
-
- 3. The set of POW values MUST NOT contain duplicates.
-
- 4. The average number of leading zeroes resulting from the provided
- POW values D' MUST be greater than D.
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
-
-Internet-Draft The GNU Name System November 2019
-
-
- 5. The validation period (TTL) of the revocation is calculated as
- (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to
- deal with unsynchronized clocks. The TTL added on top of the
- TIMESTAMP yields the expiration date.
-
-8. Determining the Root Zone and Zone Governance
-
- The resolution of a GNS name must start in a given start zone
- indicated to the resolver using any public zone key. The local
- resolver may have a local start zone configured/hard-coded which
- points to a local or remote start zone key. A resolver client may
- also determine the start zone from the suffix of the name given for
- resolution or using information retrieved out of band. The
- governance model of any zone is at the sole discretion of the zone
- owner. However, the choice of start zone(s) is at the sole
- discretion of the local system administrator or user.
-
- This is an important distinguishing factor from the Domain Name
- System where root zone governance is centralized at the Internet
- Corporation for Assigned Names and Numbers (ICANN). In DNS
- terminology, GNS roughly follows the idea of a hyper-hyper local root
- zone deployment, with the difference that it is not expected that all
- deployments use the same local root zone.
-
- In the following, we give examples how a local client resolver SHOULD
- discover the start zone. The process given is not exhaustive and
- clients MAY suppliement it with other mechanisms or ignore it if the
- particular application requires a different process.
-
- GNS clients SHOULD first try to interpret the top-level domain of a
- GNS name as a zone key. For example. if the top-level domain is a
- Base32-encoded public zone key "zk", the root zone of the resolution
- process is implicitly given by the name:
-
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
-
- In GNS, users MAY own and manage their own zones. Each local zone
- SHOULD be associated with a single GNS label, but users MAY choose to
- use longer names consisting of multiple labels. If the name of a
- locally managed zone matches the suffix of the name to be resolved,
- resolution SHOULD start from the respective local zone:
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 24]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
-
- Finally, additional "suffix to zone" mappings MAY be configured.
- Suffix to zone key mappings SHOULD be configurable through a local
- configuration file or database by the user or system administrator.
- The suffix MAY consist of multiple GNS labels concatenated with a
- ".". If multiple suffixes match the name to resolve, the longest
- matching suffix MUST BE used. The suffix length of two results
- cannot be equal, as this would indicate a misconfiguration. If both
- a locally managed zone and a configuration entry exist for the same
- suffix, the locally managed zone MUST have priority.
-
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
-
-9. Security Considerations
-
-9.1. Cryptography
-
- The security of cryptographic systems depends on both the strength of
- the cryptographic algorithms chosen and the strength of the keys used
- with those algorithms. The security also depends on the engineering
- of the protocol used by the system to ensure that there are no non-
- cryptographic ways to bypass the security of the overall system.
-
- This document concerns itself with the selection of cryptographic
- algorithms for use in GNS. The algorithms identified in this
- document are not known to be broken (in the cryptographic sense) at
- the current time, and cryptographic research so far leads us to
- believe that they are likely to remain secure into the foreseeable
- future. However, this isn't necessarily forever, and it is expected
- that new revisions of this document will be issued from time to time
- to reflect the current best practices in this area.
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 25]
-
-Internet-Draft The GNU Name System November 2019
-
-
-9.2. Abuse mitigation
-
- GNS names are UTF-8 strings. Consequently, GNS faces similar issues
- with respect to name spoofing as DNS does for internationalized
- domain names. In DNS, attackers may register similar sounding or
- looking names (see above) in order to execute phishing attacks. GNS
- zone administrators must take into account this attack vector and
- incorporate rules in order to mitigate it.
-
- Further, DNS can be used to combat illegal content on the internet by
- having the respective domains seized by authorities. However, the
- same mechanisms can also be abused in order to impose state
- censorship, which ist one of the motivations behind GNS. Hence, such
- a seizure is, by design, difficult to impossible in GNS.
-
-9.3. Zone management
-
- In GNS, zone administrators need to manage and protect their zone
- keys. Once a zone key is lost it cannot be recovered. Once it is
- compromised it cannot be revoked (unless a revocation was pre-
- calculated and is still available). Zone administrators, and for GNS
- this includes end-users, are required to responsibly and dilligently
- protect their cryptographic keys.
-
- Similarly, users are required to manage their local root zone. In
- order to ensure integrity and availability or names, users must
- ensure that their local root zone information is not compromised or
- outdated. It can be expected that the processing of zone revocations
- and an initial root zone is provided with a GNS client implementation
- ("drop shipping"). Extension and customization of the zone is at the
- full discretion of the user.
-
-9.4. Impact of underlying DHT
-
- This document does not specifiy the properties of the underlying
- distributed hash table (DHT) which is required by any GNS
- implementation. For implementors, it is important to note that the
- properties of the DHT are directly inherited by the GNS
- implementation. This includes both security as well as other non-
- functional properties such as scalability and performance.
- Implementors should take great care when selecting or implementing a
- DHT for use in a GNS implementation. DHTs with string security and
- performance guarantees exist [R5N]. It should also be taken into
- consideration that GNS implementations which build upon different DHT
- overlays are unlikely to be interoperable with each other.
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 26]
-
-Internet-Draft The GNU Name System November 2019
-
-
-9.5. Revocations
-
- Zone administrators are advised to pre-generate zone revocations and
- securely store the revocation information in case the zone key is
- lost, compromised or replaced in the furture. Pre-calculated
- revocations may become invalid due to expirations or protocol changes
- such as epoch adjustments. Conseuquently, implementors and users
- must make precautions in order to manage revocations accordingly.
-
- Revocation payloads do NOT include a 'new' key for key replacement.
- In inclusion of such a key would have two major disadvantages:
-
- If revocation is used after a private key was compromised, allowing
- key replacement would be dangerous, because if an adversary took over
- the private key, the adversary could then broadcast a revocation with
- a key replacement. For the replacement, the compromised owner would
- have no chance to issue even a revocation. Thus, allowing a
- revocation message to replace a private key makes dealing with key
- compromise situations worse.
-
- Sometimes, key revocations are used with the objective of changing
- cryptosystems. Migration to another cryptosystem by replacing keys
- via a revocation message would only be secure as long as both
- cryptosystems are still secure against forgery. Such a planned, non-
- emergency migration to another cryptosystem should be done by running
- zones for both ciphersystems in parallel for a while. The migration
- would conclude by revoking the legacy zone key only once it is deemed
- no longer secure, and hopefully after most users have migrated to the
- replacement.
-
-10. GANA Considerations
-
- GANA is requested to create an "GNU Name System Record Types"
- registry. The registry shall record for each entry:
-
- * Name: The name of the record type (case-insensitive ASCII string,
- restricted to alphanumeric characters
-
- * Number: 32-bit, above 65535
-
- * Comment: Optionally, a brief English text describing the purpose
- of the record type (in UTF-8)
-
- * Contact: Optionally, the contact information of a person to
- contact for further information
-
- * References: Optionally, references describing the record type
- (such as an RFC)
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 27]
-
-Internet-Draft The GNU Name System November 2019
-
-
- The registration policy for this sub-registry is "First Come First
- Served", as described in [RFC8126]. GANA is requested to populate
- this registry as follows:
-
- Number | Name | Contact | References | Description
- -------+---------+---------+------------+-------------------------
- 65536 | PKEY | N/A | [This.I-D] | GNS zone delegation
- 65537 | NICK | N/A | [This.I-D] | GNS zone nickname
- 65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
- 65539 | VPN | N/A | [This.I-D] | VPN resolution
- 65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
- 65541 | BOX | N/A | [This.I-D] | Boxed record
-
- Figure 18
-
-11. Test Vectors
-
- The following represents a test vector for a record set with a DNS
- record of type "A" as well as a GNS record of type "PKEY" under the
- label "test".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 28]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Zone private key (d):
- WGb/eoy8BDWvaK2vRab0xTlqvS0+PeS5HG5Rh4z4cWI=
- Zone public key (zk):
- n7TNZeJ+Ks6wQymnwjZXR/cj0ae8NZMZ/PcuDVrONAo=
- Label: test
- RRCOUNT: 2
-
- Record #0
- EXPIRATION: 1589117218087117
- DATA_SIZE: 4
- TYPE: 1
- FLAGS: 0
- DATA (base64):
- AQIDBA==
- DATA (Human readable):
- 1.2.3.4
-
- Record #1
- EXPIRATION: 1589117218087117
- DATA_SIZE: 32
- TYPE: 65536
- FLAGS: 2
- DATA (base64):
- +AT14h9SMRAwkor+azlHpE8DkvsUyeQyN49NEmsOXew=
- DATA (Human readable):
- Z02FBRGZA8RH0C4JHBZ6PEA7MH7G74QV2K4Y8CHQHX6H4TREBQP0
-
- RDATA:
- AAWlSy9KYM0AAAAEAAAAAQAAAAABAgMEAAWlSy9KYM0AAAAgAAEAAAAAAAL4BPXi
- H1IxEDCSiv5rOUekTwOS+xTJ5DI3j00Saw5d7AAAAAAAAAAAAAAAAAAAAAAAAAAA
- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-
- BDATA:
- 5e5936fttKU61GByslXav57Zgi4rac2N0F6VJCKC7NVn1YPJyiL/0+f2vZSUfHpk
- ZfRPv9clYgzO4m+PdRcYFpkG0vqmrFnDNJQRd/y9V2Wfg4ud82FK3CT9lcMpu6Sd
- fbZyE8PmL7cySfdMa/RsNWCVAES98UOvNJ7CaBDJlY2mb6iA
-
- RRBLOCK:
- Cqk3xJHTNxM1EE69iH33z0dK78FrhK+gUHMIUY//WHYCPZmbdgJc5Avb9uVTAAyT
- 5No5uINZwxXuWpL72Xh4IIqWAE/BdKHS9deQusO6CSiZN1swM5zsupJq1qjgHusG
- AAAAlAAAAA8ABaVLL0pgzeXufd+n7bSlOtRgcrJV2r+e2YIuK2nNjdBelSQiguzV
- Z9WDycoi/9Pn9r2UlHx6ZGX0T7/XJWIMzuJvj3UXGBaZBtL6pqxZwzSUEXf8vVdl
- n4OLnfNhStwk/ZXDKbuknX22chPD5i+3Mkn3TGv0bDVglQBEvfFDrzSewmgQyZWN
- pm+ogA==
-
-
- The following is an example revocation for a zone:
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 29]
-
-Internet-Draft The GNU Name System November 2019
-
-
- Zone private key (d):
- SLZnT2NK3cusTfuI0CM+XJiP4U43ZsCAv+Lk3FbIXHc=
-
- Zone public key (zk):
- bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
-
- Difficulty (5 base difficulty + 2 epochs): 7
-
- Proof:
- AAWkvp6KGBVAxXvM//8AALpHh010jxRdukeHTXSPEhq6R4dNdI8VDbpHh010jxUy
- ukeHTXSPGNK6R4dNdI8ZXLpHh010jxTTukeHTXSPFSW6R4dNdI8VarpHh010jxV3
- ukeHTXSPFnC6R4dNdI8X5rpHh010jxoJukeHTXSPGqm6R4dNdI8aurpHh010jxwD
- ukeHTXSPHGm6R4dNdI8cvLpHh010jxdGukeHTXSPF426R4dNdI8XxrpHh010jxif
- ukeHTXSPGL26R4dNdI8ZJLpHh010jxlTukeHTXSPGsa6R4dNdI8bfLpHh010jxuV
- ukeHTXSPHCi6R4dNdI8eC7pHh010jx4VukeHTXSPHhsJejeXmcDe4jcfEkWLqwIA
- 8zG/gFIxNYu34usglSp+7w8bbtTgMD5hLGiR+xxhgpPh36dGz1KBZ9kAh9pz77yS
- bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
-
-
-12. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
- <https://www.rfc-editor.org/info/rfc1034>.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
- November 1987, <https://www.rfc-editor.org/info/rfc1035>.
-
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- DOI 10.17487/RFC2782, February 2000,
- <https://www.rfc-editor.org/info/rfc2782>.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119,
- DOI 10.17487/RFC2119, March 1997,
- <https://www.rfc-editor.org/info/rfc2119>.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
- 2003, <https://www.rfc-editor.org/info/rfc3629>.
-
- [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
- Advanced Encryption Standard (AES) Cipher Algorithm in the
- SNMP User-based Security Model", RFC 3826,
- DOI 10.17487/RFC3826, June 2004,
- <https://www.rfc-editor.org/info/rfc3826>.
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 30]
-
-Internet-Draft The GNU Name System November 2019
-
-
- [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
- Key Derivation Function (HKDF)", RFC 5869,
- DOI 10.17487/RFC5869, May 2010,
- <https://www.rfc-editor.org/info/rfc5869>.
-
- [RFC5890] Klensin, J., "Internationalized Domain Names for
- Applications (IDNA): Definitions and Document Framework",
- RFC 5890, DOI 10.17487/RFC5890, August 2010,
- <https://www.rfc-editor.org/info/rfc5890>.
-
- [RFC5891] Klensin, J., "Internationalized Domain Names in
- Applications (IDNA): Protocol", RFC 5891,
- DOI 10.17487/RFC5891, August 2010,
- <https://www.rfc-editor.org/info/rfc5891>.
-
- [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
- Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
- April 2013, <https://www.rfc-editor.org/info/rfc6895>.
-
- [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
- Algorithm (DSA) and Elliptic Curve Digital Signature
- Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
- 2013, <https://www.rfc-editor.org/info/rfc6979>.
-
- [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
- for Security", RFC 7748, DOI 10.17487/RFC7748, January
- 2016, <https://www.rfc-editor.org/info/rfc7748>.
-
- [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
- Signature Algorithm (EdDSA)", RFC 8032,
- DOI 10.17487/RFC8032, January 2017,
- <https://www.rfc-editor.org/info/rfc8032>.
-
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
- Writing an IANA Considerations Section in RFCs", BCP 26,
- RFC 8126, DOI 10.17487/RFC8126, June 2017,
- <https://www.rfc-editor.org/info/rfc8126>.
-
- [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
- 128-Bit Block Cipher, 1st Edition", March 1999.
-
- [GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A
- Censorship-Resistant, Privacy-Enhancing and Fully
- Decentralized Name System", 2014,
- <https://doi.org/10.1007/978-3-319-12280-9_9>.
-
- [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 31]
-
-Internet-Draft The GNU Name System November 2019
-
-
- routing for restricted-route networks", 2011,
- <https://doi.org/10.1109/ICNSS.2011.6060022>.
-
- [Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
- Josefsson, "The memory-hard Argon2 password hash and
- proof-of-work function", March 2020,
- <https://datatracker.ietf.org/doc/draft-irtf-cfrg-
- argon2/>.
-
-Authors' Addresses
-
- Martin Schanzenbach
- GNUnet e.V.
- Boltzmannstrasse 3
- 85748 Garching
- Germany
-
- Email: schanzen@gnunet.org
-
-
- Christian Grothoff
- Berner Fachhochschule
- Hoeheweg 80
- CH-2501 Biel/Bienne
- Switzerland
-
- Email: schanzen@gnunet.org
-
-
- Bernd Fix
- GNUnet e.V.
- Boltzmannstrasse 3
- 85748 Garching
- Germany
-
- Email: fix@gnunet.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 32]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -66,7 +66,7 @@
</address>
</author>
- <date day="10" month="November" year="2019"/>
+ <date day="31" month="May" year="2020"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Independent Stream</workgroup>
