]> TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany martine.lenders@tu-dresden.de

christian@amsuess.com

HAW Hamburg

t.schmidt@haw-hamburg.de

TUD Dresden University of Technology & Barkhausen Institut

Helmholtzstr. 10 Dresden D-01069 Germany m.waehlisch@tu-dresden.de

Web and Internet Transport Constrained RESTful Environments CoRE CoAP DoC DNR SVCB This document specifies solutions to discover DNS resolvers that support encrypted DNS resolution in constrained environments. The discovery is based DNS SVCB records, Router Advertisements, or DHCP. In particular, the proposed specification allows a host to learn DNS over CoAP (DoC) servers, including configurations to use DoC over TLS/DTLS, OSCORE, and EDHOC when resolving names. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction , and specify options to discover DNS resolvers that allow for encrypted DNS resolution, using either DNS or, in a local network, Router Advertisements or DHCP. These specifications use Service Binding (SVCB) resource records or Service Parameters (SvcParams) to carry information required for configuration of such resolvers. So far, however, only DNS transfer protocols based on Transport Layer Security (TLS) are supported, namely DNS over TLS (DoT) , DNS over HTTPS (DoH) , and DNS over Dedicated QUIC (DoQ) . This document discusses and specifies options to discover DNS resolvers in constrained environments, mainly based on DNS over CoAP (DoC) . DoC provides a solution for encrypted DNS in constrained environments. In such scenarios, the usage of DoT, DoH, DoQ, or similar TLS-based solutions is often not possible. The Constrained Application Protocol (CoAP) , the transfer protocol for DoC, is mostly agnostic to the transport layer, i.e., CoAP can be transported over UDP, TCP, or WebSockets , and even less common transports such as Bluetooth GATT or SMS are discussed. CoAP offers three security modes, which would need to be covered by the SvcParams:

• No Security: This plain CoAP mode does not support any encryption. It is not recommended when using but inherits core CoAP features such as block-wise transfer for datagram-based segmentation. Such features are beneficial in constrained settings even without encryption.
• Transport Security: CoAP may use DTLS when transferred over UDP and TLS when transferred over TCP .
• Object Security: Securing content objects can be achieved using OSCORE . OSCORE can be used either as an alternative or in addition to transport security. OSCORE keys have a limited lifetime and need to be set up, for example through an EDHOC key exchange , which may use credentials from trusted ACE Authorization Server (AS) as described in the ACE EDHOC profile . As an alternative to EDHOC, keys can be set up by such an AS as described in the ACE OSCORE profile .

To discover a DoC server via Discovery of Designated Resolvers (DDR) and Discovery of Network-designated Resolvers (DNR) , the SvcParams field needs to convey both transfer protocol and type and parameters of the security parameters. We will specify extensions of SvcParams in this document.

Terminology The terms “DoC server” and “DoC client” are used as defined in . The terms “constrained node” and "constrained network" are used as defined in . SvcParams denotes the field in either DNS SVCB/HTTPS records as defined in , or DHCP and RA messages as defined in . SvcParamKeys are used as defined in . 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.

Problem Space The first and most important question to ask for the discoverability of DoC resolvers is if and what new SvcParamKeys need to be defined. defines the “alpn” key, which is used to identify the protocol suite of a service binding using its Application-Layer Protocol Negotiation (ALPN) ID . While this is useful to identify classic transport layer security, the question is raised if this is needed or even helpful for when there is only object security. There is an ALPN ID for CoAP over TLS that was defined in . As using the same ALPN ID for different transport layers is not recommended, an ALPN for CoAP over UDP is being requested in . Object security may be selected in addition to transport layer security, so defining an ALPN ID for each combination might not be viable or scalable. For some ways of setting up object security, additional information is needed for the establishment of an encryption context and for authentication with an authentication server (AS). Orthogonally to the security mechanism, the transfer protocol needs to be established. Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options defined in might be with EDHOC or ACE EDHOC. While most fields map, “authentication-domain-name” (ADN) and its corresponding ADN length field may not matter in ACE driven cases. Out of scope of this document are related issues adjacent to its problem space. they are listed both for conceptual delimitation, and to aid in discussion of more comprehensive solutions:

• There is ongoing work in addressing the trouble created by CoAP using a diverse set of URI schemes in the shape of coap+..., such as coap+tcp . The creation of URI authority values that express the content of SVCB records together with IP literals is part of the solution space that will be explored there.
• Route Advertisements (RAs) as used in can easily exceed the link layer fragmentation threshold of constrained networks. The presence of DNR information in an RA can contribute to that issue.

Solution Sketches To answer the raised questions, we first look at the general case then 4 base scenarios, from which other scenarios might be a combination of:

• Unencrypted DoC,
• DoC over TLS/DTLS,
• DoC over OSCORE using EDHOC, and
• DoC over OSCORE using ACE-EDHOC.

