]> 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 ALPN This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for 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 Application-Layer Protocol Negotiation (ALPN) enable communicating parties to agree on an application-layer protocol during a Transport Layer Security (TLS) handshake using an ALPN ID. This ALPN ID can be discovered for services as part of Service Bindings (SVCB) via the DNS, using SVCB resource records with the "alpn" Service Parameter Keys. 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. This document specifies an ALPN ID for CoAP services that are secured by transport security using DTLS. An ALPN ID for CoAP service secured by TLS has already been specified in .

Application-Layer Protocol Negotiation (ALPN) IDs For CoAP over TLS an ALPN ID was defined as "coaps" 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 registered in . ALPN ID values have variable length. Here, a short value ("co") is allocated for CoAP over DTLS, as this can avoid fragmentation of Client Hello and Server Hello messages in constrained networks with link-layer fragmentation, such as 6LoWPAN . To discover CoAP services that secure their messages with TLS or DTLS, ALPN IDs "coaps" and "co" can be used respectively 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 ALPN (see ) and 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 the DTLS connection handshake. This document does not change this behavior, 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. 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). This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]

Change Log

Acknowledgments We like to thank Rich Salz for the expert review on the "co" ALPN ID allocation. We also like to thank Mohamed Boucadair and Ben Schwartz for their early review before WG adoption of this draft.