Nameserver Access Modes with Encryption Held in Alphanumeric Configuration KeysGoogle LLCbemasc@google.comGoogle LLCwarren@kumari.net
General
dpriveInternet-DraftSome recent proposals to the DPRIVE working group rely on the use of SVCB records to provide instructions about how to reach an authoritative nameserver over an encrypted transport. These proposals will be difficult to deploy until the parent domain's delegation software has been modified to support these records. As an interim solution for these domains, this draft proposes encoding relevant signals in the child's NS-name.Discussion VenuesDiscussion of this document takes place on the
mailing list (dns-privacy@ietf.org),
which is archived at .Source for this draft and an issue tracker can be found at
.Conventions and DefinitionsThe 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 when, and only when, they
appear in all capitals, as shown here.Background defines how to use SVCB records to describe the secure transport protocols supported by a DNS server. describes the use of such records on the names of nameservers (the "NS name") to enable opportunistic encryption of recursive-to-authoritative DNS queries. Resolvers are permitted to fetch SVCB records asynchronously and cache them, resulting in "partial opportunistic encryption": even without an active adversary forcing a downgrade, queries will sometimes be sent in cleartext. Participating authoritative nameservers and recursive resolvers would have to be modified to make use of these records.When the child zone is DNSSEC-signed, publishing a SVCB record of this kind is technically sufficient to enable authenticated encryption. However, in order to support reliable authentication, recursive resolvers would have to query for a SVCB record on every signed delegation, and wait for a response before issuing their intended query. We call this behavior a "synchronous binding check".Many validating resolvers might not be willing to enable a "synchronous binding check" behavior, as this would slow down resolution of many existing domains in order to enable a new feature (authenticated encryption) that is not yet used at all. To enable authenticated encryption without this general performance loss, proposes to deliver the SVCB records from the parent, in the delegation response. This avoids the need for a binding check, at the cost of additionally requiring modifications to the parent nameserver, which must provide these extra records in delegation responses.Providing these additional records is sufficient to enable "full opportunistic encryption": the transport is always encrypted in the absence of an active adversary. However, these records are not protected by DNSSEC, so the child can only achieve fully authenticated encryption if the parent also implements fully authenticated encryption or otherwise protects the delivery of these records.Even if this approach is standardized, many parent zones may not support delivery of SVCB records in delegation responses in the near future. To enable the broadest use of encrypted transport, we may need an interim solution that can be deployed more easily.ProposalWe propose to indicate a nameserver's support for encrypted transports using a signal encoded in its name. This signal takes two forms: a "flag" and a "menu".
QUESTION: Do we need both of these forms, or should we drop one?
We note that encoding semantics in DNS labels is a hack, but believe that the privacy benefits outweigh the ick factor.In either form, the signal helps resolvers to acquire a SVCB RRSet for the nameserver. Resolvers use this RRSet as specified in .Flag formIf the NS name's first label is svcb, this is regarded as a "flag". When contacting a flagged nameserver, participating resolvers SHOULD perform a synchronous binding check, and upgrade to a secure transport if appropriate, before issuing the query.The presence of this flag does not guarantee that the corresponding SVCB records are actually present.Menu formIf the NS name's first label starts with svcb--, the label's subsequent characters represent a "menu" of connection options, which can be decoded into a SVCB RRSet. To decode the RRSet, each character is transformed into a SVCB RR with the following components:
The owner name is the NS name plus the prefix label "_dns".
The SvcPriority is the character's order in the list (starting at 1)
The TargetName is the NS name
The SvcParams are indicated in the registry entry for this menu character ().
For example, the name "svcb-qt.ns3.example." would be decoded to this RRSet:The menu characters are a-z and 0-9; all other characters are reserved for future use. Upon encountering any character outside these ranges, parsers MUST stop and return successfully. Parsers MUST ignore characters that are allowed but not recognized.
QUESTION: Do we need more than 36 codepoints? Is there a nice simple format that would give us a lot more codepoints?
QUESTION: Should we consider a format that actually encodes the SvcParams in the label instead?
Implementation requirementsResolvers that implement support for "menu" mode MUST also support the "flag" mode. Resolvers that support either mode MUST also support , and ignore the in-name signal if any SVCB records are included in a delegation response.When possible, zones SHOULD use SVCB records in the delegation response and omit any in-name signal.Security ConsiderationsNS names received during delegation are not protected by DNSSEC. Therefore, just like in , this scheme only enables authenticated encryption if the parent domain can provide authentication without DNSSEC validation, e.g. using a secure transport or Zone Digest .
QUESTION: Do we expect to have parent zones that can provide authenticated NS names but cannot provide authenticated SVCB records in delegation responses? (Maybe the root, with ZONEMD?) If not, does this proposal provide enough value?
Operational ConsiderationsIt is possible that an existing NS name already matches the "flag" pattern. Such a "false positive flag" will result in a small performance loss due to the unnecessary synchronous binding check, but will not otherwise impair functionality.If a pre-existing NS name contains the menu pattern, that nameserver will become unreachable by resolvers implementing this specification. The authors believe that no such nameservers are currently deployed, and such servers are unlikely to be deployed by accident.IANA ConsiderationsIANA is requested to create a new registry entitled "Authoritative Server Transport In-Name Signal Characters", with the following fields:
Character: a digit or lower-case letter
SvcParams: a valid SVCB SvcParams set in presentation format
The registry policy is TBD.The initial contents (DO NOT USE, subject to change) are as follows:
Character
SvcParams
t
alpn=dot
h
alpn=h2 dohpath=/dns-query{?dns}
3
alpn=h3 dohpath=/dns-query{?dns}
q
alpn=doq
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Service Binding Mapping for DNS ServersGoogle LLC The SVCB DNS record type expresses a bound collection of endpoint
metadata, for use when establishing a connection to a named service.
DNS itself can be such a service, when the server is identified by a
domain name. This document provides the SVCB mapping for named DNS
servers, allowing them to indicate support for new transport
protocols.
Informative ReferencesRecursive to Authoritative DNS with Unauthenticated EncryptionICANNPowerDNS This document describes a use case and a method for a DNS recursive
resolver to use unauthenticated encryption when communicating with
authoritative servers. The motivating use case for this method is
that more encryption on the Internet is better, and some resolver
operators believe that unauthenticated encryption is better than no
encryption at all. The method described here is optional for both
the recursive resolver and the authoritative server. This method
supports unauthenticated encryption using the same mechanism for
discovery of encryption support for the server as [FULL-AUTH].
Signaling Authoritative DNS EncryptionApple Inc.MozillaGoogle LLCCloudflare This document defines a mechanism for signaling that a given
authoritative DNS server is reachable by encrypted DNS.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the DNS PRIVate Exchange
Working Group mailing list (dns-privacy@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/dns-privacy/.
Source for this draft and an issue tracker can be found at
https://github.com/ekr/draft-rescorla-dprive-adox.
Message Digest for DNS ZonesThis document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.Signaling That an Authoritative DNS server offers DoTDNS resolvers that wish to use DNS over TLS to authoritative servers (ADoT) need some way to tell whether server offers DoT. This document describes some ways that a server might signal that it uses DoT.Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name Server nameFacebook This document describes a mechanism to exchange the Subject Public
Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated
with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding
it as part of its name. The fingerprint can thereafter be used to
validate the certificate received from the DoT server as well as
being able to discover support for DoT on the server.
Signalling Authoritative DoT support in DS records, with key pinningPowerDNSTransIPFacebook This document specifies a way to signal the usage of DoT, and the
pinned keys for that DoT usage, in authoritative servers. This
signal lives on the parent side of delegations, in DS records. To
ensure easy deployment, the signal is defined in terms of (C)DNSKEY.
Delegation Information (Referrals) Signer for DNSSECJPRS DNSSEC does not protect delegation information, it contains NS RRSet
on the parent side and glue records. This document defines
delegation information signer (DiS) resource record for protecting
the delegation information, by inserting on the parent side of zone
cut to hold a hash of delegation information. The DiS resource
record reuses the type code and wire format of DS resource record,
and distinguishes it from existing DS RRSet by using a new digest
type. This document also describes the usage of DiS resource record
and shows the implications on security-aware resolvers. The
definition and usage are compatible with current DNSSEC.
The VERBATIM Digest Algorithm for DS recordsPowerDNS The VERBATIM DS Digest is defined as a direct copy of the input data
without any hashing.
Comparison with related designsSeveral other designs have been proposed to encode a transport upgrade signal in an existing record type.Indicating DoT support with a name prefixSection 3.6 of discusses using the "xs-" name prefix to indicate support for DNS over TLS. This is equivalent to a "svcb-t" label in this formulation. This draft may be seen as an expansion of that proposal, harmonized with the SVCB-based discovery drafts.Encoding the SPKI pin in the leaf label also proposes to encode a signal in the leaf label. The signal includes an SPKI pin, for authentication of the TLS connection.Including an SPKI pin allows authentication of the nameserver without relying on DANE or PKI validation. However, like this draft, it does not achieve authenticated encryption unless the NS name can be delivered securely during delegation. It may also create operational challenges when rotating TLS keys, due to the need to update the parent zone.Encoding the signal in an additional NS recordIt would be possible to encode the signal by adding a special NS record to the RRSet. This would avoid the need to rename any existing nameservers. However, this arrangement has different semantics: it is scoped to the entire child zone, rather than a specific nameserver. It also relies heavily on existing resolvers having robust and performant fallback behavior, which may not be a safe assumption.(Credit: Paul Hoffman)Extending the DS record encodes a signal and pin in a DS record by allocating a new fake "signature algorithm" and encoding the TLS SPKI in a DNSKEY record. This enables fully authenticated encryption (only requiring that the parent zone is signed). However, it has very limited flexibility for representing different transport configurations, and creates challenges during TLS key rotation.Enabling authentication of delegation data adds a DS record over the delegation information. When combined with this draft, this would enable fully authenticated encrypted transport. However, this approach requires very tight coherence between the child and parent (e.g. when removing a nameserver) that may not be achievable in practice. allows children to push arbitrary authenticated delegation data into the parent. This could be used to convey SVCB RRSets for the delegation securely. However, it requires parents to accept a new digest type, and bends the usual DS semantics even further.AcknowledgmentsTODO