]> The Swedish Internet Foundation

Sweden erik.bergstrom@internetstiftelsen.se

The Swedish Internet Foundation

Sweden leon.fernandez@internetstiftelsen.se

The Swedish Internet Foundation

Sweden johan.stenstam@internetstiftelsen.se

Internet DNSOP Working Group Internet-Draft This document introduces the KeyState EDNS(0) option, to enable a child operator to query a parent UPDATE Receiver about the state of a SIG(0) key used to secure cross-zone-cut DNS UPDATE messages. The KeyState option allows the child to include a key state inquiry in its DNS query, and the parent to include the corresponding key state in its response. This addresses the challenge of maintaining synchronization of SIG(0) keys between the child and the parent UPDATE Receiver: the child can become aware of any issue with its SIG(0) key in advance, before attempting the next operational DNS UPDATE. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-keystate. The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.

Introduction In a mechanism for automatic synchronization of delegation data between a child zone and a parent zone is proposed. That mechanism relies on the parent validating and subsequently trusting the child SIG(0) public key so that the child is able to sign DNS UPDATE requests to the parent using the corresponding SIG(0) private key. While there is a mechanism for both uploading and rolling the public SIG(0) key there is still a risk of the child operator and the parent receiver getting out of sync. This will be noticed by the child if a DNS UPDATE is refused. In this situation the parent UPDATE Receiver does have the opportunity and ability to provide more details of the refusal via an EDE opcode . However, at that point it is too late to immediately get back in sync again and as a result the needed delegation synchronization that triggered the DNS UPDATE will be delayed until the child has managed to "re-bootstrap" a new SIG(0) key with the parent. As such re-bootstrapping may require manual actions, the length of the delay would not always be predictable. The proposed new KeyState EDNS(0) Option addresses this problem by allowing the child and parent to exchange information about the current "state" of a SIG(0) key. This enables the child to become aware of any issue with the SIG(0) key currently being used in advance, and then address and resolve the problem. Additionally, the KeyState EDNS(0) Option enables the child to detect and resolve key synchronization issues before they cause operational failures.

Trusting SIG(0) Signed DNS Messages Between Child and Parent Using the proposed KeyState option the child gains the ability to inquire about the state of its SIG(0) key at the parent UPDATE Receiver, and the parent gains the ability to respond with the current state, independently of a new DNS UPDATE (i.e. the exchange may be sent via a normal DNS QUERY + response). It should be pointed out that for the child to be able to trust the response from the parent, the response must be signed using a key that the child trusts. As the mechanism for automatic synchronization of delegation data aims to work independently of whether the involved zones are DNSSEC-signed or not, this requires that the parent UPDATE Receiver is able to sign the response using its own SIG(0) private key. Hence there is a similar need for the UPDATE Receiver to "bootstrap" (as in "validate so that the key may be trusted") the child SIG(0) public key and for the child to "bootstrap" the UPDATE Receiver SIG(0) public key. The mechanism for doing this is described in . Knowledge of DNS NOTIFY and DNS Dynamic Updates and is assumed. DNS SIG(0) transaction signatures are documented in .

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 when, and only when, they appear in all capitals, as shown here.

Terminology

SIG(0)

A DNS transaction signature mechanism () that uses asymmetric cryptography, allowing the recipient to verify a signature using only the sender's public key.

Child, Parent

The child and parent zones on either side of a delegation, as in .

UPDATE Receiver

The entity (operated by the parent, or a registrar/agent acting on its behalf) that receives and processes DNS UPDATE messages for the delegation, as defined in .

Key state

The condition of a particular SIG(0) key as known to the UPDATE Receiver (for example, unknown, known, or trusted), signaled by the KeyState option defined in this document. The defined values are listed in .

Comparison to Extended DNS Errors EDE (Extended DNS Errors) lets the receiver of a DNS message provide more information about the reason for a negative response, carried in an OPT record as an EDE code and an optional human-readable "Extra Text". Three limitations make EDE insufficient for communicating key state between two parties: An EDE must only be present in a response, not in the originating message. An EDE must only be used to augment an error response. It should not be part of a successful response. An EDE must contain an EDE info code (16 bits) and may contain "Extra Text". However this extra text is intended for human consumption, not automated parsing. To communicate state between two parties this requirement is too strict. These are not flaws in EDE, which serves a different purpose; they simply mean that signaling key state between child and parent needs a dedicated mechanism, which this document provides.

