]> 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 states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) . As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. 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 The discovery of Internet services can be facilitated by the Domain Name System (DNS). To discover services of the constrained Internet of Things (IoT) using the DNS, two challenges must be solved. First, the discovery of a DNS resolver that supports DNS resolution based on secure, IoT-friendly protocols—otherwise the subsequent discovery of IoT-tailored services would be limited to resolution protocols conflicting with constrained resources. Second, the discovery of an IoT-friendly service beyond the DNS resolution. specifies the "SVCB" ("Service Binding") DNS resource record to lookup information needed to connect to a network service. Service Parameters (SvcParams) carry that information within the SVCB record. The discovery of DNS resolvers can be enabled by the DNS itself , or, in a local network, by Router Advertisements and DHCP . In all theses cases, the SvcParams is used, but supports only DNS transfer based on Transport Layer Security (TLS), namely DNS over TLS (DoT) , DNS over HTTPS (DoH) , and DNS over Dedicated QUIC (DoQ) . The use of DoT, DoH, or DoQ, however, is not recommended in IoT scenarios. DNS over CoAP provides a solution for encrypted DNS in constrained environments. The Constrained Application Protocol (CoAP) is mostly agnostic to the transport layer CoAP can be transported over UDP, TCP, or WebSockets , and even less common transports such as Bluetooth GATT or SMS are discussed. covers the selection of different CoAP transports using SVCB records. CoAP offers three security modes:

• 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. Keys can be established through an EDHOC key exchange , received from an ACE Authorization Server (AS, as described in the ACE OSCORE profile ), or through a combination of those (established with an EDHOC peer whose public key is confirmed by an AS, using the ACE EDHOC profile ).

The SVCB-based discovery of a CoAP service in mode "no security" is covered in , and a CoAP service in the mode "transport security" in . The discovery of CoAP services in mode "object security" is not specified. To guide future specifications, this document clarifies aspects when using SVCB in the context of CoAP and object security.

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 point of discussion for the discoverability of CoAP is if and what new SvcParamKeys need to be defined and what is already there. 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 is defined in . As using the same ALPN ID for different transport layers is not recommended, another ALPN ID for CoAP over DTLS is introduced in . Object security may be selected in addition to transport layer security or without it. Additionally, different CoAP transports can be selected, which may be orthogonal to the transport security. For instance, DTLS can be used over transports other than UDP. The selection of CoAP transport protocols will be covered in future versions of . Defining an ALPN ID for each combination of object security, mode of transport layer security, and transport protocol might not be viable or scalable. For some ways of setting up object security, additional information is needed, such as an establishment options for an encryption context with EDHOC or an authentication server (AS) with ACE. 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 when authentication is driven by Authorization for Constrained Environments (ACE) .

Objectives SVCB records are not meant and should not be used to exchange security contexts, so this eliminates scenarios that use pre-shared keys with OSCORE. This leaves 2 base scenarios for OSCORE, which may occur in combination, with scenarios using transport security, or alternative transport protocols:

• DoC over OSCORE using EDHOC, and
• DoC using any ACE profile that eventually produces an OSCORE context.

We mostly need to answer the question for additional SvcParamKeys. defines the keys "mandatory", "alpn", "no-default-alpn", "port", "ipv4hint", and "ipv6hint". Additionally, defines "docpath" which carries the path for the DNS resource at the DoC server as a CBOR sequence. Since "alpn" is needed for transport layer security, the type of object security (OSCORE using EDHOC, OSCORE using ACE, OSCORE using EDHOC using ACE), needs to be conveyed in a different SvcParamKey. The semantics and necessacity of the authenticator-domain-name field in needs to be evaluated in each case. When using ACE, more SvcParamKeys might be needed, such as the OAuth audience, the scope or the authentication server URI. Defining these SvcParamKeys, including their value formats and spaces, as well as the behavior definition for authenticator-domain-name field, shall be part of future work.

Scenarios Two example scenarios illustrate possible ways for which a solution should work; they are phrased in dialogue form rather than in terms of protocol elements to avoid bias on solutions.

Neighbor discovered server with EDHOC credential In which the DoC server restricts access by network address (or not at all), and the client trusts its router to advertise a suitable Encrypted DNS server.

1. Client: Joins a network.
2. Local router: Sends out an IPv6 Router Advertisement (RA) with Encrypted DNS option (see ). Next to the network address, this conveys Service Parameters indicating DoC as well as a CWT Claims Set (CCS, ) that is to be used as an EDHOC credential.
3. Client starts EDHOC with the server at the indicated address. The client uses an ephemeral identity (i.e., authenticates with a CCS by value) and verifies that the DoC server is in possession of the key indicated in the CCS without explicit transmission of the CCS.

DHCP discovered server with ACE details In which both the DoC client and server have a preconfigured security association with an ACE server, and trust no one else.

1. Client: Requests an address using DHCP
2. DHCP server: Offers an address along with the DHCPv6 Encrypted DNS Option (see ). The option contains an address as well as an indication that ACE is used, along with sufficient data for the client to obtain an ACE token. This includes hints like the ACE Request Creation hints: the address of the AS and an identifier of the DoC server understood by the AS (the "aud"ience). The address of the AS should be provided in some resolved form, given that DNS is being bootstrapped.
3. Client requests token from AS: "I need a token for a host that is authorized to be my DNS server with me being authorized to use it; these hints were presented for me to obtain it."
4. AS verifies that the hint represents a recognized DNS server, that the client is authorized to use it, and issues a token for a suitable ACE profile (e.g. ACE OSCORE profile or ACE EDHOC profile).
5. Client establishes a security context with the DoC server as per the profile.

Security Considerations TODO Security

IANA Considerations This document has no IANA considerations.

References Normative References 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. 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 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. 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 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 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. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. 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 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 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. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. 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 ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth 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. TUD Dresden University of Technology NeuralAgent GmbH 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). TUD Dresden University of Technology 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] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. TUD Dresden University of Technology HAW Hamburg TUD Dresden University of Technology & Barkhausen Institut This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured CoAP services. OMA SpecWorks

Change Log

Since draft-lenders-core-dnr-03

• Update reference

Since draft-lenders-core-dnr-02

• Forward reference to upcoming changes in updated

Since draft-lenders-core-dnr-01

• Remove parts specified in
• Remove parts specified in
• Remove solution sketches, set objectives to solve problem space

Since draft-lenders-core-dnr-00

• IANA has processed the "co" ALPN and it is now added to the registry

Acknowledgments TODO acknowledge.