draft-ietf-tls-dtls-connection-id-06.txt   draft-ietf-tls-dtls-connection-id-07.txt 
TLS E. Rescorla, Ed. TLS E. Rescorla, Ed.
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Updates: 6347 (if approved) H. Tschofenig, Ed. Updates: 6347 (if approved) H. Tschofenig, Ed.
Intended status: Standards Track T. Fossati Intended status: Standards Track T. Fossati
Expires: January 9, 2020 Arm Limited Expires: April 23, 2020 Arm Limited
July 08, 2019 October 21, 2019
Connection Identifiers for DTLS 1.2 Connection Identifiers for DTLS 1.2
draft-ietf-tls-dtls-connection-id-06 draft-ietf-tls-dtls-connection-id-07
Abstract Abstract
This document specifies the Connection ID (CID) construct for the This document specifies the Connection ID (CID) construct for the
Datagram Transport Layer Security (DTLS) protocol version 1.2. Datagram Transport Layer Security (DTLS) protocol version 1.2.
A CID is an identifier carried in the record layer header that gives A CID is an identifier carried in the record layer header that gives
the recipient additional information for selecting the appropriate the recipient additional information for selecting the appropriate
security association. In "classical" DTLS, selecting a security security association. In "classical" DTLS, selecting a security
association of an incoming DTLS record is accomplished with the help association of an incoming DTLS record is accomplished with the help
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on April 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. The "connection_id" Extension . . . . . . . . . . . . . . . . 3 3. The "connection_id" Extension . . . . . . . . . . . . . . . . 3
4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5 4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5
5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7 5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7
5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 7 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 8
5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 8
7. Security and Privacy Considerations . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix B. Working Group Information . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 14 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 14
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Working Group Information . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 15
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Datagram Transport Layer Security (DTLS) protocol was designed The Datagram Transport Layer Security (DTLS) protocol was designed
for securing connection-less transports, like UDP. DTLS, like TLS, for securing connection-less transports, like UDP. DTLS, like TLS,
starts with a handshake, which can be computationally demanding starts with a handshake, which can be computationally demanding
(particularly when public key cryptography is used). After a (particularly when public key cryptography is used). After a
successful handshake, symmetric key cryptography is used to apply successful handshake, symmetric key cryptography is used to apply
data origin authentication, integrity and confidentiality protection. data origin authentication, integrity and confidentiality protection.
This two-step approach allows endpoints to amortize the cost of the This two-step approach allows endpoints to amortize the cost of the
skipping to change at page 8, line 27 skipping to change at page 8, line 43
the following modification is made to the additional data the following modification is made to the additional data
calculation. calculation.
additional_data = seq_num + additional_data = seq_num +
tls12_cid + tls12_cid +
DTLSCipherText.version + DTLSCipherText.version +
cid + cid +
cid_length + cid_length +
length_of_DTLSInnerPlaintext; length_of_DTLSInnerPlaintext;
6. Examples 6. Peer Address Update
When 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 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 test is defined in
this specification.
The above is necessary to protect against attacks that use datagrams
with spoofed addresses or replayed datagrams to trigger attacks.
Note that there is no requirement to 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.
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
minimal amount of ping-pong traffic with the peer. Alternatively, an
DTLS-specific mechanism may be used, as described in
[I-D.tschofenig-tls-dtls-rrc].
7. Examples
Figure 4 shows an example exchange where a CID is used uni- Figure 4 shows an example exchange where a CID is used uni-
directionally from the client to the server. To indicate that a directionally from the client to the server. To indicate that a
zero-length CID we use the term 'connection_id=empty'. zero-length CID we use the term 'connection_id=empty'.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
(connection_id=empty) (connection_id=empty)
skipping to change at page 10, line 5 skipping to change at page 11, line 5
<...> indicates that a connection id is used in the record layer <...> indicates that a connection id is used in the record layer
(...) indicates an extension (...) indicates an extension
[...] indicates a payload other than a handshake message [...] indicates a payload other than a handshake message
Figure 4: Example DTLS 1.2 Exchange with CID Figure 4: Example DTLS 1.2 Exchange with CID
Note: In the example exchange the CID is included in the record layer 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 once encryption is enabled. In DTLS 1.2 only one handshake message
is encrypted, namely the Finished message. Since the example shows is encrypted, namely the Finished message. Since the example shows
how to use the CID for payloads sent from the client to the server how to use the CID for payloads sent from the client to the server
only the record layer payload containing the Finished messagen only the record layer payloads containing the Finished messages
contains a CID. Application data payloads sent from the client to include a CID. Application data payloads sent from the client to the
the server contain a CID in this example as well. server contain a CID in this example as well.
7. Security and Privacy Considerations 8. Privacy Considerations
The CID replaces the previously used 5-tuple and, as such, introduces The CID replaces the previously used 5-tuple and, as such, introduces
an identifier that remains persistent during the lifetime of a DTLS an identifier that remains persistent during the lifetime of a DTLS
connection. Every identifier introduces the risk of linkability, as connection. Every identifier introduces the risk of linkability, as
explained in [RFC6973]. explained in [RFC6973].
In addition, endpoints can use the CID to attach arbitrary metadata An on-path adversary observing the DTLS protocol exchanges between
to each record they receive. This may be used as a mechanism to the DTLS client and the DTLS server is able to link the observed
communicate per-connection information to on-path observers. There payloads to all subsequent payloads carrying the same ID pair (for
is no straightforward way to address this with CIDs that contain bi-directional communication). Without multi-homing or mobility, the
arbitrary values; implementations concerned about this SHOULD refuse use of the CID exposes the same information as the 5-tuple.
to use connection ids.
An on-path adversary, who is able to observe the DTLS protocol With multi-homing, a passive attacker is able to correlate the
exchanges between the DTLS client and the DTLS server, is able to communication interaction over the two paths and the sequence number
link the observed payloads to all subsequent payloads carrying the makes it possible to correlate packets across CID changes. The lack
same connection id pair (for bi-directional communication). Without of a CID update mechanism in DTLS 1.2 makes this extension unsuitable
multi-homing or mobility, the use of the CID is not different to the for mobility scenarios where correlation must be considered.
use of the 5-tuple. 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.
An on-path adversary can also black-hole traffic or create a The specification introduces record padding for the CID-enhanced
reflection attack against third parties because a DTLS peer has no record layer, which is a privacy feature not available with the
means to distinguish a genuine address update event (for example, due original DTLS 1.2 specification. Padding allows to inflate the size
to a NAT rebinding) from one that is malicious. This attack is of of the ciphertext making traffic analysis more difficult. More
concern when there is a large asymmetry of request/response message details about record padding can be found in Section 5.4 and
sizes. Appendix E.3 of RFC 8446.
With multi-homing, an adversary is able to correlate the Finally, endpoints can use the CID to attach arbitrary metadata to
communication interaction over the two paths, which adds further each record they receive. This may be used as a mechanism to
privacy concerns. The lack of a CID update mechanism makes this communicate per-connection information to on-path observers. There
extension unsuitable for mobility scenarios where correlation must be is no straightforward way to address this concern with CIDs that
considered. contain arbitrary values. Implementations concerned about this
aspects SHOULD refuse to use CIDs.
Importantly, the sequence number makes it possible for a passive 9. Security Considerations
attacker to correlate packets across CID changes. Thus, even if a
client/server pair do a rehandshake to change CID, that does not
provide much privacy benefit.
The CID-enhanced record layer introduces record padding; a privacy An on-path adversary can create reflection attacks against third
feature not available with the original DTLS 1.2 RFC. Padding allows parties because a DTLS peer has no means to distinguish a genuine
to inflate the size of the ciphertext making traffic analysis more address update event (for example, due to a NAT rebinding) from one
difficult. More details about the padding can be found in that is malicious. This attack is of concern when there is a large
Section 5.4 and Appendix E.3 of RFC 8446. asymmetry of request/response message sizes.
8. IANA Considerations 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 Section 6.
10. IANA Considerations
IANA is requested to allocate an entry to the existing TLS IANA is requested to allocate an entry to the existing TLS
"ExtensionType Values" registry, defined in [RFC5246], for "ExtensionType Values" registry, defined in [RFC5246], for
connection_id(TBD1) as described in the table below. IANA is connection_id(TBD1) as described in the table below. IANA is
requested to add an extra column to the TLS ExtensionType Values requested to add an extra column to the TLS ExtensionType Values
registry to indicate whether an extension is only applicable to DTLS. registry to indicate whether an extension is only applicable to DTLS.
Value Extension Name TLS 1.3 DTLS Only Recommended Reference Value Extension Name TLS 1.3 DTLS Only Recommended Reference
-------------------------------------------------------------------- --------------------------------------------------------------------
TBD1 connection_id - Y N [[This doc]] TBD1 connection_id - Y N [[This doc]]
Note: The value "N" in the Recommended column is set because this Note: The value "N" in the Recommended column is set because this
extension is intended only for specific use cases. This document extension is intended only for specific use cases. This document
describes an extension for DTLS 1.2 only; it is not to TLS (1.3). describes an extension for DTLS 1.2 only; it is not to TLS (1.3).
The DTLS 1.3 functionality is described in [I-D.ietf-tls-dtls13]. The DTLS 1.3 functionality is described in [I-D.ietf-tls-dtls13].
IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType
Registry". The tls12_cid ContentType is only applicable to DTLS 1.2. Registry". The tls12_cid ContentType is only applicable to DTLS 1.2.
9. References 11. References
9.1. Normative References 11.1. Normative References
[I-D.tschofenig-tls-dtls-rrc]
Fossati, T. and H. Tschofenig, "Return Routability Check
for DTLS 1.2 and DTLS 1.3", draft-tschofenig-tls-dtls-
rrc-00 (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 12, line 9 skipping to change at page 13, line 18
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014,
<https://www.rfc-editor.org/info/rfc7366>. <https://www.rfc-editor.org/info/rfc7366>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 11.2. Informative References
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1.3", draft-ietf-tls-dtls13-33 (work in progress), October
2019. 2019.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
9.3. URIs 11.3. URIs
[1] mailto:tls@ietf.org [1] mailto:tls@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/tls [2] https://www1.ietf.org/mailman/listinfo/tls
[3] https://www.ietf.org/mail-archive/web/tls/current/index.html [3] https://www.ietf.org/mail-archive/web/tls/current/index.html
Appendix A. History Appendix A. History
RFC EDITOR: PLEASE REMOVE THE THIS SECTION RFC EDITOR: PLEASE REMOVE THE THIS SECTION
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 draft-ietf-tls-dtls-connection-id-06
- Updated IANA considerations - Updated IANA considerations
- Enhanced security consideration section to describe a potential - Enhanced security consideration section to describe a potential
man-in-the-middle attack concerning address validation. man-in-the-middle attack concerning address validation.
draft-ietf-tls-dtls-connection-id-05 draft-ietf-tls-dtls-connection-id-05
- Restructed Section 5 "Record Payload Protection" - Restructed Section 5 "Record Payload Protection"
skipping to change at page 13, line 48 skipping to change at page 15, line 5
- Changed record payload protection - Changed record payload protection
- Updated introduction and security consideration section - Updated introduction and security consideration section
- Author- and affiliation changes - Author- and affiliation changes
draft-ietf-tls-dtls-connection-id-02 draft-ietf-tls-dtls-connection-id-02
- Move to internal content types a la DTLS 1.3. - 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 - Remove 1.3 based on the WG consensus at IETF 101
draft-ietf-tls-dtls-connection-id-00 draft-ietf-tls-dtls-connection-id-00
- Initial working group version (containing a solution for DTLS 1.2 - Initial working group version (containing a solution for DTLS 1.2
and 1.3) and 1.3)
draft-rescorla-tls-dtls-connection-id-00 draft-rescorla-tls-dtls-connection-id-00
- Initial version - Initial version
Appendix B. Working Group Information Appendix B. Working Group Information
RFC EDITOR: PLEASE REMOVE THE THIS SECTION RFC EDITOR: PLEASE REMOVE THE THIS SECTION
 End of changes. 24 change blocks. 
62 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/