KeyState EDNS(0) Option Format This document uses an Extended Mechanism for DNS (EDNS0) option to include Key State information in DNS messages. The option is structured as follows:

Field definition details: OPTION-CODE: 2 octets / 16 bits (defined in ) contains the value TBD for KeyState. OPTION-LENGTH: 2 octets / 16 bits (defined in ) contains the length of the payload (everything after OPTION-LENGTH) in octets and should be 4 plus the length of the EXTRA-TEXT field (which may be zero octets long). For example, for an option with no extra text OPTION-LENGTH is 4 (KEY-ID + KEY-STATE + KEY-DATA = 2 + 1 + 1 octets); for an option carrying 12 octets of extra text OPTION-LENGTH is 16. KEY-ID: 16 bits. The KeyID of the SIG(0) key that the KeyState inquiry is referring to. Note that while KeyIds are not guaranteed to be unique, it is the child that generates the initial SIG(0) key pair and all subsequent key pairs. Hence, it is the child's responsibility to not use multiple keys with the same KeyId. KEY-STATE: 8 bits. Currently defined values are listed in . Additional values may be defined in future documents. KEY-DATA: 8 bits. Interpretation specific to each KEY-STATE. EXTRA-TEXT: a variable-length sequence of octets that may hold additional information. This information is intended for human consumption (typically a reason or additional detail), not automated parsing. The length of the EXTRA-TEXT MUST be derived from the OPTION-LENGTH field. The EXTRA-TEXT field may be zero octets in length.

Use of the KeyState Option A child that wishes to receive KeyState information about its own SIG(0) key MUST include a KeyState option in its query or UPDATE message to the UPDATE Receiver. Including the option signals the child's capability and intent to receive a KeyState response; a child that does not need key-state information for a given message need not include it. The UPDATE Receiver MUST only include a KeyState option when responding to a DNS message that contained a KeyState option; that is, the UPDATE Receiver never assumes that the child is able to interpret KeyState options. A KeyState option MAY be included in any type of response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes a KeyState option. A recipient that does not understand the KeyState option ignores it. A recipient that does understand it SHOULD respond with the KeyState for the specified key (identified by the KEY-ID field), unless local policy or operational constraints (for example, rate limiting) prevent it. When such a response is sent, it MUST meet the requirements in (signed by the UPDATE Receiver's SIG(0) key and carrying a KeyState option). This document includes a set of initial "key state" codepoints but is extensible via the IANA registry defined and created in .

Defined and Reserved Values for SIG(0) Key States This document defines a number of initial KEY-STATE codes. The mechanism is intended to be extensible and additional KEY-STATE codes can be registered in the "KeyState Codes" registry (see ). The KEY-STATE code from the "KeyState" EDNS(0) option is used to serve as an index into the "KeyState Codes" registry with the initial values defined below. For KeyState signaling to be used the child includes a KeyState option in its query to indicate the ability to interpret a KeyState option in the response. The KEY-STATE code space is divided into three ranges by who sets the value and what it conveys: protocol-level responses (0-1, set by the UPDATE Receiver), inquiries set by the sender (2-3), and key-state reports set by the UPDATE Receiver (4-127). Private Use occupies 128-255.

Protocol-Level Responses (Set By The UPDATE Receiver) These codes report on the KeyState exchange itself rather than on the state of any particular key. They are the KeyState equivalents of the DNS FORMERR and SERVFAIL conditions. 0 (KEY_REQUEST_MALFORMED): The KeyState request could not be understood; for example, it carried an unrecognized or unassigned KEY-STATE value (see below), an invalid KEY-DATA value, or a KeyState option that could not be parsed. The KEY-ID field MUST echo the KEY-ID from the request if it could be parsed, and MUST be 0 otherwise. KEY-DATA MUST be 0. 1 (KEY_TEMPORARY_FAILURE): The UPDATE Receiver understood the request but is temporarily unable to determine the state of the key. The child MAY retry the inquiry later. KEY-DATA MUST be 0. An UPDATE Receiver that receives a KeyState option whose KEY-STATE value it does not recognize, including the unassigned values 3 and 11-127, MUST treat the request as malformed and respond with code 0 (KEY_REQUEST_MALFORMED).

