< draft-ietf-tls-dtls-connection-id-04.txt   draft-ietf-tls-dtls-connection-id-05.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: September 12, 2019 Arm Limited Expires: November 7, 2019 Arm Limited
March 11, 2019 May 06, 2019
Connection Identifiers for DTLS 1.2 Connection Identifiers for DTLS 1.2
draft-ietf-tls-dtls-connection-id-04 draft-ietf-tls-dtls-connection-id-05
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 September 12, 2019. This Internet-Draft will expire on November 7, 2019.
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 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 7
5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security and Privacy Considerations . . . . . . . . . . . . . 10 7. Security and Privacy Considerations . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Working Group Information . . . . . . . . . . . . . 13 Appendix B. Working Group Information . . . . . . . . . . . . . 14
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 14 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 14
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 3, line 38 skipping to change at page 3, line 41
This document assumes familiarity with DTLS 1.2 [RFC6347]. This document assumes familiarity with DTLS 1.2 [RFC6347].
3. The "connection_id" Extension 3. The "connection_id" Extension
This document defines the "connection_id" extension, which is used in This document defines the "connection_id" extension, which is used in
ClientHello and ServerHello messages. ClientHello and ServerHello messages.
The extension type is specified as follows. The extension type is specified as follows.
enum { enum {
connection_id(TBD), (65535) connection_id(TBD1), (65535)
} ExtensionType; } ExtensionType;
The extension_data field of this extension, when included in the The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure. This structure ClientHello, MUST contain the ConnectionId structure. This structure
contains the CID value the client wishes the server to use when contains the CID value the client wishes the server to use when
sending messages to the client. A zero-length CID value indicates 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 that the client is prepared to send with a CID but does not wish the
server to use one when sending. Alternatively, this can be server to use one when sending. Alternatively, this can be
interpreted as the client wishes the server to use a zero-length CID; interpreted as the client wishes the server to use a zero-length CID;
the result is the same. the result is the same.
skipping to change at page 4, line 51 skipping to change at page 4, line 51
The DTLS peers determine whether incoming and outgoing messages need The DTLS peers determine whether incoming and outgoing messages need
to use the new record format, i.e., the record format containing the 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 CID. The new record format with the the tls12_cid content type is
only used once encryption is enabled. Plaintext payloads never use only used once encryption is enabled. Plaintext payloads never use
the new record type and the CID content type. the new record type and the CID content type.
For sending, if a zero-length CID has been negotiated then the RFC For sending, if a zero-length CID has been negotiated then the RFC
6347-defined record format and content type MUST be used (see 6347-defined record format and content type MUST be used (see
Section 4.1 of [RFC6347]) else the new record layer format with the Section 4.1 of [RFC6347]) else the new record layer format with the
tls12_cid content type defined in Figure 1 MUST be used. tls12_cid content type defined in Figure 3 MUST be used.
When transmitting a datagram with the tls12_cid content type, the new When transmitting a datagram with the tls12_cid content type, the new
MAC computation defined in Section 5 MUST be used. MAC computation defined in Section 5 MUST be used.
For receiving, if the tls12_cid content type is set, then the CID is 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 used to look up the connection and the security association. If the
tls12_cid content type is not set, then the connection and security 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 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 determine whether the expected CID value is indeed zero length. If
the check fails, then the datagram MUST be dropped. the check fails, then the datagram MUST be dropped.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
datagram with the RFC 6347-defined record format the MAC calculation datagram with the RFC 6347-defined record format the MAC calculation
defined in Section 4.1.2 of [RFC6347] MUST be used. defined in Section 4.1.2 of [RFC6347] MUST be used.
4. Record Layer Extensions 4. Record Layer Extensions
This specification defines the DTLS 1.2 record layer format and This specification defines the DTLS 1.2 record layer format and
[I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. [I-D.ietf-tls-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, To allow a receiver to determine whether a record has a CID or not,
connections which have negotiated this extension use a distinguished connections which have negotiated this extension use a distinguished
record type tls12_cid(25). Use of this content type has the record type tls12_cid(TBD2). Use of this content type has the
following three implications: following three implications:
- The CID field is present and contains one or more bytes. - The CID field is present and contains one or more bytes.
- The MAC calculation follows the process described in Section 5. - The MAC calculation follows the process described in Section 5.
- The true content type is inside the encryption envelope, as - The true content type is inside the encryption envelope, as
described below. described below.
When CIDs are being used, the content to be sent is first wrapped Plaintext records are not impacted by this extension. Hence, the
along with its content type and optional padding into a format of the DTLSPlaintext structure is left unchanged, as shown in
DTLSInnerPlaintext: Figure 1.
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; uint16 epoch;
uint48 sequence_number; uint48 sequence_number;
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
Figure 1: DTLS 1.2 Plaintext Record Payload.
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 Figure 2. The DTLSInnerPlaintext byte sequence is then
encrypted. To create the DTLSCiphertext structure shown in Figure 3
the CID is added.
struct { struct {
opaque content[DTLSPlaintext.length]; opaque content[length];
ContentType real_type; ContentType real_type;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} DTLSInnerPlaintext; } DTLSInnerPlaintext;
content A copy of DTLSPlaintext.fragment Figure 2: New DTLSInnerPlaintext Payload Structure.
real_type A copy of DTLSPlaintext.type 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 zeros An arbitrary-length run of zero-valued bytes may appear in the
cleartext after the type field. This provides an opportunity for cleartext after the type field. This provides an opportunity for
senders to pad any DTLS record by a chosen amount as long as the 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 total stays within record size limits. See Section 5.4 of
[RFC8446] for more details. (Note that the term TLSInnerPlaintext [RFC8446] for more details. (Note that the term TLSInnerPlaintext
in RFC 8446 refers to DTLSInnerPlaintext in this specification.) in RFC 8446 refers to DTLSInnerPlaintext in this specification.)
The DTLSInnerPlaintext value is then encrypted and the CID added to
produce the final DTLSCiphertext.
struct { struct {
ContentType special_type = tls12_cid; /* 25 */ ContentType special_type = tls12_cid;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; uint16 epoch;
uint48 sequence_number; uint48 sequence_number;
opaque cid[cid_length]; // New field opaque cid[cid_length]; // New field
uint16 length; uint16 length;
opaque enc_content[DTLSCiphertext.length]; opaque enc_content[DTLSCiphertext.length];
} DTLSCiphertext; } DTLSCiphertext;
Figure 1: DTLSCiphertext with CID Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record.
special_type The outer content type of a DTLSCiphertext record special_type The outer content type of a DTLSCiphertext record
carrying a CID is always set to the value 25 (tls12_cid). The carrying a CID is always set to tls12_cid(TBD2). The real content
actual content type of the record is found in type of the record is found in DTLSInnerPlaintext.real_type after
DTLSInnerPlaintext.real_type after decryption. decryption.
cid The CID value, cid_length bytes long, as agreed at the time the cid The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated. extension has been negotiated.
enc_content The encrypted form of the serialized DTLSInnerPlaintext enc_content The encrypted form of the serialized DTLSInnerPlaintext
structure. structure.
All other fields are as defined in RFC 6347. All other fields are as defined in RFC 6347.
5. Record Payload Protection 5. Record Payload Protection
Several types of ciphers have been defined for use with TLS and DTLS
and the MAC calculation for those ciphers differs slightly.
This specification modifies the MAC calculation defined in [RFC6347] This specification modifies the MAC calculation defined in [RFC6347]
and [RFC7366] as well as the definition of the additional data used and [RFC7366] as well as the definition of the additional data used
with AEAD ciphers provided in [RFC6347] for records with content type with AEAD ciphers provided in [RFC6347] for records with content type
tls12_cid. The modified algorithm MUST NOT be applied to records 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 that do not carry a CID, i.e., records with content type other than
tls12_cid. tls12_cid.
- Block Ciphers: The following fields are defined in this document; all other fields
are as defined in the cited documents.
cid Value of the negotiated CID.
cid_length 1 byte field indicating the length of the negotiated CID.
length_of_DTLSInnerPlaintext The length (in bytes) of the serialised
DTLSInnerPlaintext.
The length MUST NOT exceed 2^14.
Note "+" denotes concatenation.
5.1. Block Ciphers
The following MAC algorithm applies to block ciphers that do not use
the with Encrypt-then-MAC processing described in [RFC7366].
MAC(MAC_write_key, seq_num + MAC(MAC_write_key, seq_num +
tls12_cid + // New input tls12_cid +
DTLSPlaintext.version + DTLSCiphertext.version +
cid + // New input cid +
cid_length + // New input cid_length +
length_of_DTLSInnerPlaintext + // New input length_of_DTLSInnerPlaintext +
DTLSInnerPlaintext.content + // New input DTLSInnerPlaintext.content +
DTLSInnerPlaintext.real_type + // New input DTLSInnerPlaintext.real_type +
DTLSInnerPlaintext.zeros // New input DTLSInnerPlaintext.zeros
) )
- Block Ciphers with Encrypt-then-MAC processing: 5.2. Block Ciphers with Encrypt-then-MAC processing
The following MAC algorithm applies to block ciphers that use the
with Encrypt-then-MAC processing described in [RFC7366].
MAC(MAC_write_key, seq_num + MAC(MAC_write_key, seq_num +
DTLSCipherText.type + tls12_cid +
DTLSCipherText.version + DTLSCipherText.version +
DTLSPlaintext.version + cid +
cid + // New input cid_length +
cid_length + // New input
length of (IV + DTLSCiphertext.enc_content) + length of (IV + DTLSCiphertext.enc_content) +
IV + IV +
DTLSCiphertext.enc_content); DTLSCiphertext.enc_content);
- AEAD Ciphers: 5.3. AEAD Ciphers
additional_data = seq_num + DTLSPlaintext.type +
DTLSPlaintext.version +
cid + // New input
cid_length + // New input
length_of_DTLSInnerPlaintext;
Where:
cid Value of the negotiated CID.
cid_length 1 byte field indicating the length of the negotiated CID.
All other fields are as defined in the cited documents. For ciphers utilizing authenticated encryption with additional data
the following modification is made to the additional data
calculation.
length_of_DTLSInnerPlaintext The length (in bytes) of the serialised additional_data = seq_num +
DTLSInnerPlaintext. The length MUST NOT exceed 2^14. tls12_cid +
DTLSCipherText.version +
cid +
cid_length +
length_of_DTLSInnerPlaintext;
6. Examples 6. Examples
Figure 2 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)
<-------- HelloVerifyRequest <-------- HelloVerifyRequest
skipping to change at page 9, line 46 skipping to change at page 9, line 46
<CID=100> <CID=100>
<======== Application Data <======== Application Data
Legend: Legend:
<...> 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 2: 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 payload containing the Finished messagen
contains a CID. Application data payloads sent from the client to contains a CID. Application data payloads sent from the client to
the server contain a CID in this example as well. the server contain a CID in this example as well.
7. Security and Privacy Considerations 7. Security and Privacy Considerations
skipping to change at page 10, line 32 skipping to change at page 10, line 32
An on-path adversary, who is able to observe the DTLS protocol An on-path adversary, who is able to observe the DTLS protocol
exchanges between the DTLS client and the DTLS server, is able to exchanges between the DTLS client and the DTLS server, is able to
link the observed payloads to all subsequent payloads carrying the link the observed payloads to all subsequent payloads carrying the
same connection id pair (for bi-directional communication). Without same connection id pair (for bi-directional communication). Without
multi-homing or mobility, the use of the CID is not different to the multi-homing or mobility, the use of the CID is not different to the
use of the 5-tuple. use of the 5-tuple.
With multi-homing, an adversary is able to correlate the With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further communication interaction over the two paths, which adds further
privacy concerns. privacy concerns. The lack of a CID update mechanism makes this
extension unsuitable for mobility scenarios where correlation must be
considered.
Importantly, the sequence number makes it possible for a passive Importantly, the sequence number makes it possible for a passive
attacker to correlate packets across CID changes. Thus, even if a attacker to correlate packets across CID changes. Thus, even if a
client/server pair do a rehandshake to change CID, that does not client/server pair do a rehandshake to change CID, that does not
provide much privacy benefit. provide much privacy benefit.
The CID-enhanced record layer introduces record padding; a privacy The CID-enhanced record layer introduces record padding; a privacy
feature not available with the original DTLS 1.2 RFC. Padding allows feature not available with the original DTLS 1.2 RFC. Padding allows
to inflate the size of the ciphertext making traffic analysis more to inflate the size of the ciphertext making traffic analysis more
difficult. More details about the padding can be found in difficult. More details about the padding can be found in
Section 5.4 and Appendix E.3 of RFC 8446. Section 5.4 and Appendix E.3 of RFC 8446.
8. IANA Considerations 8. 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(TBD) defined in this document. connection_id(TBD1) defined in this document.
IANA is requested to allocate tls12_cid(25) in the "TLS ContentType IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType
Registry". Registry".
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
[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 9.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-30 (work in progress), 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
November 2018. 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 9.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-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 draft-ietf-tls-dtls-connection-id-03
- Updated list of contributors - Updated list of contributors
- Updated list of contributors and acknowledgements - Updated list of contributors and acknowledgements
- Updated example - Updated example
- Changed record layer design - Changed record layer design
skipping to change at page 14, line 44 skipping to change at page 15, line 8
- Ian Swett (Google) - Ian Swett (Google)
- Mark Nottingham (Fastly) - Mark Nottingham (Fastly)
The task force team discussed various design ideas, including The task force team discussed various design ideas, including
cryptographically generated session cryptographically generated session
ids using hash chains and public key encryption, but dismissed them ids using hash chains and public key encryption, but dismissed them
due to their inefficiency. The approach described in this due to their inefficiency. The approach described in this
specification is the simplest possible design that works given the specification is the simplest possible design that works given the
limitations of DTLS 1.2. DTLS 1.3 provides better privacy features limitations of DTLS 1.2. DTLS 1.3 provides better privacy features
and developers are encouraged to switch to the new version of DTLS, and developers are encouraged to switch to the new version of DTLS.
if these privacy properties are important in a given deployment.
Finally, we want to thank the IETF TLS working group chairs, Chris Finally, we want to thank the IETF TLS working group chairs, Chris
Wood, Joseph Salowey, and Sean Turner, for their patience, support Wood, Joseph Salowey, and Sean Turner, for their patience, support
and feedback. and feedback.
Appendix D. Acknowledgements Appendix D. Acknowledgements
We would like to thank Achim Kraus for his review feedback. We would like to thank Achim Kraus for his review comments and
implementation feedback.
Authors' Addresses Authors' Addresses
Eric Rescorla (editor) Eric Rescorla (editor)
RTFM, Inc. RTFM, Inc.
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
Hannes Tschofenig (editor) Hannes Tschofenig (editor)
Arm Limited Arm Limited
 End of changes. 35 change blocks. 
62 lines changed or deleted 98 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/