Connection Identifiers for DTLS 1.2RTFM, Inc.ekr@rtfm.comArm Limitedhannes.tschofenig@arm.comArm Limitedthomas.fossati@arm.comBosch.IO GmbHachim.kraus@bosch.io
Security
TLSInternet-DraftThis document specifies the Connection ID (CID) construct for the Datagram Transport
Layer Security (DTLS) protocol version 1.2.A CID is an identifier carried in the record layer header that gives the
recipient additional information for selecting the appropriate security association.
In "classical" DTLS, selecting a security association of an incoming DTLS record
is accomplished with the help of the 5-tuple. If the source IP address and/or
source port changes during the lifetime of an ongoing DTLS session then the
receiver will be unable to locate the correct security context.IntroductionThe Datagram Transport Layer Security (DTLS) protocol was designed for
securing connection-less transports, like UDP. DTLS, like TLS, starts
with a handshake, which can be computationally demanding (particularly
when public key cryptography is used). After a successful handshake,
symmetric key cryptography is used to apply data origin
authentication, integrity and confidentiality protection. This
two-step approach allows endpoints to amortize the cost of the initial
handshake across subsequent application data protection. Ideally, the
second phase where application data is protected lasts over a long
period of time since the established keys will only need to be updated
once the key lifetime expires.In DTLS as specified in RFC 6347, the IP address and port of the peer are used to
identify the DTLS association. Unfortunately, in some cases, such as NAT rebinding,
these values are insufficient. This is a particular issue in the Internet of Things
when devices enter extended sleep periods to increase their battery lifetime. The
NAT 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 CID to the
DTLS record layer. The presence of the CID is negotiated via a DTLS
extension.Conventions and TerminologyThe 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 RFC 2119 .This document assumes familiarity with DTLS 1.2 .The "connection_id" ExtensionThis document defines the "connection_id" extension, which
is used in ClientHello and ServerHello messages.The extension type is specified as follows.The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure. This structure
contains the CID value the client wishes the server to use when sending
messages to the client. A zero-length CID value indicates that the client
is prepared to send with a CID but does not wish the server to use one when
sending.;
} ConnectionId;
]]>A server willing to use CIDs will respond with a "connection_id"
extension in the ServerHello, containing the CID it wishes the
client to use when sending messages towards it. A zero-length value
indicates that the server will send with the client's CID but does not
wish the client to include a CID (or again, alternately, to use a
zero-length CID).Because each party sends the value in the "connection_id" extension it wants to
receive as a CID in encrypted records, it is possible
for an endpoint to use a globally constant length for such connection
identifiers. This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time constant.
Such implementations MUST still be able to send
CIDs of different length to other parties.
Implementations that want to use variable-length CIDs are responsible
for constructing the CID in such a way that its length can be determined
on reception. Note that there is no CID
length information included in the record itself.In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS
session only. There is no dedicated "CID update" message
that allows new CIDs to be established mid-session, because
DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages
that do not themselves begin other handshakes. When a DTLS session is
resumed or renegotiated, the "connection_id" extension is negotiated afresh.If DTLS peers have not negotiated the use of CIDs then the RFC 6347-defined
record format and content type MUST be used.If DTLS peers have negotiated the use of a CIDs using the ClientHello and
the ServerHello messages then the peers need to take the following steps.The DTLS peers determine whether incoming and outgoing messages need
to use the new record format, i.e., the record format containing the CID.
The new record format with the the tls12_cid content type is only used once encryption
is enabled. Plaintext payloads never use the new record type and the CID content
type.For sending, if a zero-length CID has been negotiated then the RFC 6347-defined
record format and content type MUST be used (see Section 4.1 of )
else the new record layer format with the tls12_cid content type defined in MUST be used.When transmitting a datagram with the tls12_cid content type,
the new MAC computation defined in MUST be used.For receiving, if the tls12_cid content type is set, then the CID is used to look up
the connection and the security association. If the tls12_cid content type is not set,
then the connection and security association is looked up by the 5-tuple and a
check MUST be made to determine whether the expected CID value is indeed
zero length. If the check fails, then the datagram MUST be dropped.When receiving a datagram with the tls12_cid content type,
the new MAC computation defined in MUST be used. When receiving a datagram
with the RFC 6347-defined record format the MAC calculation defined in Section 4.1.2
of MUST be used.Record Layer ExtensionsThis specification defines the DTLS 1.2 record layer format and
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 which have negotiated this extension use a distinguished
record type tls12_cid(TBD2). Use of this content type has the following
three implications:
The CID field is present and contains one or more bytes.
The MAC calculation follows the process described in .
The true content type is inside the encryption envelope, as described
below.
Plaintext records are not impacted by this extension. Hence, the format
of the DTLSPlaintext structure is left unchanged, as shown in .When CIDs are being used, the content to be sent
is first wrapped along with its content type and optional padding into a
DTLSInnerPlaintext structure. This newly introduced structure is shown in
. The DTLSInnerPlaintext
byte sequence is then encrypted. To create the DTLSCiphertext structure shown in
the CID is added.
content
Corresponds to the fragment of a given length.
real_type
The content type describing the payload.
zeros
An arbitrary-length run of zero-valued bytes may appear in
the cleartext after the type field. This provides an opportunity
for senders to pad any DTLS record by a chosen amount as long as
the total stays within record size limits. See Section 5.4 of
for more details. (Note that the term TLSInnerPlaintext in
RFC 8446 refers to DTLSInnerPlaintext in this specification.)
outer_type
The outer content type of a DTLSCiphertext record carrying a CID
is always set to tls12_cid(TBD2). The real content
type of the record is found in DTLSInnerPlaintext.real_type after
decryption.
cid
The CID value, cid_length bytes long, as agreed at the time the extension
has been negotiated. Recall that (as discussed previously) each peer chooses
the CID value it will receive and use to identify the connection, so an
implementation can choose to always recieve CIDs of a fixed length. If,
however, an implementation chooses to receive different lengths of CID,
the assigned CID values must be self-delineating since there is no other
mechanism 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.Record Payload ProtectionSeveral types of ciphers have been defined for use with TLS and DTLS and the
MAC calculations for those ciphers differ slightly.This specification modifies the MAC calculation as defined in and
, as well as the definition of the additional data used with AEAD
ciphers provided in , for records with content type tls12_cid. The
modified algorithm MUST 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 as
defined in the cited documents.
cid
Value of the negotiated CID (variable length).
cid_length
1 byte field indicating the length of the negotiated CID.
length_of_DTLSInnerPlaintext
The length (in bytes) of the serialised DTLSInnerPlaintext (two-byte integer).
The length MUST NOT exceed 2^14.
seq_num_placeholder
8 bytes of 0xff
Note "+" denotes concatenation.Block CiphersThe following MAC algorithm applies to block ciphers
that do not use the with Encrypt-then-MAC processing
described in .The rationale behind this construction is to separate the MAC input
for DTLS without the connection ID from the MAC input with the
connection ID. The former always consists of a sequence number
followed by some other content type than tls12_cid; the latter
always consists of the seq_num_placeholder followed by tls12_cid.
Although 2^64-1 is potentially a valid sequence number, tls12_cid
will never be a valid content type when the connection ID is not in use.
In addition, the epoch and sequence_number are now fed into
the MAC in the same order as they appear on the wire.Block Ciphers with Encrypt-then-MAC processingThe following MAC algorithm applies to block ciphers
that use the with Encrypt-then-MAC processing
described in .AEAD CiphersFor ciphers utilizing authenticated encryption with additional
data the following modification is made to the additional data calculation.Peer Address UpdateWhen a record with a CID is received that has a source address
different than the one currently associated with the DTLS connection,
the receiver MUST NOT replace the address it uses for sending records
to 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 using
the DTLS record layer processing procedures.
The received datagram is "newer" (in terms of both epoch and sequence
number) than the newest datagram received. Reordered datagrams that are
sent prior to a change in a peer address might otherwise cause a valid
address change to be reverted. This also limits the ability of an attacker
to use replayed datagrams to force a spurious address change, which
could result in denial of service. An attacker might be able to succeed
in changing a peer address if they are able to rewrite source addresses
and if replayed packets are able to arrive before any original.
There is a strategy for ensuring that the new peer address is able to
receive and process DTLS records. No such strategy is defined in this specification.
The conditions above are necessary to protect against attacks that use datagrams with
spoofed addresses or replayed datagrams to trigger attacks. Note that there
is no requirement for use of the anti-replay window mechanism defined in
Section 4.1.2.6 of DTLS 1.2. Both solutions, the "anti-replay window" or
"newer" algorithm, will prevent address updates from replay attacks while the
latter will only apply to peer address updates and the former applies to any
application layer traffic.Note that datagrams that pass the DTLS cryptographic verification procedures
but do not trigger a change of peer address are still valid DTLS records and
are still to be passed to the application.Application protocols that implement protection against these attacks depend on
being aware of changes in peer addresses so that they can engage the necessary
mechanisms. When delivered such an event, an application layer-specific
address validation mechanism can be triggered, for example one that is based on
successful exchange of a minimal amount of ping-pong traffic with the peer.
Alternatively, an DTLS-specific mechanism may be used, as described in
.DTLS implementations MUST silently discard records with bad MACs or that are
otherwise invalid.Examples shows an example exchange where a CID is
used uni-directionally from the client to the server. To indicate that
a zero-length CID is present in the "connection_id" extension
we use the notation 'connection_id=empty'.Note: In the example exchange the CID is included in the record layer
once encryption is enabled. In DTLS 1.2 only one handshake message is
encrypted, namely the Finished message. Since the example shows how to
use the CID for payloads sent from the client to the server, only the
record layer payloads containing the Finished message or application data
include a CID.Privacy ConsiderationsThe CID replaces the previously used 5-tuple and, as such, introduces
an identifier that remains persistent during the lifetime of a DTLS connection.
Every identifier introduces the risk of linkability, as explained in .An on-path adversary observing the DTLS protocol exchanges between the
DTLS client and the DTLS server is able to link the observed payloads to all
subsequent payloads carrying the same ID pair (for bi-directional
communication). Without multi-homing or mobility, the use of the CID
exposes the same information as the 5-tuple.With multi-homing, a passive attacker is able to correlate the communication
interaction over the two paths. The lack of a CID update mechanism
in DTLS 1.2 makes this extension unsuitable for mobility scenarios where
correlation must be considered. Deployments that use DTLS in multi-homing
environments and are concerned about this aspects SHOULD refuse to use CIDs in
DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and
sequence number encryption is available.The 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 to inflate the size of the ciphertext making traffic analysis
more difficult. More details about record padding can be found in Section 5.4
and Appendix E.3 of RFC 8446.Finally, endpoints can use the CID to attach arbitrary per-connection metadata
to each record they receive on a given connection. This may be used as a mechanism to communicate
per-connection information to on-path observers. There is no straightforward way to
address this concern with CIDs that contain arbitrary values. Implementations
concerned about this aspect SHOULD refuse to use CIDs.Security ConsiderationsAn on-path adversary can create reflection attacks
against third parties because a DTLS peer has no means to distinguish a
genuine address update event (for example, due to a NAT rebinding) from one
that is malicious. This attack is of particular concern when the request is small
and the response large. See for more
on address updates.Additionally, an attacker able to observe the data traffic exchanged between
two DTLS peers is able to replay datagrams with modified IP address/port numbers.The topic of peer address updates is discussed in .IANA ConsiderationsIANA is requested to allocate an entry to the existing TLS "ExtensionType
Values" registry, defined in , for connection_id(TBD1) as described
in the table below. IANA is requested to add an extra column to the
TLS ExtensionType Values registry to indicate whether an extension is only
applicable to DTLS and to include this document as an additional reference
for the registry.Note: The value "N" in the Recommended column is set because this
extension is intended only for specific use cases. This document describes
the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and
its usage for DTLS 1.3 is described in .IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType
Registry". The tls12_cid ContentType is only applicable to DTLS 1.2.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Datagram Transport Layer Security Version 1.2This 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 Transport Layer Security (TLS) Protocol Version 1.3This 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.Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.Informative ReferencesPrivacy Considerations for Internet ProtocolsThis document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.The Datagram Transport Layer Security (DTLS) Protocol Version 1.3This 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 intentionally 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.Return Routability Check for DTLS 1.2 and DTLS 1.3This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.HistoryRFC EDITOR: PLEASE REMOVE THE THIS SECTIONdraft-ietf-tls-dtls-connection-id-10
Clarify privacy impact.
Have security considerations point to .
draft-ietf-tls-dtls-connection-id-09
Changed MAC/additional data calculation.
Disallow sending MAC failure fatal alerts to non-validated peers.
Incorporated editorial review comments by Ben Kaduk.
draft-ietf-tls-dtls-connection-id-08
RRC draft moved from normative to informative.
draft-ietf-tls-dtls-connection-id-07
Wording changes in the security and privacy
consideration and the peer address update
sections.
draft-ietf-tls-dtls-connection-id-06
Updated IANA considerations
Enhanced security consideration section to describe a potential
man-in-the-middle attack concerning address validation.
draft-ietf-tls-dtls-connection-id-05
Restructed Section 5 "Record Payload Protection"
draft-ietf-tls-dtls-connection-id-04
Editorial simplifications to the 'Record Layer Extensions' and the 'Record Payload Protection' sections.
Added MAC calculations for block ciphers with and without Encrypt-then-MAC processing.
draft-ietf-tls-dtls-connection-id-03
Updated list of contributors
Updated list of contributors and acknowledgements
Updated example
Changed record layer design
Changed record payload protection
Updated introduction and security consideration section
Author- and affiliation changes
draft-ietf-tls-dtls-connection-id-02
Move to internal content types a la DTLS 1.3.
draft-ietf-tls-dtls-connection-id-01
Remove 1.3 based on the WG consensus at IETF 101
draft-ietf-tls-dtls-connection-id-00
Initial working group version
(containing a solution for DTLS 1.2 and 1.3)
draft-rescorla-tls-dtls-connection-id-00
Initial version
Working Group InformationRFC EDITOR: PLEASE REMOVE THE THIS SECTIONThe discussion list for the IETF TLS working group is located at the e-mail
address tls@ietf.org. Information on the group and information on how to
subscribe to the list is at https://www1.ietf.org/mailman/listinfo/tlsArchives of the list can be found at:
https://www.ietf.org/mail-archive/web/tls/current/index.htmlContributorsMany people have contributed to this specification and we would like to thank
the 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 session
ids using hash chains and public key encryption, but dismissed them due to their
inefficiency. The approach described in this specification is the
simplest possible design that works given the limitations of DTLS 1.2. DTLS 1.3 provides
better privacy features and developers are encouraged to switch to the new version of DTLS.Finally, we want to thank the IETF TLS working group chairs, Chris Wood, Joseph Salowey, and
Sean Turner, for their patience, support and feedback.