In the general case, we mostly need to answer the question for additional SvcParamKeys. defines the keys “mandatory”, “alpn”, “no-default-alpn”, “port”, “ipv4hint”, and “ipv6hint” were defined. Additionally, defines “dohpath” which carries the URI template for the DNS resource at the DoH server in relative form. For DoC, the DNS resource needs to be identified as, so a corresponding “docpath” key should be provided that provides either a relative URI or CRI . Since the URI-Path option in CoAP may be omitted (defaulting to the root path), this could also be done for the “docpath”.

Unencrypted DoC While unencrypted DoC is not recommended by and might not even be viable using DDR/DNR, it provides additional benefits not provided by classic unencrypted DNS over UDP, such as segmentation block-wise transfer . However, it provides the simplest DoC configuration and thus is here discussed. At minimum for a DoC server a way to identify the following keys are required. “docpath” (see above), an optional “port” (see ), the IP address (either with an optional “ipv6hint”/“ipv4hint” or the respective IP address field in ), and a yet to be defined SvcParamKey for the CoAP transfer protocol, e.g., “coaptransfer”. The latter can be used to identify the service binding as a CoAP service binding. The “authenticator-domain-name” field should remain empty as it does not serve a purpose without encryption. See this example for the possible values of a DNR option: svc-params: - coaptransfer="tcp" - docpath="/dns" - port=61616 ]]>

DoC over TLS/DTLS In addition to the SvcParamKeys proposed in , this scenario needs the “alpn” key. While there is a “coap” ALPN ID defined, it only identifies CoAP over TLS . As such, a new ALPN ID for CoAP over DTLS is required. See this example for the possible values of a DNR option: svc-params: - alpn="co" - docpath="/dns" ]]> Note that “coaptransfer” is not needed, as it is implied by the ALPN ID; thus, no values for it would be allocated for transfer protocols that use transport security.

DoC over OSCORE using EDHOC While the “alpn” SvcParamKey is needed for the transport layer security (see ), we can implement a CA-style authentication with EDHOC when using object security with OSCORE using the authenticator-domain-name field. A new key SvcParamKey “objectsecurity” identifies the type of object security, using the value "edhoc" in this scenario. See this example for the possible values of a DNR option: svc-params: - coaptransfer="udp", - objectsecurity="edhoc", - docpath="/dns", - port=61616 ]]> The use of objectsecurity="edhoc" with an authenticator-domain-name and no further ACE details indicates that the client can use CA based authentication of the server.

DoC over ACE-OSCORE Using ACE, we require an OAuth context to authenticate the server in addition to the “objectsecurity” key. We propose three keys “oauth-aud” for the audience, “oauth-scope” for the OAuth scope, and “auth-as” for the authentication server. “oauth-aud” should be the valid domain name of the DoC server, “oauth-scope” a list of identifiers for the scope, and “oauth-as” a valid URI or CRI. TBD: should oauth-scope be expressed at all? Since authentication is done over OAuth and not CA-style, the “authenticator-domain-name” is not needed. There might be merit, however, to use it instead of the “oauth-aud” SvcParamKey. See this example for the possible values of a DNR option: svc-params: - coaptransfer="tcp" - objectsecurity="edhoc" /* TBD: or ace-edhoc? */ - docpath="/dns", - port=61616, - oauth-aud="dns.example.com", - oauth-scope="resolve DNS" - oauth-as="coap://as.example.com" ]]>

Security Considerations TODO Security

IANA Considerations

TLS ALPN for CoAP The following entry is being requested for addition into the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry, which is part of the "Transport Layer Security (TLS) Extensions" group.

• Protocol: CoAP (over DTLS)
• Identification sequence: 0x63 0x6f ("co")
• Reference: and [this document]

Note that does not prescribe the use of the ALPN TLS extension during connection the DTLS handshake. This document does not change that, and thus does not establish any rules like those in .

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. The SVCB DNS resource 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 encrypted transport protocols. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. TUD Dresden University of Technology Huawei Technologies HAW Hamburg TUD Dresden University of Technology & Barkhausen Institut This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). Ericsson RISE AB RISE AB Fraunhofer AISEC Ericsson The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. 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. Informative References The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. 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. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. 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. 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 specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an OAuth 2.0 Client and Resource Server, and it binds an authentication credential of the Client to an OAuth 2.0 access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –14 of this draft picks up comments from the // shepherd review and adds sections on CoAP integration and on cri // application-oriented literals for the Extended Diagnostic // Notation. This revision still contains open issues and is // intended to serve as a snapshot while the processing of the // shepherd review is being completed. OMA SpecWorks The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] to express alternative transports available to a device, and to optimize exchanges using these.

Acknowledgments TODO acknowledge.