]> Arm Limited

Hannes.Tschofenig@gmx.net

Arm Limited

Thomas.Fossati@arm.com

ART CoRE Working Group CoAP, Option, Early Data, TLS 1.3 This document defines mechanisms that allow clients to communicate with servers about CoAP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction TLS and DTLS 1.3 provide a "zero round-trip time" (0-RTT) feature, the mechanics of which are described in . This feature provides a significant performance enhancement by enabling a client to send data to a server whom it has already spoken to in the first TLS handshake flight. However, TLS does not provide inherent replay protections for 0-RTT data, therefore the application running atop the TLS session has to take care of that. Specifically, establishes that:

• Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT.

This document defines the application profile for CoAP to allow clients and servers to exchange CoAP requests that are sent in early data. It also describes how to mitigate the risk of replay. The design is inspired by .

Requirements Language 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.

0-RTT Data For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. The server can choose whether it will process early data before the TLS handshake completes. It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests. This document specifies the Early-Data option, which indicates that the request has been conveyed in early data and that a client understands the 4.25 (Too Early) status code. The semantic follows . Early-Data Option

No.	C	U	N	R	Name	Format	Length	Default	E
TBD	x				Early-Data	empty	0	(none)	x

Note that 4.25 is just the suggested CoAP response code, which has not been registered yet.

Open Issues A list of open issues can be found at https://github.com/thomas-fossati/draft-coap-early-data/issues

Security Considerations Background:

IANA Considerations

New Option IANA is asked to add the Option defined in to the CoAP Option Numbers registry. Early-Data Option

Number	Name	Reference
TBD	Early-Data	RFCthis

New Response Code IANA is asked to add the Response Code defined in to the CoAP Response Code registry. Too Early Response Code

Code	Description	Reference
4.25	Too Early	RFCthis

Normative References 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 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. 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. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. 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.