Status of This Memo

This is an Internet Standards Track document.¶

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). Further information on Internet Standards is available in 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 athttps://www.rfc-editor.org/info/rfc9146.¶

Copyright Notice

Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) 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.¶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶

Table of Contents

1.Introduction

The Datagram Transport Layer Security (DTLS) protocol[RFC6347] was designed forsecuring data sent over datagram transports (e.g., UDP). DTLS, like TLS, startswith a handshake, which can be computationally demanding (particularlywhen public key cryptography is used). After a successful handshake,symmetric key cryptography is used to apply data originauthentication, integrity, and confidentiality protection. Thistwo-step approach allows endpoints to amortize the cost of the initialhandshake across subsequent application data protection. Ideally, thesecond phase where application data is protected lasts over a longperiod of time, since the established keys will only need to be updatedonce the key lifetime expires.¶

In DTLS as specified in RFC 6347, the IP address and port of the peer are used toidentify the DTLS association. Unfortunately, in some cases, such as NAT rebinding,these values are insufficient. This is a particular issue in the Internet of Thingswhen devices enter extended sleep periods to increase their battery lifetime. TheNAT rebinding leads to connection failure, with the resulting cost of a new handshake.¶

This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to theDTLS record layer. The presence of the CID is negotiated via a DTLSextension.¶

Adding a CID to the ciphertext record format presents an opportunity to makeother changes to the record format. In keeping with the best practicesestablished by TLS 1.3, the type of the record is encrypted, anda mechanism is provided for adding padding to obfuscate the plaintext length.¶