KeyStates Set By The Sender (the Child) 2: Key inquiry. Child requests information about the current KeyState for the specified key. KEY-DATA MUST be 0. Code 3 is unassigned. Together with codes 0 and 1, codes 2 and 3 were used differently in earlier revisions; see for the historical context.

KeyStates Set By The UPDATE Receiver (the Parent or Its Agent) 4 (KEY_TRUSTED): The SIG(0) key is known and trusted. KEY-DATA MUST be 0. 5 (KEY_UNKNOWN): The SIG(0) key is unknown. KEY-DATA MUST be 0. 6 (KEY_INVALID): The SIG(0) key is invalid (e.g. the key data does not match the declared algorithm). KEY-DATA MAY carry a receiver-defined sub-reason code; if no sub-reason is offered, KEY-DATA MUST be 0. 7 (KEY_REFUSED): The SIG(0) key is refused (e.g. the algorithm is not accepted by policy). KEY-DATA MAY carry a receiver-defined sub-reason code; if no sub-reason is offered, KEY-DATA MUST be 0. 8 (KEY_VALIDATION_FAILED): The SIG(0) key is known but validation has failed. This corresponds to the bootstrap state described in Section "Communication in Case of Errors" as "SIG(0) key is known, but validation failed". KEY-DATA MUST be 0. 9 (KEY_BOOTSTRAP_AUTO): The SIG(0) key is known but not yet trusted; automatic bootstrap is in progress. This corresponds to the bootstrap state described in Section "Communication in Case of Errors" as "SIG(0) key is known, but not yet trusted". KEY-DATA MUST be 0. 10 (KEY_BOOTSTRAP_MANUAL): The SIG(0) key is known but not trusted; manual bootstrap is required. This corresponds to the bootstrap state described in Section "Communication in Case of Errors" as "Automatic bootstrap of SIG(0) keys not supported; manual bootstrap required". KEY-DATA MUST be 0. 128-255: Reserved for Private Use. To ensure that the SIG(0) bootstrap is correctly prepared, the child (or an agent for the child) sends a DNS QUERY to the parent UPDATE Receiver with QNAME="child.parent." and QTYPE=KEY containing a KeyState option with KEY-STATE=2 (INTENT_INQUIRE_KEY) and the KeyId of the SIG(0) key to inquire about in the KEY-ID field. See Section "Communication To Inquire State" for the canonical use case. The response MUST be signed by the SIG(0) key for the UPDATE Receiver and MUST contain a KeyState option carrying the KeyId and the corresponding KEY-STATE as defined above. The mechanism by which the child obtains and validates the UPDATE Receiver's SIG(0) public key is specified in Section "Bootstrapping the UPDATE Receiver's Key Into the Child".

Security Considerations Key state signals in OPT queries and answers are unauthenticated unless the transaction carrying the state signal is secured via mechanisms such as , , , , or . Unauthenticated information MUST NOT be trusted as the state signals influence the DNS protocol processing. For instance, an attacker might cause a denial-of-service by forging a response claiming that the victim's key is invalid, thereby halting the delegation synchronization procedure. Moreover, it is assumed that the child has some means of validating messages from the parent during the initial phase when the child initializes the SIG(0) key synchronization. Otherwise, an attacker could prevent a child from initializing the synchronization by spoofing responses that refuse the key that the child is trying to upload. For that reason, it is expected that the parent has already published a public key that the child can use for this purpose. It could also possibly establish this trust out-of-band, such as via a physical meeting. Lastly, SIG(0) transaction signatures are vulnerable to replay attacks, which could allow an attacker to disrupt the synchronization. Secure transport alternatives exist in , , and .

IANA Considerations

New KeyState EDNS Option This document defines a new EDNS(0) option, entitled "KeyState", assigned a value of TBD in the "DNS EDNS0 Option Codes (OPT)" registry Value Name Status Reference TBD KeyState Standard (This document)

