]> TUD Dresden University of Technology

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

christian@amsuess.com

HAW Hamburg

Berliner Tor 7 Hamburg D-20099 Germany 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 SVCB DTLS This document specifies the usage of Service Parameters as used in SVCB ("Service Binding") DNS resource records for the discovery of transport-layer-secured CoAP services. 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 specifies the "SVCB" ("Service Binding") DNS resource records for looking up communication endpoints of a service. Service Parameters (SvcParams) are used to carry that information. This document specifies which information from SvcParams can be used with CoAP services that are secured by transport security, namely TLS and DTLS. As an example, this information can be obtained as part of the discovery of DNS over CoAP (DoC) servers (see ) that deploy TLS or DTLS to secure their messages.

Terminology SvcParams denotes the field in either DNS SVCB/HTTPS records as defined in , or DHCP and RA messages 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.

Application-Layer Protocol Negotiation (ALPN) IDs defines the "alpn" key, which is used to identify the service binding to a protocol suite using its Application-Layer Protocol Negotiation (ALPN) ID . For CoAP over TLS an ALPN ID was defined in . As it is not advisable to re-use the same ALPN ID for a different transport layer, an ALPN for CoAP over DTLS is also registered in . To discover CoAP services that secure their messages with TLS or DTLS, these ALPN IDs can be used in the same manner as for any other service secured with transport layer security, as described in . Other authentication mechanisms are currently out of scope.

Security Considerations Any security considerations on SVCB resource records (see ), also apply to this document.

IANA Considerations

TLS ALPN for CoAP The following entry has been added to 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 define 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 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. 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), 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. 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).

Change Log

Acknowledgments TODO acknowledge.