2.Conventions and Terminology

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[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document assumes familiarity with DTLS 1.2[RFC6347]. The presentation languageused in this document is described inSection 3 of [RFC8446].¶

3.The "connection_id" Extension

This document defines the "connection_id" extension, whichis used in ClientHello and ServerHello messages.¶

The extension type is specified as follows.¶

  enum {     connection_id(54), (65535)  } ExtensionType;

The extension_data field of this extension, when included in theClientHello,MUST contain the ConnectionId structure. This structurecontains the CID value the client wishes the server to use when sendingmessages to the client. A zero-length CID value indicates that the clientis prepared to send using a CID but does not wish the server to use one whensending.¶

  struct {      opaque cid<0..2^8-1>;  } ConnectionId;

A server willing to use CIDs will respond with a "connection_id"extension in the ServerHello, containing the CID it wishes theclient to use when sending messages towards it. A zero-length valueindicates that the server will send using the client's CID but does notwish the client to include a CID when sending.¶

Because each party sends the value in the "connection_id" extension it wants toreceive as a CID in encrypted records, it is possiblefor an endpoint to use a deployment-specific constant length for such connectionidentifiers. This can in turn ease parsing and connection lookup --for example, by having the length in question be a compile-time constant.Such implementationsMUST still be able to sendCIDs of different lengths to other parties.Since the CID length information is not included in the record itself,implementations that want to use variable-length CIDs are responsiblefor constructing the CID in such a way that its length can be determinedon reception.¶

In DTLS 1.2, CIDs are exchanged at the beginning of the DTLSsession only. There is no dedicated "CID update" messagethat allows new CIDs to be established mid-session, becauseDTLS 1.2 in general does not allow TLS 1.3-style post-handshake messagesthat do not themselves begin other handshakes. When a DTLS session isresumed or renegotiated, the "connection_id" extension is negotiated afresh.¶

If DTLS peers have not negotiated the use of CIDs, or a zero-lengthCID has been advertised for a given direction, then the record format and content type defined in RFC 6347MUST be used to send inthe indicated direction(s).¶

If DTLS peers have negotiated the use of a non-zero-length CID for agiven direction, then once encryption is enabled, theyMUST send withthe record format defined inFigure 3 (seeSection 4) with thenew Message Authentication Code (MAC) computation defined inSection 5 and the content type tls12_cid.Plaintext payloads never use the new record format or the CID contenttype.¶

When receiving, if the tls12_cid content type is set, then the CID isused to look up the connection and the security association. If thetls12_cid content type is not set, then the connection and the securityassociation are looked up by the 5-tuple and a checkMUST be made todetermine whether a non-zero-length CID is expected.If a non-zero-length CID is expected for the retrieved association,then the datagramMUST be treated as invalid, as describedinSection 4.1.2.1 of [RFC6347].¶

When receiving a datagram with the tls12_cid content type,the new MAC computation defined inSection 5MUST be used. When receiving a datagramwith the record format defined in RFC 6347, the MAC calculation defined inSection 4.1.2 of [RFC6347]MUST be used.¶

4.Record Layer Extensions

This specification defines the CID-enhanced record layer format for DTLS 1.2, and[DTLS13] specifies how to carry the CID in DTLS 1.3.¶

To allow a receiver to determine whether a record has a CID or not,connections that have negotiated this extension use a distinguishedrecord type tls12_cid(25). The use of this content type has the followingthree implications:¶

• The CID field is present and contains one or more bytes.¶
• The MAC calculation follows the process described inSection 5.¶
• The real content type is inside the encryption envelope, as describedbelow.¶

Plaintext records are not impacted by this extension. Hence, the formatof the DTLSPlaintext structure is left unchanged, as shown inFigure 1.¶

     struct {         ContentType type;         ProtocolVersion version;         uint16 epoch;         uint48 sequence_number;         uint16 length;         opaque fragment[DTLSPlaintext.length];     } DTLSPlaintext;

When CIDs are being used, the content to be sentis first wrapped along with its content type and optional padding into aDTLSInnerPlaintext structure. This newly introduced structure is shown inFigure 2.¶

     struct {         opaque content[length];         ContentType real_type;         uint8 zeros[length_of_padding];     } DTLSInnerPlaintext;

content:

Corresponds to the fragment of a given length.¶

real_type:

The content type describing the cleartext payload.¶

zeros:

An arbitrary-length run of zero-valued bytes may appear inthe cleartext after the type field. This provides an opportunityfor senders to pad any DTLS record by a chosen amount as long asthe total stays within record size limits. SeeSection 5.4 of [RFC8446] for more details. (Note that the term TLSInnerPlaintext inRFC 8446 refers to DTLSInnerPlaintext in this specification.)¶

The DTLSInnerPlaintext byte sequence is then encrypted. To create theDTLSCiphertext structure shown inFigure 3, the CID is added.¶

     struct {         ContentType outer_type = tls12_cid;         ProtocolVersion version;         uint16 epoch;         uint48 sequence_number;         opaque cid[cid_length];               // New field         uint16 length;         opaque enc_content[DTLSCiphertext.length];     } DTLSCiphertext;

outer_type:

The outer content type of a DTLSCiphertext record carrying a CIDis always set to tls12_cid(25). The real contenttype of the record is found in DTLSInnerPlaintext.real_type afterdecryption.¶

cid:

The CID value, cid_length bytes long, as agreed at the time the extensionhas been negotiated. Recall that each peer choosesthe CID value it will receive and use to identify the connection, so animplementation can choose to always receive CIDs of a fixed length. If,however, an implementation chooses to receive CIDs of different lengths,the assigned CID values must be self-delineating, since there is no othermechanism available to determine what connection (and thus, what CID length)is in use.¶

enc_content:

The encrypted form of the serialized DTLSInnerPlaintext structure.¶

All other fields are as defined in RFC 6347.¶

5.Record Payload Protection

Several types of ciphers have been defined for use with TLS and DTLS, and theMAC calculations for those ciphers differ slightly.¶

This specification modifies the MAC calculation as defined in[RFC6347] and[RFC7366], as well as the definition of the additional data used with Authenticated Encryption with Associated Data (AEAD)ciphers provided in[RFC6347], for records with content type tls12_cid. Themodified algorithmMUST NOT be applied to records that do not carry a CID, i.e.,records with content type other than tls12_cid.¶

The following fields are defined in this document; all other fields are asdefined in the cited documents.¶

cid:

Value of the negotiated CID (variable length).¶

cid_length:

The length (in bytes) of the negotiated CID (one-byte integer).¶

length_of_DTLSInnerPlaintext:

The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer).The lengthMUST NOT exceed 2^14.¶

seq_num_placeholder:

8 bytes of 0xff.¶

Note that "+" denotes concatenation.¶

    MAC(MAC_write_key,        seq_num_placeholder +        tls12_cid +        cid_length +        tls12_cid +        DTLSCiphertext.version +        epoch +        sequence_number +        cid +        length_of_DTLSInnerPlaintext +        DTLSInnerPlaintext.content +        DTLSInnerPlaintext.real_type +        DTLSInnerPlaintext.zeros    );

    MAC(MAC_write_key,        seq_num_placeholder +        tls12_cid +        cid_length +        tls12_cid +        DTLSCiphertext.version +        epoch +        sequence_number +        cid +        DTLSCiphertext.length +        IV +        ENC(content + padding + padding_length)    );

    additional_data = seq_num_placeholder +                      tls12_cid +                      cid_length +                      tls12_cid +                      DTLSCiphertext.version +                      epoch +                      sequence_number +                      cid +                      length_of_DTLSInnerPlaintext;

6.Peer Address Update

When a record with a CID is received that has a source addressdifferent from the one currently associated with the DTLS connection,the receiverMUST NOT replace the address it uses for sending recordsto its peer with the source address specified in the received datagram,unless the following three conditions are met:¶

• The received datagram has been cryptographically verified usingthe DTLS record layer processing procedures.¶
• The received datagram is "newer" (in terms of both epoch and sequencenumber) than the newest datagram received. Reordered datagrams that aresent prior to a change in a peer address might otherwise cause a validaddress change to be reverted. This also limits the ability of an attackerto use replayed datagrams to force a spurious address change, whichcould result in denial of service. An attacker might be able to succeedin changing a peer address if they are able to rewrite source addressesand if replayed packets are able to arrive before any original.¶
• There is a strategy for ensuring that the new peer address is able toreceive and process DTLS records. No strategy is mandated by this specification,but see note (*) below.¶

The conditions above are necessary to protect against attacks that use datagrams withspoofed addresses or replayed datagrams to trigger attacks. Note that thereis no requirement for the use of the anti-replay window mechanism defined inSection 4.1.2.6 of [RFC6347]. Both solutions, the "anti-replay window" or"newer" algorithm, will prevent address updates from replay attacks while thelatter will only apply to peer address updates and the former applies to anyapplication layer traffic.¶

Note that datagrams that pass the DTLS cryptographic verification proceduresbut do not trigger a change of peer address are still valid DTLS records andare still to be passed to the application.¶

(*) Note: Application protocols that implement protection against spoofed addressesdepend on being aware of changes in peer addresses so that they can engage the necessarymechanisms. When delivered such an event, an address validation mechanism specific to the application layer can be triggered -- for example, one that is based onsuccessful exchange of a minimal amount of ping-pong traffic with the peer.Alternatively, a DTLS-specific mechanism may be used, as described in[DTLS-RRC].¶

DTLS implementationsMUST silently discard records with bad MACs or that areotherwise invalid.¶

7.Example

Figure 4 shows an example exchange where a CID isused unidirectionally from the client to the server. To indicate thata zero-length CID is present in the "connection_id" extension,we use the notation 'connection_id=empty'.¶

Client                                             Server------                                             ------ClientHello                 -------->(connection_id=empty)                            <--------      HelloVerifyRequest                                                     (cookie)ClientHello                 -------->(connection_id=empty)(cookie)                                                  ServerHello                                          (connection_id=100)                                                  Certificate                                            ServerKeyExchange                                           CertificateRequest                            <--------         ServerHelloDoneCertificateClientKeyExchangeCertificateVerify[ChangeCipherSpec]Finished                    --------><CID=100>                                           [ChangeCipherSpec]                            <--------                FinishedApplication Data            ========><CID=100>                            <========        Application DataLegend:<...> indicates that a connection ID is used in the record layer(...) indicates an extension[...] indicates a payload other than a handshake message

Note: In the example exchange, the CID is included in the record layeronce encryption is enabled. In DTLS 1.2, only one handshake message isencrypted, namely the Finished message. Since the example shows how touse the CID for payloads sent from the client to the server, only therecord layer payloads containing the Finished message or application datainclude a CID.¶

8.Privacy Considerations

The CID replaces the previously used 5-tuple and, as such, introducesan identifier that remains persistent during the lifetime of a DTLS connection.Every identifier introduces the risk of linkability, as explained in[RFC6973].¶

An on-path adversary observing the DTLS protocol exchanges between theDTLS client and the DTLS server is able to link the observed payloads to allsubsequent payloads carrying the same ID pair (for bidirectionalcommunication). Without multihoming or mobility, the use of the CIDexposes the same information as the 5-tuple.¶

With multihoming, a passive attacker is able to correlate the communicationinteraction over the two paths. The lack of a CID update mechanismin DTLS 1.2 makes this extension unsuitable for mobility scenarios wherecorrelation must be considered. Deployments that use DTLS in multihomingenvironments and are concerned about these aspectsSHOULD refuse to use CIDs inDTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided andsequence number encryption is available.¶

This specification introduces record padding for the CID-enhanced record layer,which is a privacy feature not available with the original DTLS 1.2 specification.Padding allows the size of the ciphertext to be inflated, making traffic analysismore difficult. More details about record padding can be found inSection 5.4 and Appendix E.3 of[RFC8446].¶

Finally, endpoints can use the CID to attach arbitrary per-connection metadatato each record they receive on a given connection. This may be used as a mechanism to communicateper-connection information to on-path observers. There is no straightforward way toaddress this concern with CIDs that contain arbitrary values. Implementationsconcerned about this aspectSHOULD refuse to use CIDs.¶

9.Security Considerations

An on-path adversary can create reflection attacksagainst third parties because a DTLS peer has no means to distinguish agenuine address update event (for example, due to a NAT rebinding) from onethat is malicious. This attack is of particular concern when the request is smalland the response large. SeeSection 6 for moreon address updates.¶

Additionally, an attacker able to observe the data traffic exchanged betweentwo DTLS peers is able to replay datagrams with modified IP addresses / port numbers.¶

The topic of peer address updates is discussed inSection 6.¶

10.IANA Considerations

This document implements three IANA updates.¶

Acknowledgements

We would like to thankHanno Becker,Martin Duke,Lars Eggert,Ben Kaduk,Warren Kumari,Francesca Palombini,Tom Petch,John Scudder,Sean Turner,Éric Vyncke, andRobert Wiltonfor their review comments.¶

Finally, we want to thank the IETF TLS Working Group chairs,Chris Wood,Joseph Salowey, andSean Turner, for their patience, support, and feedback.¶

Contributors

Many people have contributed to this specification, and we would like to thankthe following individuals for their contributions:¶

Additionally, we would like to thank the Connection ID task force team members:¶

• Martin Thomson (Mozilla)¶

• Christian Huitema (Private Octopus Inc.)¶

• Jana Iyengar (Google)¶

• Daniel Kahn Gillmor (ACLU)¶

• Patrick McManus (Mozilla)¶

• Ian Swett (Google)¶

• Mark Nottingham (Fastly)¶

The task force team discussed various design ideas, including cryptographically generated sessionIDs using hash chains and public key encryption, but dismissed them due to theirinefficiency. The approach described in this specification is thesimplest possible design that works, given the limitations of DTLS 1.2. DTLS 1.3 providesbetter privacy features, and developers are encouraged to switch to the new version of DTLS.¶

Authors' Addresses