A New Registry for KeyState Codes The KeyState option defines an 8-bit state field, for which IANA is requested to create and maintain a new registry entitled "KeyState Codes", used by the KeyState option. Initial values for the "KeyState Codes" registry are given below; future assignments in the 11-127 range are to be made through Specification Required review . KEY STATE Mnemonic Set by Reference 0 KEY_REQUEST_MALFORMED Receiver (This document) 1 KEY_TEMPORARY_FAILURE Receiver (This document) 2 INTENT_INQUIRE_KEY Sender (This document) 3 Unassigned -- (This document) 4 KEY_TRUSTED Receiver (This document) 5 KEY_UNKNOWN Receiver (This document) 6 KEY_INVALID Receiver (This document) 7 KEY_REFUSED Receiver (This document) 8 KEY_VALIDATION_FAILED Receiver (This document) 9 KEY_BOOTSTRAP_AUTO Receiver (This document) 10 KEY_BOOTSTRAP_MANUAL Receiver (This document) 11-127 Unassigned -- (This document) 128-255 Private Use -- (This document) The code space is grouped as follows: codes 0-1 are protocol-level responses set by the UPDATE Receiver (the KeyState equivalents of FORMERR and SERVFAIL); codes 2-3 are set by the sender (the child), of which only 2 is currently defined; and codes 4-127 are key-state reports set by the UPDATE Receiver. Codes 0 and 1 were used in draft-berra-dnsop-keystate-02 as the sender codes REQUEST_AUTO_BOOTSTRAP and REQUEST_MANUAL_BOOTSTRAP. Those uses were removed in -03 (bootstrap initiation and bootstrap-method discovery are handled by the self-signed DNS UPDATE and the SVCB bootstrap SvcParamKey specified in ), and the codepoints are reassigned here as the protocol-level responses described above.

This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] In 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. RFC 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. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in [RFC9859]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns (https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via- ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

Change History (to be removed before publication) draft-berra-dnsop-keystate-03

• Aligned the draft with : mapped each KeyState code to the corresponding named bootstrap state in that document, and added cross-references to the specific sections where the KeyState mechanism is used (state inquiry, re-bootstrapping, mutual authentication).

• Removed the former sender codes 0 and 1 ("Automatic bootstrap requested" and "Manual bootstrap requested"). Bootstrap initiation and bootstrap-method discovery are handled by other mechanisms (the self-signed DNS UPDATE and the SVCB "bootstrap" SvcParamKey in ); KeyState is now used purely for key-state inquiry and reporting.

• Added two protocol-level response codes for reporting on the KeyState exchange itself rather than on a key: KEY_REQUEST_MALFORMED (the equivalent of DNS FORMERR) and KEY_TEMPORARY_FAILURE (SERVFAIL), filling the previous gap where a receiver could not say "I could not understand your request" or "I cannot answer right now". Rather than leave a hole where the removed sender codes 0 and 1 had been, those two now-free codepoints are reused for these responses, giving a clean grouping: 0-1 protocol-level (receiver-set), 2-3 sender-set (only 2 defined), 4-127 key-state reports (receiver-set). This is an incompatible change to codepoints 0 and 1 relative to draft-berra-dnsop-keystate-02. A receiver MUST answer an unrecognized or unassigned KEY-STATE with KEY_REQUEST_MALFORMED.

• Specified the contents of the KEY-DATA field per KeyState code.

• Reworded the abstract (removed the "mutual awareness" overreach; the mechanism is child-inquires / parent-responds) and the "Use of the KeyState Option" text (removed the contradictory "may be included" / "MUST be present" wording). Added a cross-reference from Security Considerations to the receiver-key bootstrap mechanism in .

• Editorial: fixed the GitHub URL in the abstract; settled on US "signaling" spelling; cleaned up the IANA registry table and unified the KeyState mnemonics (added a "Set by" column).

draft-berra-dnsop-opt-keystate-02

• Removed policy inquiry KeyState code 3 (INQUIRY_POLICY) and policy response codes 11 (POLICY_MANUAL_BOOTSTRAP_REQUIRED) and 12 (POLICY_AUTO_BOOTSTRAP). Bootstrap policy discovery is now handled entirely via the SVCB "bootstrap" SvcParamKey mechanism described in .

• Fixed wire format diagram: KEY-ID is 16 bits (a standard DNSSEC Key Tag), corrected byte offsets from 4/8/10 to 4/6/8.

• Replaced hardcoded section number references with kramdown anchors for stable cross-references.

draft-berra-dnsop-opt-keystate-01

• Fixed minor typos.

draft-berra-dnsop-opt-keystate-00

• Initial public draft.