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

WIT core CoRE CoAP SVCB DTLS ALPN This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for Constrained Application Protocol (CoAP) services that are secured by DTLS.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Application-Layer Protocol Negotiation (ALPN) IDs
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction Application-Layer Protocol Negotiation (ALPN) enables 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 (SVCBs) via the DNS, using SVCB resource records with the "alpn" Service Parameter Keys . As an example, applications that use the Constrained Application Protocol (CoAP) can obtain this information as part of the discovery of DNS over CoAP (DoC) servers (see ) that deploy TLS 1.3 as well as Datagram Transport Layer Security (DTLS) 1.2 or 1.3 to secure their messages. This document specifies an ALPN ID for CoAP services that are secured by DTLS. An ALPN ID for CoAP services secured by TLS has already been specified in .

Application-Layer Protocol Negotiation (ALPN) IDs For CoAP over TLS, an ALPN ID is defined as "coap" in . As it is not advisable to reuse the same ALPN ID for a different transport layer, an ALPN for CoAP over DTLS is registered in . ALPN ID values have variable length. For CoAP over DTLS, a short value ("co") is allocated, 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, the ALPN IDs "coap" and "co" can be used, respectively, in the same manner as for any other service secured with TLS, as described in . The discovery of CoAP services that rely on other security mechanisms is out of the scope of this document.

Security Considerations Any security considerations for ALPN (see ) and SVCB resource records (see ) also apply to this document.

IANA Considerations IANA has added the following entry to the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry in the "Transport Layer Security (TLS) Extensions" registry group. TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs Registry

Protocol	Identification Sequence	Reference
CoAP (over DTLS)	0x63 0x6f ("co")	, RFC 9952

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 This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] 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 version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. 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 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] 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 specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgments We would like to thank for the expert review on the "co" ALPN ID allocation. We would also like to thank and for their early reviews before WG adoption of this specification and , , and for their feedback and comments. This work was supported in parts by the German Federal Ministry of Research, Technology, and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the research project PIVOT and under the grant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge.

Authors' Addresses 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