Internet-Draft The GNS SBOX Record Type December 2023
Nadler & Schanzenbach Expires 16 June 2024 [Page]
Workgroup:
GNUnet
LSD:
0008
Published:
Intended Status:
Informational
Expires:
Authors:
S. Nadler
Technische Universität München
M. Schanzenbach
Fraunhofer AISEC

The GNS SBOX Record Type

Abstract

This document provides an extension to the GNU Name System (GNS) technical specification [RFC9498]. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols.

This document defines the normative wire format of an additional resource record and a modified resolution processes for use by implementers.

This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations (for example, pre-existing GNUnet implementations).

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 16 June 2024.

▲

Table of Contents

1. Introduction

This specification describes additions to the GNU Name System (GNS) [RFC9498], a censorship-resistant, privacy-preserving, and decentralized domain name resolution protocol. GNS cryptographically secures the binding of names to arbitrary tokens, enabling it to double in some respects as an alternative to some of today's public key infrastructures.

This LSD document is an extension to the GNS technical specification [RFC9498]. It is intended to be read in conjunction with the GNS technical specification.

A new record type is defined to extend the GNS to support a wider range of underscore labels. The new record type is called SBOX and is intended to handle all variations of underscore labels the BOX record type is not able to.

This document defines the normative wire format of the SBOX resource record and resolution processes for use by implementers.

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

The terminology defined in [RFC9498] also applies to this document.

This document includes the following additional terms:

Underscore label:
A label is considered an underscore label only if it begins with an underscore. (e.g., "_name")
Underscore prefix:
The underscore prefix contains the rightmost underscore label and all subsequent labels to its left. For example, the underscore prefix of "_service._proto.example.gns.alt" is "_service._proto" and the underscore prefix of "c93f1e400.abcd._info.example.gns.alt" is "c93f1e400.abcd._info".

3. Resource Records

3.1. Auxiliary Records

This section defines an additional auxiliary GNS record type. Any implementation SHOULD be able to process the specified record types according to Section 4.1.

3.1.1. SBOX

GNS lookups are expected to return all of the required useful information in one record set. This avoids unnecessary additional lookups and cryptographically ties together information that belongs together, making it impossible for an adversarial storage entity to provide partial answers that might omit information critical for security.

This general strategy 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.

This way of handling and storing restricts the allowed and processable underscore prefixes to the format of "_SERVICE._PROTOCOL" as well as only services registered in the corresponding IANA registry. A new SBOX record is proposed to enable the use of labels such as "c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._smimecert" and other variations of underscore prefixes for SMIMEA/URI/SRV, and other records. The SBOX record is supposed to handle all variations of underscore prefixes. The idea is to store the string representation of the underscore prefix instead of the service and protocol numbers. A SBOX record boxes the record's type and data as well as the underscore prefix, and adds them to the record set of the associated label. For example, a URI record for "_scheme._trust.example.gns.alt" will be stored as an SBOX record in the record set of "example.gns.alt" with the underscore prefix "_schema._trust" and record type URI and the URI records data.

For reference, see also [RFC8552].

A SBOX DATA entry is illustrated in Figure 1.

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          TYPE         |         PREFIX        /
+-----------+-----------+                       /
/                                               /
/                                               /
+-----------------------------------------------+
/                 RECORD DATA                   /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 1: The SBOX DATA Wire Format
TYPE:
The 32-bit record type of the boxed record in network byte order.
PREFIX:
A variable-length field containing the first GNS name prefix consisting of multiple labels. The rightmost label MUST begin with an underscore. PREFIX MUST be a zero terminated string.
RECORD DATA:
A variable-length field containing the "DATA" format of TYPE as defined for the respective TYPE. Thus, for TYPE values below 216, the format is the same as the respective record type's binary format in DNS.
3.1.1.1. Overlap of BOX and SBOX records

Records saved as BOX records can also be saved as SBOX records. Thus, upon encountering underscore labels processable by BOX records, the resolver must store the labels as their protocol and service numbers, as well as the underscore prefix. This way, the resolver should be able to return all boxed records later, whether they are SBOX or BOX records. More on this in Section 4. BOX records are more efficient for boxing resource records due to their smaller wire format. Therefore, SBOX records are not a replacement for BOX records.

4. Name Resolution

4.1. Record Processing

The first step in processing the records remains the same as described in [RFC9498] Section 7.

The next step depends on the context of the name being resolved. Case 3, as defined in [RFC9498] Section 7.3, is modified here. All other cases and further processing steps remain the same.

Case 3:
If the record set contains SBOX records and the name to be resolved is an underscore prefix, the records in the matching SBOX records are part of the final result. The recursion is processed as described in Section 4.1.2. Additionally, it MUST be checked whether the record set contains BOX records and the underscore prefix is in the format "_SERVICE._PROTO". If this is the case the matching BOX records are added to the final result. The recursion is processed as described in Section 4.1.1. The final result is the combination of the unboxed record sets of the matched SBOX and BOX records.

4.1.1. 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.

4.1.2. SBOX

When a SBOX record is received, a GNS resolver must unbox it if the name to be resolved continues with an underscore prefix. Otherwise, the SBOX record is to be left untouched.

5. GANA Considerations

5.1. GNS Record Types Registry

GANA [GANA] manages the "GNS Record Types" registry.

GANA has assigned a number for the record type SBOX defined in this specification in the "GNS Record Types" registry as listed in Table 1.

Table 1: The GANA GNS Record Types Registry
Number Name Contact References Comment
65547 SBOX (*) LSD 0008 SBOX records
(*): gns-registry@gnunet.org

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[GANA]
GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", , <https://gana.gnunet.org/>.

6.2. Informative References

[RFC8552]
Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, , <https://www.rfc-editor.org/info/rfc8552>.
[RFC9498]
Schanzenbach, M., Grothoff, C., and B. Fix, "The GNU Name System", RFC 9498, DOI 10.17487/RFC9498, , <https://www.rfc-editor.org/info/rfc9498>.

Authors' Addresses

Sebastian Nadler
Technische Universität München
Martin Schanzenbach
Fraunhofer AISEC
Lichtenbergstrasse 11
85748 Garching
Germany