draft-ietf-tls-tls13-24.txt   draft-ietf-tls-tls13-25.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246 (if approved) February 15, 2018 Obsoletes: 5077, 5246, 6961 (if March 02, 2018
Updates: 4492, 5705, 6066, 6961 (if approved)
approved) Updates: 4492, 5705, 6066 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 19, 2018 Expires: September 3, 2018
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-24 draft-ietf-tls-tls13-25
Abstract Abstract
This document specifies version 1.3 of the Transport Layer Security This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping, over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. tampering, and message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 19, 2018. This Internet-Draft will expire on September 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 7, line 14 skipping to change at page 7, line 14
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Change Log 1.2. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
(*) indicates changes to the wire protocol which may require (*) indicates changes to the wire protocol which may require
implementations to update. implementations to update.
draft-25 - Add the header to additional data (*)
- Minor clarifications.
- IANA cleanup.
draft-24 draft-24
- Require that CH2 have version 0303 (*) - Require that CH2 have version 0303 (*)
- Some clarifications - Some clarifications
draft-23 - Renumber key_share (*) draft-23 - Renumber key_share (*)
- Add a new extension and new code points to allow negotiating PSS - Add a new extension and new code points to allow negotiating PSS
separately for certificates and CertificateVerify (*) separately for certificates and CertificateVerify (*)
skipping to change at page 43, line 37 skipping to change at page 43, line 37
ClientHellos that include this extension but do not include 0x0304 in ClientHellos that include this extension but do not include 0x0304 in
the list of versions. the list of versions.
A server which negotiates TLS 1.3 MUST respond by sending a A server which negotiates TLS 1.3 MUST respond by sending a
"supported_versions" extension containing the selected version value "supported_versions" extension containing the selected version value
(0x0304). It MUST set the ServerHello.legacy_version field to 0x0303 (0x0304). It MUST set the ServerHello.legacy_version field to 0x0303
(TLS 1.2). Clients MUST check for this extension prior to processing (TLS 1.2). Clients MUST check for this extension prior to processing
the rest of the ServerHello (although they will have to parse the the rest of the ServerHello (although they will have to parse the
ServerHello in order to read the extension). If this extension is ServerHello in order to read the extension). If this extension is
present, clients MUST ignore the ServerHello.legacy_version value and present, clients MUST ignore the ServerHello.legacy_version value and
MUST use only the "supported_versions" extension to determine client MUST use only the "supported_versions" extension to determine the
preferences. If the "supported_versions" extension contains a selected version. If the "supported_versions" extension contains a
version not offered by the client, the client MUST abort the version not offered by the client, the client MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
4.2.1.1. Draft Version Indicator 4.2.1.1. Draft Version Indicator
RFC EDITOR: PLEASE REMOVE THIS SECTION RFC EDITOR: PLEASE REMOVE THIS SECTION
While the eventual version indicator for the RFC version of TLS 1.3 While the eventual version indicator for the RFC version of TLS 1.3
will be 0x0304, implementations of draft versions of this will be 0x0304, implementations of draft versions of this
specification SHOULD instead advertise 0x7f00 | draft_version in the specification SHOULD instead advertise 0x7f00 | draft_version in the
skipping to change at page 54, line 5 skipping to change at page 54, line 5
server_share A single KeyShareEntry value that is in the same group server_share A single KeyShareEntry value that is in the same group
as one of the client's shares. as one of the client's shares.
If using (EC)DHE key establishment, servers offer exactly one If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello. This value MUST be in the same KeyShareEntry in the ServerHello. This value MUST be in the same
group as the KeyShareEntry value offered by the client that the group as the KeyShareEntry value offered by the client that the
server has selected for the negotiated key exchange. Servers MUST server has selected for the negotiated key exchange. Servers MUST
NOT send a KeyShareEntry for any group not indicated in the NOT send a KeyShareEntry for any group not indicated in the
"supported_groups" extension and MUST NOT send a KeyShareEntry when "supported_groups" extension and MUST NOT send a KeyShareEntry when
using the "psk_ke" PskKeyExchangeMode. If a HelloRetryRequest was using the "psk_ke" PskKeyExchangeMode. If using (EC)DHE key
received by the client, the client MUST verify that the selected establishment, and a HelloRetryRequest containing a "key_share"
NamedGroup in the ServerHello is the same as that in the extension was received by the client, the client MUST verify that the
selected NamedGroup in the ServerHello is the same as that in the
HelloRetryRequest. If this check fails, the client MUST abort the HelloRetryRequest. If this check fails, the client MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
4.2.8.1. Diffie-Hellman Parameters 4.2.8.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of a KeyShareEntry in a encoded in the opaque key_exchange field of a KeyShareEntry in a
KeyShare structure. The opaque value contains the Diffie-Hellman KeyShare structure. The opaque value contains the Diffie-Hellman
public value (Y = g^X mod p) for the specified group (see [RFC7919] public value (Y = g^X mod p) for the specified group (see [RFC7919]
for group definitions) encoded as a big-endian integer and padded to for group definitions) encoded as a big-endian integer and padded to
skipping to change at page 60, line 18 skipping to change at page 60, line 18
value associated with the session matches the one specified in the value associated with the session matches the one specified in the
resumption handshake. However, in reality the implementations were resumption handshake. However, in reality the implementations were
not consistent on which of two supplied SNI values they would use, not consistent on which of two supplied SNI values they would use,
leading to the consistency requirement being de-facto enforced by the leading to the consistency requirement being de-facto enforced by the
clients. In TLS 1.3, the SNI value is always explicitly specified in clients. In TLS 1.3, the SNI value is always explicitly specified in
the resumption handshake, and there is no need for the server to the resumption handshake, and there is no need for the server to
associate an SNI value with the ticket. Clients, however, SHOULD associate an SNI value with the ticket. Clients, however, SHOULD
store the SNI with the PSK to fulfill the requirements of store the SNI with the PSK to fulfill the requirements of
Section 4.6.1. Section 4.6.1.
Implementor's note: the most straightforward way to implement the Implementor's note: when session resumption is the primary use case
PSK/cipher suite matching requirements is to negotiate the cipher of PSKs the most straightforward way to implement the PSK/cipher
suite first and then exclude any incompatible PSKs. Any unknown PSKs suite matching requirements is to negotiate the cipher suite first
(e.g., they are not in the PSK database or are encrypted with an and then exclude any incompatible PSKs. Any unknown PSKs (e.g., they
unknown key) SHOULD simply be ignored. If no acceptable PSKs are are not in the PSK database or are encrypted with an unknown key)
found, the server SHOULD perform a non-PSK handshake if possible. SHOULD simply be ignored. If no acceptable PSKs are found, the
server SHOULD perform a non-PSK handshake if possible. If backwards
compatibility is important, client provided, externally established
PSKs SHOULD influence cipher suite selection.
Prior to accepting PSK key establishment, the server MUST validate Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see Section 4.2.11.2 below). If this the corresponding binder value (see Section 4.2.11.2 below). If this
value is not present or does not validate, the server MUST abort the value is not present or does not validate, the server MUST abort the
handshake. Servers SHOULD NOT attempt to validate multiple binders; handshake. Servers SHOULD NOT attempt to validate multiple binders;
rather they SHOULD select a single PSK and validate solely the binder rather they SHOULD select a single PSK and validate solely the binder
that corresponds to that PSK. In order to accept PSK key that corresponds to that PSK. In order to accept PSK key
establishment, the server sends a "pre_shared_key" extension establishment, the server sends a "pre_shared_key" extension
indicating the selected identity. indicating the selected identity.
skipping to change at page 72, line 4 skipping to change at page 72, line 4
Structure of this message: Structure of this message:
struct { struct {
SignatureScheme algorithm; SignatureScheme algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} CertificateVerify; } CertificateVerify;
The algorithm field specifies the signature algorithm used (see The algorithm field specifies the signature algorithm used (see
Section 4.2.3 for the definition of this field). The signature is a Section 4.2.3 for the definition of this field). The signature is a
digital signature using that algorithm. The content that is covered digital signature using that algorithm. The content that is covered
under the signature is the hash output as described in Section 4.4, under the signature is the hash output as described in Section 4.4.1,
namely: namely:
Transcript-Hash(Handshake Context, Certificate) Transcript-Hash(Handshake Context, Certificate)
The digital signature is then computed over the concatenation of: The digital signature is then computed over the concatenation of:
- A string that consists of octet 32 (0x20) repeated 64 times - A string that consists of octet 32 (0x20) repeated 64 times
- The context string - The context string
skipping to change at page 81, line 48 skipping to change at page 81, line 48
a record that exceeds this length MUST terminate the connection a record that exceeds this length MUST terminate the connection
with a "record_overflow" alert. with a "record_overflow" alert.
fragment The data being transmitted. This value is transparent and fragment The data being transmitted. This value is transparent and
is treated as an independent block to be dealt with by the higher- is treated as an independent block to be dealt with by the higher-
level protocol specified by the type field. level protocol specified by the type field.
This document describes TLS 1.3, which uses the version 0x0304. This This document describes TLS 1.3, which uses the version 0x0304. This
version value is historical, deriving from the use of 0x0301 for TLS version value is historical, deriving from the use of 0x0301 for TLS
1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards
compatibility, records containing an initial ClientHello MUST have compatibility, records containing an initial ClientHello SHOULD have
version 0x0301 and a record containing a second ClientHello or a version 0x0301 and a record containing a second ClientHello or a
ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
respectively. When negotiating prior versions of TLS, endpoints respectively. When negotiating prior versions of TLS, endpoints
follow the procedure and requirements in Appendix D. follow the procedure and requirements in Appendix D.
When record protection has not yet been engaged, TLSPlaintext When record protection has not yet been engaged, TLSPlaintext
structures are written directly onto the wire. Once record structures are written directly onto the wire. Once record
protection has started, TLSPlaintext records are protected and sent protection has started, TLSPlaintext records are protected and sent
as described in the following section. as described in the following section.
skipping to change at page 83, line 10 skipping to change at page 83, line 10
opaque_type The outer opaque_type field of a TLSCiphertext record is opaque_type The outer opaque_type field of a TLSCiphertext record is
always set to the value 23 (application_data) for outward always set to the value 23 (application_data) for outward
compatibility with middleboxes accustomed to parsing previous compatibility with middleboxes accustomed to parsing previous
versions of TLS. The actual content type of the record is found versions of TLS. The actual content type of the record is found
in TLSInnerPlaintext.type after decryption. in TLSInnerPlaintext.type after decryption.
legacy_record_version The legacy_record_version field is always legacy_record_version The legacy_record_version field is always
0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS
1.3 has been negotiated, so there are no historical compatibility 1.3 has been negotiated, so there are no historical compatibility
concerns where other values might be received. Implementations concerns where other values might be received. Note that the
MAY verify that the legacy_record_version field is 0x0303 and handshake protocol including the ClientHello and ServerHello
abort the connection if it is not. Note that the handshake messages authenticates the protocol version, so this value is
protocol including the ClientHello and ServerHello messages redundant.
authenticates the protocol version, so this value is redundant.
length The length (in bytes) of the following length The length (in bytes) of the following
TLSCiphertext.encrypted_record, which is the sum of the lengths of TLSCiphertext.encrypted_record, which is the sum of the lengths of
the content and the padding, plus one for the inner content type, the content and the padding, plus one for the inner content type,
plus any expansion added by the AEAD algorithm. The length MUST plus any expansion added by the AEAD algorithm. The length MUST
NOT exceed 2^14 + 256 bytes. An endpoint that receives a record NOT exceed 2^14 + 256 bytes. An endpoint that receives a record
that exceeds this length MUST terminate the connection with a that exceeds this length MUST terminate the connection with a
"record_overflow" alert. "record_overflow" alert.
encrypted_record The AEAD-encrypted form of the serialized encrypted_record The AEAD-encrypted form of the serialized
TLSInnerPlaintext structure. TLSInnerPlaintext structure.
AEAD algorithms take as input a single key, a nonce, a plaintext, and AEAD algorithms take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [RFC5116]. The key is either the described in Section 2.1 of [RFC5116]. The key is either the
client_write_key or the server_write_key, the nonce is derived from client_write_key or the server_write_key, the nonce is derived from
the sequence number (see Section 5.3) and the client_write_iv or the sequence number (see Section 5.3) and the client_write_iv or
server_write_iv, and the additional data input is empty (zero server_write_iv, and the additional data input is the record header.
length). Derivation of traffic keys is defined in Section 7.3. I.e.,
additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version ||
TLSCiphertext.length
The plaintext input to the AEAD algorithm is the encoded The plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure. TLSInnerPlaintext structure. Derivation of traffic keys is defined
in Section 7.3.
The AEAD output consists of the ciphertext output from the AEAD The AEAD output consists of the ciphertext output from the AEAD
encryption operation. The length of the plaintext is greater than encryption operation. The length of the plaintext is greater than
the corresponding TLSPlaintext.length due to the inclusion of the corresponding TLSPlaintext.length due to the inclusion of
TLSInnerPlaintext.type and any padding supplied by the sender. The TLSInnerPlaintext.type and any padding supplied by the sender. The
length of the AEAD output will generally be larger than the length of the AEAD output will generally be larger than the
plaintext, but by an amount that varies with the AEAD algorithm. plaintext, but by an amount that varies with the AEAD algorithm.
Since the ciphers might incorporate padding, the amount of overhead Since the ciphers might incorporate padding, the amount of overhead
could vary with different lengths of plaintext. Symbolically, could vary with different lengths of plaintext. Symbolically,
AEADEncrypted = AEADEncrypted =
AEAD-Encrypt(write_key, nonce, plaintext) AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
Then the encrypted_record field of TLSCiphertext is set to
AEADEncrypted.
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
nonce, and the AEADEncrypted value. The output is either the nonce, additional data, and the AEADEncrypted value. The output is
plaintext or an error indicating that the decryption failed. There either the plaintext or an error indicating that the decryption
is no separate integrity check. That is: failed. There is no separate integrity check. That is:
plaintext of encrypted_record = plaintext of encrypted_record =
AEAD-Decrypt(peer_write_key, nonce, AEADEncrypted) AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
If the decryption fails, the receiver MUST terminate the connection If the decryption fails, the receiver MUST terminate the connection
with a "bad_record_mac" alert. with a "bad_record_mac" alert.
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion
greater than 255 octets. An endpoint that receives a record from its greater than 255 octets. An endpoint that receives a record from its
peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST
terminate the connection with a "record_overflow" alert. This limit terminate the connection with a "record_overflow" alert. This limit
is derived from the maximum TLSPlaintext length of 2^14 octets + 1 is derived from the maximum TLSPlaintext length of 2^14 octets + 1
octet for ContentType + the maximum AEAD expansion of 255 octets. octet for ContentType + the maximum AEAD expansion of 255 octets.
skipping to change at page 106, line 13 skipping to change at page 106, line 13
compliant. compliant.
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendix C, Appendix D, and Appendix E. Appendix C, Appendix D, and Appendix E.
11. IANA Considerations 11. IANA Considerations
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA has updated these to reference this document. The [RFC4346]. IANA [SHALL update/has updated] these to reference this
registries and their allocation policies are below: document. The registries and their allocation policies are below:
- TLS Cipher Suite Registry: values with the first byte in the range - TLS Cipher Suite Registry: values with the first byte in the range
0-254 (decimal) are assigned via Specification Required [RFC8126]. 0-254 (decimal) are assigned via Specification Required [RFC8126].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
Use [RFC8126]. Use [RFC8126].
IANA [SHALL add/has added] the cipher suites listed in IANA [SHALL add/has added] the cipher suites listed in
Appendix B.4 to the registry. The "Value" and "Description" Appendix B.4 to the registry. The "Value" and "Description"
columns are taken from the table. The "DTLS-OK" and "Recommended" columns are taken from the table. The "DTLS-OK" and "Recommended"
columns are both marked as "Yes" for each new cipher suite. columns are both marked as "Yes" for each new cipher suite.
[[This assumes [I-D.ietf-tls-iana-registry-updates] has been [[This assumes [I-D.ietf-tls-iana-registry-updates] has been
applied.]] applied.]]
- TLS ContentType Registry: Future values are allocated via - TLS ContentType Registry: Future values are allocated via
Standards Action [RFC8126]. Standards Action [RFC8126].
- TLS Alert Registry: Future values are allocated via Standards - TLS Alert Registry: Future values are allocated via Standards
Action [RFC8126]. IANA [SHALL update/has updated] this registry Action [RFC8126]. IANA [SHALL update/has updated] this registry
to include values for "missing_extension" and to include values for "missing_extension" and
"certificate_required". "certificate_required". The "DTLS-OK" column is marked as "Yes"
for each new alert.
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC8126]. IANA [SHALL update/has updated] this Standards Action [RFC8126]. IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the "new_session_ticket" and to add the
"hello_retry_request_RESERVED", "encrypted_extensions", "hello_retry_request_RESERVED", "encrypted_extensions",
"end_of_early_data", "key_update", and "message_hash" values. "end_of_early_data", "key_update", and "message_hash" values. The
"DTLS-OK" are marked as "Yes" for each of these additions.
This document also uses the TLS ExtensionType Registry originally This document also uses the TLS ExtensionType Registry originally
created in [RFC4366]. IANA has updated it to reference this created in [RFC4366]. IANA has updated it to reference this
document. The registry and its allocation policy is listed below: document. Changes to the registry follow:
- IANA [SHALL update/has updated] the registration policy as
follows:
Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required [RFC8126]. Values with the
first byte 255 (decimal) are reserved for Private Use [RFC8126].
- IANA [SHALL update/has updated] this registry to include the - IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes", "key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions", "early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", "post_handshake_auth", "certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_cert", extensions with the values and "signature_algorithms_cert", extensions with the values
defined in this document and the Recommended value of "Yes". defined in this document and the Recommended value of "Yes".
- IANA [SHALL update/has updated] this registry to include a "TLS - IANA [SHALL update/has updated] this registry to include a "TLS
1.3" column which lists the messages in which the extension may 1.3" column which lists the messages in which the extension may
skipping to change at page 107, line 24 skipping to change at page 107, line 35
- TLS SignatureScheme Registry: Values with the first byte in the - TLS SignatureScheme Registry: Values with the first byte in the
range 0-253 (decimal) are assigned via Specification Required range 0-253 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 254 or 255 (decimal) are [RFC8126]. Values with the first byte 254 or 255 (decimal) are
reserved for Private Use [RFC8126]. Values with the first byte in reserved for Private Use [RFC8126]. Values with the first byte in
the range 0-6 or with the second byte in the range 0-3 that are the range 0-6 or with the second byte in the range 0-3 that are
not currently allocated are reserved for backwards compatibility. not currently allocated are reserved for backwards compatibility.
This registry SHALL have a "Recommended" column. The registry This registry SHALL have a "Recommended" column. The registry
[shall be/ has been] initially populated with the values described [shall be/ has been] initially populated with the values described
in Section 4.2.3. The following values SHALL be marked as in Section 4.2.3. The following values SHALL be marked as
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
ed25519.
12. References 12. References
12.1. Normative References 12.1. Normative References
[DH] Diffie, W. and M. Hellman, "New Directions in [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977. V.IT-22 n.6 , June 1977.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
skipping to change at page 110, line 16 skipping to change at page 110, line 34
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
12.2. Informative References 12.2. Informative References
[AEAD-LIMITS] [AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", 2016, Encryption Use in TLS", 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[Anon18] Anonymous, A., "Secure Channels for Multiplexed Data
Streams: Analyzing the TLS 1.3 Record Layer Without
Elision", In submission to CRYPTO 2018. RFC EDITOR: PLEASE
UPDATE THIS REFERENCE AFTER FINAL NOTIFICATION
(2018-4-29). , 2018.
[BBFKZG16] [BBFKZG16]
Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M., Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M.,
Zanella-Beguelin, S., and M. Green, "Downgrade Resilience Zanella-Beguelin, S., and M. Green, "Downgrade Resilience
in Key-Exchange Protocols", Proceedings of IEEE Symposium in Key-Exchange Protocols", Proceedings of IEEE Symposium
on Security and Privacy (Oakland) 2016 , 2016. on Security and Privacy (Oakland) 2016 , 2016.
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified
Models and Reference Implementations for the TLS 1.3 Models and Reference Implementations for the TLS 1.3
Standard Candidate", Proceedings of IEEE Symposium on Standard Candidate", Proceedings of IEEE Symposium on
Security and Privacy (Oakland) 2017 , 2017. Security and Privacy (Oakland) 2017 , 2017.
skipping to change at page 112, line 41 skipping to change at page 113, line 21
EURASIP Journal on Information Security Vol. 2016, EURASIP Journal on Information Security Vol. 2016,
DOI 10.1186/s13635-016-0030-7, February 2016. DOI 10.1186/s13635-016-0030-7, February 2016.
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
"Prying Open Pandora's Box: KCI Attacks against TLS", "Prying Open Pandora's Box: KCI Attacks against TLS",
Proceedings of USENIX Workshop on Offensive Technologies , Proceedings of USENIX Workshop on Offensive Technologies ,
2015. 2015.
[I-D.ietf-tls-iana-registry-updates] [I-D.ietf-tls-iana-registry-updates]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", draft-ietf-tls-iana-registry-updates-03 (work and DTLS", draft-ietf-tls-iana-registry-updates-04 (work
in progress), January 2018. in progress), February 2018.
[I-D.ietf-tls-tls13-vectors] [I-D.ietf-tls-tls13-vectors]
Thomson, M., "Example Handshake Traces for TLS 1.3", Thomson, M., "Example Handshake Traces for TLS 1.3",
draft-ietf-tls-tls13-vectors-03 (work in progress), draft-ietf-tls-tls13-vectors-03 (work in progress),
December 2017. December 2017.
[IEEE1363] [IEEE1363]
IEEE, "Standard Specifications for Public Key IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363 , 2000. Cryptography", IEEE 1363 , 2000.
skipping to change at page 114, line 35 skipping to change at page 115, line 21
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006, <https://www.rfc- DOI 10.17487/RFC4492, May 2006, <https://www.rfc-
editor.org/info/rfc4492>. editor.org/info/rfc4492>.
[RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User
Mapping Extension", RFC 4681, DOI 10.17487/RFC4681,
October 2006, <https://www.rfc-editor.org/info/rfc4681>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 134, line 45 skipping to change at page 134, line 45
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and and there is at least the ClientHello format remains compatible and and there is at least
one protocol version supported by both the client and the server. one protocol version supported by both the client and the server.
Prior versions of TLS used the record layer version number for Prior versions of TLS used the record layer version number for
various purposes. (TLSPlaintext.legacy_record_version and various purposes. (TLSPlaintext.legacy_record_version and
TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is
deprecated. The value of TLSPlaintext.legacy_record_version MUST be deprecated. The value of TLSPlaintext.legacy_record_version MUST be
ignored by all implementations. The value of ignored by all implementations. The value of
TLSCiphertext.legacy_record_version MAY be ignored, or MAY be TLSCiphertext.legacy_record_version is included in the additional
data for deprotection but MAY otherwise be ignored or MAY be
validated to match the fixed constant value. Version negotiation is validated to match the fixed constant value. Version negotiation is
performed using only the handshake versions performed using only the handshake versions
(ClientHello.legacy_version, ServerHello.legacy_version, as well as (ClientHello.legacy_version, ServerHello.legacy_version, as well as
the ClientHello, HelloRetryRequest and ServerHello the ClientHello, HelloRetryRequest and ServerHello
"supported_versions" extensions). In order to maximize "supported_versions" extensions). In order to maximize
interoperability with older endpoints, implementations that negotiate interoperability with older endpoints, implementations that negotiate
the use of TLS 1.0-1.2 SHOULD set the record layer version number to the use of TLS 1.0-1.2 SHOULD set the record layer version number to
the negotiated version for the ServerHello and all records the negotiated version for the ServerHello and all records
thereafter. thereafter.
skipping to change at page 139, line 43 skipping to change at page 139, line 43
Forward secret with respect to long-term keys If the long-term Forward secret with respect to long-term keys If the long-term
keying material (in this case the signature keys in certificate- keying material (in this case the signature keys in certificate-
based authentication modes or the external/resumption PSK in PSK based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) is compromised after the handshake is with (EC)DHE modes) is compromised after the handshake is
complete, this does not compromise the security of the session key complete, this does not compromise the security of the session key
(See [DOW92]), as long as the session key itself has been erased. (See [DOW92]), as long as the session key itself has been erased.
The forward secrecy property is not satisfied when PSK is used in The forward secrecy property is not satisfied when PSK is used in
the "psk_ke" PskKeyExchangeMode. the "psk_ke" PskKeyExchangeMode.
Key Compromise Impersonation (KCI) resistance In a mutually- Key Compromise Impersonation (KCI) resistance In a mutually-
authenticated connection with certificates, peer authentication authenticated connection with certificates, compromising the long-
should hold even if the local long-term secret was compromised term secret of one actor should not break that actor's
before the connection was established (see [HGFS15]). For authentication of their peer in the given connection (see
example, if a client's signature key is compromised, it should not [HGFS15]). For example, if a client's signature key is
be possible to impersonate arbitrary servers to that client in compromised, it should not be possible to impersonate arbitrary
subsequent handshakes. servers to that client in subsequent handshakes.
Protection of endpoint identities. The server's identity Protection of endpoint identities. The server's identity
(certificate) should be protected against passive attackers. The (certificate) should be protected against passive attackers. The
client's identity should be protected against both passive and client's identity should be protected against both passive and
active attackers. active attackers.
Informally, the signature-based modes of TLS 1.3 provide for the Informally, the signature-based modes of TLS 1.3 provide for the
establishment of a unique, secret, shared key established by an establishment of a unique, secret, shared key established by an
(EC)DHE key exchange and authenticated by the server's signature over (EC)DHE key exchange and authenticated by the server's signature over
the handshake transcript, as well as tied to the server's identity by the handshake transcript, as well as tied to the server's identity by
skipping to change at page 144, line 41 skipping to change at page 144, line 41
That is, TLS does not provide post-compromise security/future That is, TLS does not provide post-compromise security/future
secrecy/backward secrecy with respect to the traffic secret. Indeed, secrecy/backward secrecy with respect to the traffic secret. Indeed,
an attacker who learns a traffic secret can compute all future an attacker who learns a traffic secret can compute all future
traffic secrets on that connection. Systems which want such traffic secrets on that connection. Systems which want such
guarantees need to do a fresh handshake and establish a new guarantees need to do a fresh handshake and establish a new
connection with an (EC)DHE exchange. connection with an (EC)DHE exchange.
E.2.1. External References E.2.1. External References
The reader should refer to the following references for analysis of The reader should refer to the following references for analysis of
the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17]. the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17]
[Anon18].
E.3. Traffic Analysis E.3. Traffic Analysis
TLS is susceptible to a variety of traffic analysis attacks based on TLS is susceptible to a variety of traffic analysis attacks based on
observing the length and timing of encrypted packets [CLINIC] observing the length and timing of encrypted packets [CLINIC]
[HCJ16]. This is particularly easy when there is a small set of [HCJ16]. This is particularly easy when there is a small set of
possible messages to be distinguished, such as for a video server possible messages to be distinguished, such as for a video server
hosting a fixed corpus of content, but still provides usable hosting a fixed corpus of content, but still provides usable
information even in more complicated scenarios. information even in more complicated scenarios.
skipping to change at page 149, line 51 skipping to change at page 149, line 51
cas.cremers@cs.ox.ac.uk cas.cremers@cs.ox.ac.uk
- Antoine Delignat-Lavaud (co-author of [RFC7627]) - Antoine Delignat-Lavaud (co-author of [RFC7627])
INRIA INRIA
antoine.delignat-lavaud@inria.fr antoine.delignat-lavaud@inria.fr
- Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) - Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
Independent Independent
tim@dierks.org tim@dierks.org
- Roelof DuToit
Symantec Corporation
roelof_dutoit@symantec.com
- Taher Elgamal - Taher Elgamal
Securify Securify
taher@securify.com taher@securify.com
- Pasi Eronen - Pasi Eronen
Nokia Nokia
pasi.eronen@nokia.com pasi.eronen@nokia.com
- Cedric Fournet - Cedric Fournet
Microsoft Microsoft
 End of changes. 29 change blocks. 
54 lines changed or deleted 89 lines changed or added

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