draft-ietf-tls-tls13-11.txt   draft-ietf-tls-tls13-12.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246, 5746 (if December 28, 2015 Obsoletes: 5077, 5246, 5746 (if March 21, 2016
approved) approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 30, 2016 Expires: September 22, 2016
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-11 draft-ietf-tls-tls13-12
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. The TLS protocol allows client/server applications (TLS) protocol. The TLS protocol allows client/server applications
to communicate over the Internet in a way that is designed to prevent to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery. eavesdropping, 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 June 30, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 9 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 10
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 10 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 10
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 10 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 10
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 13 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 13
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Cryptographic Attributes . . . . . . . . . . . . . . . . 14 4.8. Cryptographic Attributes . . . . . . . . . . . . . . . . 15
4.8.1. Digital Signing . . . . . . . . . . . . . . . . . . . 15 4.8.1. Digital Signing . . . . . . . . . . . . . . . . . . . 16
4.8.2. Authenticated Encryption with Additional Data (AEAD) 16 4.8.2. Authenticated Encryption with Additional Data (AEAD) 17
5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 17 5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 17
5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 5.1. Connection States . . . . . . . . . . . . . . . . . . . . 18
5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21 5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21
5.2.3. Record Padding . . . . . . . . . . . . . . . . . . . 23 5.2.3. Record Padding . . . . . . . . . . . . . . . . . . . 24
6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 24 6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 25
6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 25 6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 26 6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 26
6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 28 6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 28
6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 31 6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 31
6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 35 6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 35
6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 36 6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 36
6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 37 6.2.3. Resumption and Pre-Shared Key (PSK) . . . . . . . . . 37
6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 39 6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 39
6.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 40 6.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 40
6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 46 6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 46
6.3.3. Server Parameters . . . . . . . . . . . . . . . . . . 58 6.3.3. Server Parameters . . . . . . . . . . . . . . . . . . 59
6.3.4. Authentication Messages . . . . . . . . . . . . . . . 63 6.3.4. Authentication Messages . . . . . . . . . . . . . . . 63
6.3.5. Post-Handshake Messages . . . . . . . . . . . . . . . 71 6.3.5. Post-Handshake Messages . . . . . . . . . . . . . . . 71
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 73 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 73
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 73 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 73
7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 75 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 76
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 76 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 76
7.3.1. The Handshake Hash . . . . . . . . . . . . . . . . . 77 7.3.1. The Handshake Hash . . . . . . . . . . . . . . . . . 77
7.3.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 77 7.3.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 78
7.3.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 77 7.3.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 78
8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 78 7.3.4. Exporters . . . . . . . . . . . . . . . . . . . . . . 78
8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 78 8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 79
8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 78 8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 79
9. Application Data Protocol . . . . . . . . . . . . . . . . . . 79 8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 79
9. Application Data Protocol . . . . . . . . . . . . . . . . . . 80
10. Security Considerations . . . . . . . . . . . . . . . . . . . 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.1. Normative References . . . . . . . . . . . . . . . . . . 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 84
12.2. Informative References . . . . . . . . . . . . . . . . . 85 12.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix A. Protocol Data Structures and Constant Values . . . . 91 Appendix A. Protocol Data Structures and Constant Values . . . . 92
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 91 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 92
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 91 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 92
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 93 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 94
A.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 93 A.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 94
A.3.2. Server Parameters Messages . . . . . . . . . . . . . 98 A.3.2. Server Parameters Messages . . . . . . . . . . . . . 98
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 98 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 99
A.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 99 A.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 100
A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 99 A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 100
A.4.1. Unauthenticated Operation . . . . . . . . . . . . . . 102 A.4.1. Unauthenticated Operation . . . . . . . . . . . . . . 105
A.5. The Security Parameters . . . . . . . . . . . . . . . . . 102 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 105
A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 103 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 106
Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 104 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 107
B.1. Random Number Generation and Seeding . . . . . . . . . . 104 B.1. Random Number Generation and Seeding . . . . . . . . . . 107
B.2. Certificates and Authentication . . . . . . . . . . . . . 104 B.2. Certificates and Authentication . . . . . . . . . . . . . 107
B.3. Cipher Suite Support . . . . . . . . . . . . . . . . . . 104 B.3. Cipher Suite Support . . . . . . . . . . . . . . . . . . 107
B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 104 B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 107
Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 106 Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 109
C.1. Negotiating with an older server . . . . . . . . . . . . 106 C.1. Negotiating with an older server . . . . . . . . . . . . 109
C.2. Negotiating with an older client . . . . . . . . . . . . 107 C.2. Negotiating with an older client . . . . . . . . . . . . 110
C.3. Backwards Compatibility Security Restrictions . . . . . . 107 C.3. Backwards Compatibility Security Restrictions . . . . . . 110
Appendix D. Security Analysis . . . . . . . . . . . . . . . . . 108 Appendix D. Security Analysis . . . . . . . . . . . . . . . . . 111
D.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 108 D.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 112
D.1.1. Authentication and Key Exchange . . . . . . . . . . . 109 D.1.1. Authentication and Key Exchange . . . . . . . . . . . 112
D.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 109 D.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 113
D.1.3. Detecting Attacks Against the Handshake Protocol . . 110 D.1.3. Detecting Attacks Against the Handshake Protocol . . 113
D.2. Protecting Application Data . . . . . . . . . . . . . . . 113
D.2. Protecting Application Data . . . . . . . . . . . . . . . 110 D.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 114
D.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 110 D.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 114
D.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 111 Appendix E. Working Group Information . . . . . . . . . . . . . 114
Appendix E. Working Group Information . . . . . . . . . . . . . 111 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 114
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 115
1. Introduction 1. Introduction
DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
significant security analysis. significant security analysis.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/tlswg/tls13-spec. as pull requests at https://github.com/tlswg/tls13-spec.
Instructions are on that page as well. Editorial changes can be Instructions are on that page as well. Editorial changes can be
skipping to change at page 6, line 12 skipping to change at page 6, line 14
sender: An endpoint that is transmitting records. sender: An endpoint that is transmitting records.
session: An association between a client and a server resulting from session: An association between a client and a server resulting from
a handshake. a handshake.
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-12
- Provide a list of the PSK cipher sutes.
- Remove the ability for the ServerHello to have no extensions (this
aligns the syntax with the text).
- Clarify that the server can send application data after its first
flight (0.5 RTT data)
- Revise signature algorithm negotiation to group hash, signature
algorithm, and curve together. This is backwards compatible.
- Make ticket lifetime mandatory and limit it to a week.
- Make the purpose strings lower-case. This matches how people are
implementing for interop.
- Define exporters.
- Editorial cleanup
draft-11 draft-11
- Port the CFRG curves & signatures work from RFC4492bis. - Port the CFRG curves & signatures work from RFC4492bis.
- Remove sequence number and version from additional_data, which is - Remove sequence number and version from additional_data, which is
now empty. now empty.
- Reorder values in HkdfLabel. - Reorder values in HkdfLabel.
- Add support for version anti-downgrade mechanism. - Add support for version anti-downgrade mechanism.
skipping to change at page 15, line 13 skipping to change at page 16, line 12
field's cryptographic processing is specified by prepending an field's cryptographic processing is specified by prepending an
appropriate key word designation before the field's type appropriate key word designation before the field's type
specification. Cryptographic keys are implied by the current session specification. Cryptographic keys are implied by the current session
state (see Section 5.1). state (see Section 5.1).
4.8.1. Digital Signing 4.8.1. Digital Signing
A digitally-signed element is encoded as a struct DigitallySigned: A digitally-signed element is encoded as a struct DigitallySigned:
struct { struct {
SignatureAndHashAlgorithm algorithm; SignatureScheme algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} DigitallySigned; } DigitallySigned;
The algorithm field specifies the algorithm used (see Section 6.3.2.1 The algorithm field specifies the algorithm used (see Section 6.3.2.1
for the definition of this field). Note that the algorithm field was for the definition of this field). The signature is a digital
introduced in TLS 1.2, and is not in earlier versions. The signature signature using those algorithms over the contents of the element.
is a digital signature using those algorithms over the contents of The contents themselves do not appear on the wire but are simply
the element. The contents themselves do not appear on the wire but calculated. The length of the signature is specified by the signing
are simply calculated. The length of the signature is specified by algorithm and key.
the signing algorithm and key.
In previous versions of TLS, the ServerKeyExchange format meant that In previous versions of TLS, the ServerKeyExchange format meant that
attackers can obtain a signature of a message with a chosen, 32-byte attackers can obtain a signature of a message with a chosen, 32-byte
prefix. Because TLS 1.3 servers are likely to also implement prior prefix. Because TLS 1.3 servers are likely to also implement prior
versions, the contents of the element always start with 64 bytes of versions, the contents of the element always start with 64 bytes of
octet 32 in order to clear that chosen-prefix. octet 32 in order to clear that chosen-prefix.
Following that padding is a context string used to disambiguate Following that padding is a context string used to disambiguate
signatures for different purposes. The context string will be signatures for different purposes. The context string will be
specified whenever a digitally-signed element is used. A single 0 specified whenever a digitally-signed element is used. A single 0
byte is appended to the context to act as a separator. byte is appended to the context to act as a separator.
Finally, the specified contents of the digitally-signed structure Finally, the specified contents of the digitally-signed structure
follow the NUL after the context string. (See the example at the end follow the 0 byte after the context string. (See the example at the
of this section.) end of this section.)
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in [RFC3447] with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature). The length of the salt MUST be equal to the
length of the digest output. Note that previous versions of TLS used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.
All ECDSA computations MUST be performed according to ANSI X9.62
[X962] or its successors. Data to be signed/verified is hashed, and
the result run directly through the ECDSA algorithm with no
additional hashing. The SignatureAndHashAlgorithm parameter in the
DigitallySigned object indicates the digest algorithm which was used
in the signature. Signature-only curves MUST NOT be used for ECDSA
unless otherwise noted.
All EdDSA computations MUST be performed according to The combined input is then fed into the corresponding signature
[I-D.irtf-cfrg-eddsa] or its successors. Data to be signed/verified algorithm to produce the signature value on the wire. See
is passed as-is to the EdDSA algorithm with no hashing. The Section 6.3.2.1 for algorithms defined in this specification.
signature output is placed as-is in the signature field. The
SignatureAndHashAlgorithm.hash value MUST set to none(0).
In the following example In the following example
struct { struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
digitally-signed opaque { digitally-signed opaque {
uint8 field3<0..255>; uint8 field3<0..255>;
uint8 field4; uint8 field4;
}; };
skipping to change at page 16, line 35 skipping to change at page 17, line 15
Assume that the context string for the signature was specified as Assume that the context string for the signature was specified as
"Example". The input for the signature/hash algorithm would be: "Example". The input for the signature/hash algorithm would be:
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
4578616d706c6500 4578616d706c6500
followed by the encoding of the inner struct (field3 and field4). followed by the encoding of the inner struct (field3 and field4).
The length of the structure, in bytes, would be equal to two bytes The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature and hash for field1 and field2, plus two bytes for the signature algorithm,
algorithm, plus two bytes for the length of the signature, plus the plus two bytes for the length of the signature, plus the length of
length of the output of the signing algorithm. The length of the the output of the signing algorithm. The length of the signature is
signature is known because the algorithm and key used for the signing known because the algorithm and key used for the signing are known
are known prior to encoding or decoding this structure. prior to encoding or decoding this structure.
4.8.2. Authenticated Encryption with Additional Data (AEAD) 4.8.2. Authenticated Encryption with Additional Data (AEAD)
In AEAD encryption, the plaintext is simultaneously encrypted and In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length, and aead- integrity protected. The input may be of any length, and aead-
ciphered output is generally larger than the input in order to ciphered output is generally larger than the input in order to
accommodate the integrity check value. accommodate the integrity check value.
5. The TLS Record Protocol 5. The TLS Record Protocol
skipping to change at page 25, line 7 skipping to change at page 25, line 29
X509v3 [RFC5280] certificate of the peer. This element of the X509v3 [RFC5280] certificate of the peer. This element of the
state may be null. state may be null.
cipher spec cipher spec
Specifies the authentication and key establishment algorithms, the Specifies the authentication and key establishment algorithms, the
hash for use with HKDF to generate keying material, and the record hash for use with HKDF to generate keying material, and the record
protection algorithm (See Appendix A.5 for formal definition.) protection algorithm (See Appendix A.5 for formal definition.)
resumption master secret resumption master secret
a secret shared between the client and server that can be used as a secret shared between the client and server that can be used as
a PSK in future connections. a pre-shared symmetric key (PSK) in future connections.
These items are then used to create security parameters for use by These items are then used to create security parameters for use by
the record layer when protecting application data. Many connections the record layer when protecting application data. Many connections
can be instantiated using the same session using a PSK established in can be instantiated using the same session using a PSK established in
an initial handshake. an initial handshake.
6.1. Alert Protocol 6.1. Alert Protocol
One of the content types supported by the TLS record layer is the One of the content types supported by the TLS record layer is the
alert type. Alert messages convey the severity of the message alert type. Alert messages convey the severity of the message
skipping to change at page 32, line 31 skipping to change at page 32, line 31
Key / ClientHello Key / ClientHello
Exch \ + key_share --------> Exch \ + key_share -------->
ServerHello \ Key ServerHello \ Key
+ key_share / Exch + key_share / Exch
{EncryptedExtensions} ^ {EncryptedExtensions} ^
{CertificateRequest*} | Server {CertificateRequest*} | Server
{ServerConfiguration*} v Params {ServerConfiguration*} v Params
{Certificate*} ^ {Certificate*} ^
{CertificateVerify*} | Auth {CertificateVerify*} | Auth
<-------- {Finished} v {Finished} v
<-------- [Application Data*]
^ {Certificate*} ^ {Certificate*}
Auth | {CertificateVerify*} Auth | {CertificateVerify*}
v {Finished} --------> v {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
+ Indicates extensions sent in the + Indicates extensions sent in the
previously noted message. previously noted message.
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages that are not always sent. messages that are not always sent.
skipping to change at page 35, line 28 skipping to change at page 35, line 28
ClientHello ClientHello
+ key_share --------> + key_share -------->
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} {Finished}
<-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 2: Message flow for a full handshake with mismatched Figure 2: Message flow for a full handshake with mismatched
parameters parameters
[[OPEN ISSUE: Should we restart the handshake hash? [[OPEN ISSUE: Should we restart the handshake hash?
https://github.com/tlswg/tls13-spec/issues/104.]] [[OPEN ISSUE: We https://github.com/tlswg/tls13-spec/issues/104.]] [[OPEN ISSUE: We
skipping to change at page 36, line 32 skipping to change at page 36, line 32
v (Application Data*) v (Application Data*)
(end_of_early_data) --------> (end_of_early_data) -------->
ServerHello ServerHello
+ early_data + early_data
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} {Finished}
<-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages that are not always sent. messages that are not always sent.
() Indicates messages protected using keys () Indicates messages protected using keys
skipping to change at page 37, line 40 skipping to change at page 37, line 40
application layer protocol. However, 0-RTT data cannot be application layer protocol. However, 0-RTT data cannot be
duplicated within a connection (i.e., the server will not process duplicated within a connection (i.e., the server will not process
the same data twice for the same connection) and also cannot be the same data twice for the same connection) and also cannot be
sent as if it were ordinary TLS data. sent as if it were ordinary TLS data.
3. If the server key is compromised, then the attacker can tamper 3. If the server key is compromised, then the attacker can tamper
with the 0-RTT data without detection. If the client's ephemeral with the 0-RTT data without detection. If the client's ephemeral
share is compromised and client authentication is used, then the share is compromised and client authentication is used, then the
attacker can impersonate the client on subsequent connections. attacker can impersonate the client on subsequent connections.
6.2.3. Resumption and PSK 6.2.3. Resumption and Pre-Shared Key (PSK)
Finally, TLS provides a pre-shared key (PSK) mode which allows a Finally, TLS provides a pre-shared key (PSK) mode which allows a
client and server who share an existing secret (e.g., a key client and server who share an existing secret (e.g., a key
established out of band) to establish a connection authenticated by established out of band) to establish a connection authenticated by
that key. PSKs can also be established in a previous session and that key. PSKs can also be established in a previous session and
then reused ("session resumption"). Once a handshake has completed, then reused ("session resumption"). Once a handshake has completed,
the server can send the client a PSK identity which corresponds to a the server can send the client a PSK identity which corresponds to a
key derived from the initial handshake (See Section 6.3.5.1). The key derived from the initial handshake (See Section 6.3.5.1). The
client can then use that PSK identity in future handshakes to client can then use that PSK identity in future handshakes to
negotiate use of the PSK; if the server accepts it, then the security negotiate use of the PSK; if the server accepts it, then the security
skipping to change at page 38, line 27 skipping to change at page 38, line 27
Initial Handshake: Initial Handshake:
ClientHello ClientHello
+ key_share --------> + key_share -------->
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} {Finished}
<-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
<-------- [NewSessionTicket] <-------- [NewSessionTicket]
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Subsequent Handshake: Subsequent Handshake:
ClientHello ClientHello
+ key_share + key_share
+ pre_shared_key --------> + pre_shared_key -------->
ServerHello ServerHello
+ pre_shared_key + pre_shared_key
{EncryptedExtensions} {EncryptedExtensions}
<-------- {Finished} {Finished}
<-------- [Application Data*]
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 4: Message flow for resumption and PSK Figure 4: Message flow for resumption and PSK
As the server is authenticating via a PSK, it does not send a As the server is authenticating via a PSK, it does not send a
Certificate or a CertificateVerify. PSK-based resumption cannot be Certificate or a CertificateVerify. PSK-based resumption cannot be
used to provide a new ServerConfiguration. Note that the client used to provide a new ServerConfiguration. Note that the client
supplies a KeyShare to the server as well, which allows the server to supplies a KeyShare to the server as well, which allows the server to
decline resumption and fall back to a full handshake. decline resumption and fall back to a full handshake.
skipping to change at page 39, line 38 skipping to change at page 40, line 24
server_configuration(17), server_configuration(17),
finished(20), finished(20),
key_update(24), key_update(24),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_configuration:ServerConfiguration; case server_configuration: ServerConfiguration;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case session_ticket: NewSessionTicket; case session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
} body; } body;
} Handshake; } Handshake;
The TLS Handshake Protocol messages are presented below in the order The TLS Handshake Protocol messages are presented below in the order
they MUST be sent; sending handshake messages in an unexpected order they MUST be sent; sending handshake messages in an unexpected order
results in an "unexpected_message" fatal error. Unneeded handshake results in an "unexpected_message" fatal error. Unneeded handshake
messages can be omitted, however. messages can be omitted, however.
New handshake message types are assigned by IANA as described in New handshake message types are assigned by IANA as described in
Section 11. Section 11.
skipping to change at page 42, line 22 skipping to change at page 42, line 48
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} ClientHello; } ClientHello;
TLS allows extensions to follow the compression_methods field in an TLS allows extensions to follow the compression_methods field in an
extensions block. The presence of extensions can be detected by extensions block. The presence of extensions can be detected by
determining whether there are bytes following the compression_methods determining whether there are bytes following the compression_methods
at the end of the ClientHello. Note that this method of detecting at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS variable-length field, but it is used for compatibility with TLS
before extensions were defined. before extensions were defined. As of TLS 1.3, all clients and
servers will send at least one extension (at least "key_share" or
"pre_shared_key").
client_version client_version
The version of the TLS protocol by which the client wishes to The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this (highest valued) version supported by the client. For this
version of the specification, the version will be { 3, 4 }. (See version of the specification, the version will be { 3, 4 }. (See
Appendix C for details about backward compatibility.) Appendix C for details about backward compatibility.)
random random
A client-generated random structure. A client-generated random structure.
skipping to change at page 43, line 11 skipping to change at page 43, line 41
ClientHello, this vector MUST contain exactly one byte set to ClientHello, this vector MUST contain exactly one byte set to
zero, which corresponds to the "null" compression method in prior zero, which corresponds to the "null" compression method in prior
versions of TLS. If a TLS 1.3 ClientHello is received with any versions of TLS. If a TLS 1.3 ClientHello is received with any
other value in this field, the server MUST generate a fatal other value in this field, the server MUST generate a fatal
"illegal_parameter" alert. Note that TLS 1.3 servers might "illegal_parameter" alert. Note that TLS 1.3 servers might
receive TLS 1.2 or prior ClientHellos which contain other receive TLS 1.2 or prior ClientHellos which contain other
compression methods and MUST follow the procedures for the compression methods and MUST follow the procedures for the
appropriate prior version of TLS. appropriate prior version of TLS.
extensions extensions
Clients MAY request extended functionality from servers by sending Clients request extended functionality from servers by sending
data in the extensions field. The actual "Extension" format is data in the extensions field. The actual "Extension" format is
defined in Section 6.3.2. defined in Section 6.3.2.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake. A server MUST accept ClientHello client MAY abort the handshake. A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all messages both with and without the extensions field, and (as for all
other messages) it MUST check that the amount of data in the message other messages) it MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert. fatal "decode_error" alert.
skipping to change at page 43, line 42 skipping to change at page 44, line 24
and the client's "key_share" extension was acceptable. If the and the client's "key_share" extension was acceptable. If the
client proposed groups are not acceptable by the server, it will client proposed groups are not acceptable by the server, it will
respond with a "handshake_failure" fatal alert. respond with a "handshake_failure" fatal alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { Extension extensions<0..2^16-1>;
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello; } ServerHello;
The presence of extensions can be detected by determining whether In prior versions of TLS, the extensions field could be omitted
there are bytes following the cipher_suite field at the end of the entirely if not needed, similar to ClientHello. As of TLS 1.3, all
ServerHello. clients and servers will send at least one extension (at least
"key_share" or "pre_shared_key").
server_version server_version
This field will contain the lower of that suggested by the client This field will contain the lower of that suggested by the client
in the ClientHello and the highest supported by the server. For in the ClientHello and the highest supported by the server. For
this version of the specification, the version is { 3, 4 }. (See this version of the specification, the version is { 3, 4 }. (See
Appendix C for details about backward compatibility.) Appendix C for details about backward compatibility.)
random random
This structure is generated by the server and MUST be generated This structure is generated by the server and MUST be generated
independently of the ClientHello.random. independently of the ClientHello.random.
skipping to change at page 46, line 17 skipping to change at page 46, line 33
The extension format is: The extension format is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
supported_groups(10), supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), key_share(40),
pre_shared_key(TBD), pre_shared_key(41),
key_share(TBD), early_data(42),
(65535) (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
skipping to change at page 48, line 8 skipping to change at page 48, line 23
suite negotiation. This is not recommended; it would be more suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS -- particularly since appropriate to define a new version of TLS -- particularly since
the TLS handshake algorithms have specific protection against the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the version rollback attacks based on the version number, and the
possibility of version rollback should be a significant possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
6.3.2.1. Signature Algorithms 6.3.2.1. Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in the server which signature algorithms may be used in digital
digital signatures. signatures.
Clients which offer one or more cipher suites which use certificate Clients which offer one or more cipher suites which use certificate
authentication (i.e., any non-PSK cipher suite) MUST send the authentication (i.e., any non-PSK cipher suite) MUST send the
"signature_algorithms" extension. If this extension is not provided "signature_algorithms" extension. If this extension is not provided
and no alternative cipher suite is available, the server MUST close and no alternative cipher suite is available, the server MUST close
the connection with a fatal "missing_extension" alert. (see the connection with a fatal "missing_extension" alert. (see
Section 8.2) Section 8.2)
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"supported_signature_algorithms" value: "supported_signature_algorithms" value:
enum { enum {
none(0), // RSASSA-PKCS-v1_5 algorithms.
sha1(2), rsa_pkcs1_sha1 (0x0201),
sha256(4), sha384(5), sha512(6), rsa_pkcs1_sha256 (0x0401),
(255) rsa_pkcs1_sha384 (0x0501),
} HashAlgorithm; rsa_pkcs1_sha512 (0x0601),
enum { // DSA algorithms (deprecated).
rsa(1), dsa_sha1 (0x0202),
dsa(2), dsa_sha256 (0x0402),
ecdsa(3), dsa_sha384 (0x0502),
rsapss(4), dsa_sha512 (0x0602),
eddsa(5),
(255)
} SignatureAlgorithm;
struct { // ECDSA algorithms.
HashAlgorithm hash; ecdsa_secp256r1_sha256 (0x0403),
SignatureAlgorithm signature; ecdsa_secp384r1_sha384 (0x0503),
} SignatureAndHashAlgorithm; ecdsa_secp521r1_sha512 (0x0603),
SignatureAndHashAlgorithm // RSASSA-PSS algorithms.
supported_signature_algorithms<2..2^16-2>; rsa_pss_sha256 (0x0700),
rsa_pss_sha384 (0x0701),
rsa_pss_sha512 (0x0702),
[[TODO: IANA considerations for new SignatureAlgorithm value]] // EdDSA algorithms.
ed25519 (0x0703),
ed448 (0x0704),
Each SignatureAndHashAlgorithm value lists a single hash/signature // Reserved Code Points.
pair that the client is willing to verify. The values are indicated private_use (0xFE00..0xFFFF),
in descending order of preference. (0xFFFF)
} SignatureScheme;
Note: Because not all signature algorithms and hash algorithms may be SignatureScheme supported_signature_algorithms<2..2^16-2>;
accepted by an implementation (e.g., ECDSA with SHA-256, but not SHA-
384), algorithms here are listed in pairs.
hash Note: This production is named "SignatureScheme" because there is
This field indicates the hash algorithms which may be used. The already a SignatureAlgorithm type in TLS 1.2. We use the term
values indicate support for unhashed data, SHA-1, SHA-256, SHA- "signature algorithm" throughout the text.
384, and SHA-512 [SHS], respectively. The "none" value is
provided for signature algorithms which do not require hashing
before signing, such as EdDSA. Previous versions of TLS supported
MD5, SHA-1, and SHA-224. These algorithms are now deprecated.
MD5 and SHA-224 MUST NOT be offered by TLS 1.3 implementations;
SHA-1 SHOULD NOT be offered. Clients MAY offer support for SHA-1
for backwards compatibility, either with TLS 1.2 servers or for
servers that have certification paths with signatures based on
SHA-1.
signature Each SignatureScheme value lists a single signature algorithm that
This field indicates the signature algorithm that may be used. the client is willing to verify. The values are indicated in
The values indicate RSASSA-PKCS1-v1_5 [RFC3447], DSA [DSS], ECDSA descending order of preference. Note that a signature algorithm
[ECDSA], RSASSA-PSS [RFC3447], and EdDSA [I-D.irtf-cfrg-eddsa] takes as input an arbitrary-length message, rather than a digest.
respectively. Because all RSA signatures used in signed TLS Algorithms which traditionally act on a digest should be defined in
handshake messages (see Section 4.8.1), as opposed to those in TLS to first hash the input with a specified hash function and then
certificates, are RSASSA-PSS, the "rsa" value refers solely to proceed as usual.
signatures which appear in certificates. The use of DSA and
anonymous is deprecated. Previous versions of TLS supported DSA. rsa_pkcs1_sha1, etc.
DSA is deprecated as of TLS 1.3 and SHOULD NOT be offered or
negotiated by any implementation. Indicates a signature algorithm using RSASSA-PKCS1-v1_5 [RFC3447]
with the corresponding hash algorithm as defined in [SHS]. These
values refer solely to signatures which appear in certificates
(see Section 6.3.4.1.1) and are not defined for use in signed TLS
handshake messages (see Section 4.8.1).
ecdsa_secp256r1_sha256, etc.
Indicates a signature algorithm using ECDSA [ECDSA], the
corresponding curve as defined in ANSI X9.62 [X962] and FIPS 186-4
[DSS], and the corresponding hash algorithm as defined in [SHS].
The signature is represented as a DER-encoded [X690] ECDSA-Sig-
Value structure.
rsa_pss_sha256, etc.
Indicates a signature algorithm using RSASSA-PSS [RFC3447] with
MGF1. The digest used in the mask generation function and the
digest being signed are both the corresponding hash algorithm as
defined in [SHS]. When used in signed TLS handshake messages (see
Section 4.8.1), the length of the salt MUST be equal to the length
of the digest output.
ed25519, ed448
Indicates a signature algorithm using EdDSA as defined in
[I-D.irtf-cfrg-eddsa] or its successors. Note that these
correspond to the "PureEdDSA" algorithms and not the "prehash"
variants.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite adds additional constraints on signature algorithms.
algorithms. Section 6.3.4.1.1 and Section 6.3.2.3 describe the Section 6.3.4.1.1 describes the appropriate rules.
appropriate rules.
Clients offering support for SHA-1 for backwards compatibility MUST rsa_pkcs1_sha1 and dsa_sha1 SHOULD NOT be offered. Clients offering
do so by listing those hash/signature pairs as the lowest priority these values for backwards compatibility MUST list them as the lowest
(listed after all other pairs in the supported_signature_algorithms priority (listed after all other algorithms in the
vector). TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate supported_signature_algorithms vector). TLS 1.3 servers MUST NOT
unless no valid certificate chain can be produced without it (see offer a SHA-1 signed certificate unless no valid certificate chain
Section 6.3.4.1.1). can be produced without it (see Section 6.3.4.1.1).
The signatures on certificates that are self-signed or certificates The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a that are trust anchors are not validated since they begin a
certification path (see [RFC5280], Section 3.2). A certificate that certification path (see [RFC5280], Section 3.2). A certificate that
begins a certification path MAY use a hash or signature algorithm begins a certification path MAY use a signature algorithm that is not
that is not advertised as being supported in the advertised as being supported in the "signature_algorithms"
"signature_algorithms" extension. extension.
Note: TLS 1.3 servers might receive TLS 1.2 ClientHellos which do not Note that TLS 1.2 defines this extension differently. TLS 1.3
contain this extension. If those servers are willing to negotiate implementations willing to negotiate TLS 1.2 MUST behave in
TLS 1.2, they MUST behave in accordance with the requirements of accordance with the requirements of [RFC5246] when negotiating that
[RFC5246] when negotiating that version. version. In particular:
- TLS 1.2 ClientHellos may omit this extension.
- In TLS 1.2, the extension contained hash/signature pairs. The
pairs are encoded in two octets, so SignatureScheme values have
been allocated to align with TLS 1.2's encoding. Some legacy
pairs are left unallocated. These algorithms are deprecated as of
TLS 1.3. They MUST NOT be offered or negotiated by any
implementation. In particular, MD5 [SLOTH] and SHA-224 MUST NOT
be used.
- ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/
signature pairs. However, the old semantics did not constrain the
signing curve.
6.3.2.2. Negotiated Groups 6.3.2.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most the named groups which the client supports, ordered from most
preferred to least preferred. preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups. See "elliptic_curves" and only contained elliptic curve groups. See
[RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. [RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. This extension was
also used to negotiate ECDSA curves. Signature algorithms are now
negotiated independently (see Section 6.3.2.1).
Clients which offer one or more (EC)DHE cipher suites MUST send at Clients which offer one or more (EC)DHE cipher suites MUST send at
least one supported NamedGroup value and servers MUST NOT negotiate least one supported NamedGroup value and servers MUST NOT negotiate
any of these cipher suites unless a supported value was provided. If any of these cipher suites unless a supported value was provided. If
this extension is not provided and no alternative cipher suite is this extension is not provided and no alternative cipher suite is
available, the server MUST close the connection with a fatal available, the server MUST close the connection with a fatal
"missing_extension" alert. (see Section 8.2) If the extension is "missing_extension" alert. (see Section 8.2) If the extension is
provided, but no compatible group is offered, the server MUST NOT provided, but no compatible group is offered, the server MUST NOT
negotiate a cipher suite of the relevant type. For instance, if a negotiate a cipher suite of the relevant type. For instance, if a
client supplies only ECDHE groups, the server MUST NOT negotiate client supplies only ECDHE groups, the server MUST NOT negotiate
finite field Diffie-Hellman. If no acceptable group can be selected finite field Diffie-Hellman. If no acceptable group can be selected
across all cipher suites, then the server MUST generate a fatal across all cipher suites, then the server MUST generate a fatal
"handshake_failure" alert. "handshake_failure" alert.
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"NamedGroupList" value: "NamedGroupList" value:
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups (ECDHE).
secp256r1 (23), secp384r1 (24), secp521r1 (25), secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519 (29), x448 (30),
// ECDH functions. // Finite Field Groups (DHE).
ecdh_x25519 (29), ecdh_x448 (30),
// Signature-only curves.
eddsa_ed25519 (31), eddsa_ed448 (32),
// Finite Field Groups.
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe6144 (259), ffdhe8192 (260), ffdhe6144 (259), ffdhe8192 (260),
// Reserved Code Points. // Reserved Code Points.
ffdhe_private_use (0x01FC..0x01FF), ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1>; NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
secp256r1, etc. secp256r1, etc.
Indicates support of the corresponding named curve. Note that Indicates support of the corresponding named curve. Note that
some curves are also recommended in ANSI X9.62 [X962] and FIPS some curves are also recommended in ANSI X9.62 [X962] and FIPS
186-4 [DSS]. Values 0xFE00 through 0xFEFF are reserved for 186-4 [DSS]. Others are recommended in [I-D.irtf-cfrg-curves].
private use. Values 0xFE00 through 0xFEFF are reserved for private use.
ecdh_x25519 and ecdh_x448
Indicates support of the corresponding ECDH functions X25519 and
X448.
eddsa_ed25519 and eddsa_ed448
Indicates support of the corresponding curve for signatures.
ffdhe2048, etc. ffdhe2048, etc.
Indicates support of the corresponding finite field group, defined Indicates support of the corresponding finite field group, defined
in [I-D.ietf-tls-negotiated-ff-dhe]. Values 0x01FC through 0x01FF in [I-D.ietf-tls-negotiated-ff-dhe]. Values 0x01FC through 0x01FF
are reserved for private use. are reserved for private use.
Items in named_group_list are ordered according to the client's Items in named_group_list are ordered according to the client's
preferences (most preferred choice first). preferences (most preferred choice first).
As an example, a client that only supports secp256r1 (aka NIST P-256; As an example, a client that only supports secp256r1 (aka NIST P-256;
value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018)
and prefers to use secp256r1 would include a TLS extension consisting and prefers to use secp256r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type ("supported_groups" extension): extension type ("supported_groups" extension):
00 0A 00 06 00 04 00 17 00 18 00 0A 00 06 00 04 00 17 00 18
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA or EdDSA key in its certificate,
and (ii) the ephemeral ECDH key in its "key_share" extension. The
server must consider the supported groups in both cases.
[[TODO: IANA Considerations.]] [[TODO: IANA Considerations.]]
6.3.2.3. Key Share 6.3.2.3. Key Share
The "key_share" extension contains the endpoint's cryptographic The "key_share" extension contains the endpoint's cryptographic
parameters for non-PSK key establishment methods (currently DHE or parameters for non-PSK key establishment methods (currently DHE or
ECDHE). ECDHE).
Clients which offer one or more (EC)DHE cipher suites MUST send this Clients which offer one or more (EC)DHE cipher suites MUST send this
extension and SHOULD send at least one supported KeyShareEntry value. extension and SHOULD send at least one supported KeyShareEntry value.
skipping to change at page 52, line 42 skipping to change at page 53, line 25
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
group group
The named group for the key being exchanged. Finite Field Diffie- The named group for the key being exchanged. Finite Field Diffie-
Hellman [DH] parameters are described in Section 6.3.2.3.1; Hellman [DH] parameters are described in Section 6.3.2.3.1;
Elliptic Curve Diffie-Hellman parameters are described in Elliptic Curve Diffie-Hellman parameters are described in
Section 6.3.2.3.2. Signature-only curves, currently eddsa_ed25519 Section 6.3.2.3.2.
(31) and eddsa_ed448 (32), MUST NOT be used for key exchange.
key_exchange key_exchange
Key exchange information. The contents of this field are Key exchange information. The contents of this field are
determined by the specified group and its corresponding determined by the specified group and its corresponding
definition. Endpoints MUST NOT send empty or otherwise invalid definition. Endpoints MUST NOT send empty or otherwise invalid
key_exchange values for any reason. key_exchange values for any reason.
The "extension_data" field of this extension contains a "KeyShare" The "extension_data" field of this extension contains a "KeyShare"
value: value:
skipping to change at page 54, line 26 skipping to change at page 55, line 6
ECDHE parameters for both clients and servers are encoded in the the ECDHE parameters for both clients and servers are encoded in the the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure. opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
The opaque value conveys the Elliptic Curve Diffie-Hellman public The opaque value conveys the Elliptic Curve Diffie-Hellman public
value (ecdh_Y) represented as a byte string ECPoint.point. value (ecdh_Y) represented as a byte string ECPoint.point.
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
point point
For secp256r1, secp384r1 and secp521r1, this is the byte string For secp256r1, secp384r1 and secp521r1, this is the byte string
representation of an elliptic curve point following the conversion representation of an elliptic curve point following the conversion
routine in Section 4.3.6 of ANSI X9.62 [X962]. For ecdh_x25519 routine in Section 4.3.6 of ANSI X9.62 [X962]. For x25519 and
and ecdh_x448, this is raw opaque octet-string representation of x448, this is raw opaque octet-string representation of point (in
point (in the format those functions use), 32 octets for the format those functions use), 32 octets for x25519 and 56
ecdh_x25519 and 56 octets for ecdh_x448. octets for x448.
Although X9.62 supports multiple point formats, any given curve MUST Although X9.62 supports multiple point formats, any given curve MUST
specify only a single point format. All curves currently specified specify only a single point format. All curves currently specified
in this document MUST only be used with the uncompressed point format in this document MUST only be used with the uncompressed point format
(the format for all ECDH functions is considered uncompressed). (the format for all ECDH functions is considered uncompressed).
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS
1.3 removes this feature in favor of a single point format for each 1.3 removes this feature in favor of a single point format for each
curve. curve.
skipping to change at page 57, line 43 skipping to change at page 58, line 23
group in its own "key_share" extension. group in its own "key_share" extension.
If any of these checks fail, the server MUST NOT respond with the If any of these checks fail, the server MUST NOT respond with the
extension and must discard all the remaining first flight data (thus extension and must discard all the remaining first flight data (thus
falling back to 1-RTT). If the client attempts a 0-RTT handshake but falling back to 1-RTT). If the client attempts a 0-RTT handshake but
the server rejects it, it will generally not have the 0-RTT record the server rejects it, it will generally not have the 0-RTT record
protection keys and will instead trial decrypt each record with the protection keys and will instead trial decrypt each record with the
1-RTT handshake keys until it finds one that decrypts properly, and 1-RTT handshake keys until it finds one that decrypts properly, and
then pick up the handshake from that point. then pick up the handshake from that point.
If the server choosed to accept the "early_data" extension, then it If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for MUST comply with the same error handling requirements specified for
all records when processing early data records. Specifically, all records when processing early data records. Specifically,
decryption failure of any 0-RTT record following an accepted decryption failure of any 0-RTT record following an accepted
"early_data" extension MUST produce a fatal "bad_record_mac" alert as "early_data" extension MUST produce a fatal "bad_record_mac" alert as
per Section 5.2.2. per Section 5.2.2.
[[TODO: How does the client behave if the indication is rejected.]] [[TODO: How does the client behave if the indication is rejected.]]
[[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the [[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the
the 0-RTT cryptographic transforms, including: the 0-RTT cryptographic transforms, including:
skipping to change at page 58, line 31 skipping to change at page 59, line 9
In order to allow the server to decrypt 0-RTT data, the client needs In order to allow the server to decrypt 0-RTT data, the client needs
to provide enough information to allow the server to decrypt the to provide enough information to allow the server to decrypt the
traffic without negotiation. This is accomplished by having the traffic without negotiation. This is accomplished by having the
client indicate the "cryptographic determining parameters" in its client indicate the "cryptographic determining parameters" in its
ClientHello, which are necessary to decrypt the client's packets ClientHello, which are necessary to decrypt the client's packets
(i.e., those present in the ServerHello). This includes the (i.e., those present in the ServerHello). This includes the
following values: following values:
- The cipher suite identifier. - The cipher suite identifier.
- If (EC)DHE is being used, the server's version of "key_share". - If (EC)DHE is being used, the server's version of the "key_share"
extension.
- If PSK is being used, the server's version of the "pre_shared_key" - If PSK is being used, the server's version of the "pre_shared_key"
(indicating the PSK the client is using). extension (indicating the PSK the client is using).
6.3.2.5.2. Replay Properties 6.3.2.5.2. Replay Properties
As noted in Section 6.2.2, TLS does not provide any inter-connection As noted in Section 6.2.2, TLS does not provide any inter-connection
mechanism for replay protection for data sent by the client in the mechanism for replay protection for data sent by the client in the
first flight. As a special case, implementations where the server first flight. As a special case, implementations where the server
configuration, is delivered out of band (as has been proposed for configuration, is delivered out of band (as has been proposed for
DTLS-SRTP [RFC5763]), MAY use a unique server configuration DTLS-SRTP [RFC5763]), MAY use a unique server configuration
identifier for each connection, thus preventing replay. identifier for each connection, thus preventing replay.
Implementations are responsible for ensuring uniqueness of the Implementations are responsible for ensuring uniqueness of the
skipping to change at page 60, line 14 skipping to change at page 60, line 33
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
opaque certificate_extension_oid<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>; opaque certificate_extension_values<0..2^16-1>;
} CertificateExtension; } CertificateExtension;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
SignatureAndHashAlgorithm SignatureScheme
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
CertificateExtension certificate_extensions<0..2^16-1>; CertificateExtension certificate_extensions<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_request_context certificate_request_context
An opaque string which identifies the certificate request and An opaque string which identifies the certificate request and
which will be echoed in the client's Certificate message. The which will be echoed in the client's Certificate message. The
certificate_request_context MUST be unique within the scope of certificate_request_context MUST be unique within the scope of
this connection (thus preventing replay of client this connection (thus preventing replay of client
CertificateVerify messages). CertificateVerify messages).
supported_signature_algorithms supported_signature_algorithms
A list of the hash/signature algorithm pairs that the server is A list of the signature algorithms that the server is able to
able to verify, listed in descending order of preference. Any verify, listed in descending order of preference. Any
certificates provided by the client MUST be signed using a hash/ certificates provided by the client MUST be signed using a
signature algorithm pair found in supported_signature_algorithms. signature algorithm found in supported_signature_algorithms.
certificate_authorities certificate_authorities
A list of the distinguished names [X501] of acceptable A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded [X690] format. certificate_authorities, represented in DER-encoded [X690] format.
These distinguished names may specify a desired distinguished name These distinguished names may specify a desired distinguished name
for a root CA or for a subordinate CA; thus, this message can be for a root CA or for a subordinate CA; thus, this message can be
used to describe known roots as well as a desired authorization used to describe known roots as well as a desired authorization
space. If the certificate_authorities list is empty, then the space. If the certificate_authorities list is empty, then the
client MAY send any certificate that meets the rest of the client MAY send any certificate that meets the rest of the
selection criteria in the CertificateRequest, unless there is some selection criteria in the CertificateRequest, unless there is some
skipping to change at page 62, line 52 skipping to change at page 63, line 17
certificate for future handshakes based on the CertificateRequest certificate for future handshakes based on the CertificateRequest
parameters supplied in this handshake. The server MUST NOT send parameters supplied in this handshake. The server MUST NOT send
either of these two options unless it also requested a certificate either of these two options unless it also requested a certificate
on this handshake. [[OPEN ISSUE: Should we relax this?]] on this handshake. [[OPEN ISSUE: Should we relax this?]]
extensions extensions
This field is a placeholder for future extensions to the This field is a placeholder for future extensions to the
ServerConfiguration format. ServerConfiguration format.
The semantics of this message are to establish a shared state between The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration" the client and server for use with the "early_data" extension with
extension with the key specified in key and with the handshake the key specified in "static_key_share" and with the handshake
parameters negotiated by this handshake. parameters negotiated by this handshake.
When the ServerConfiguration message is sent, the server MUST also When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus the "early_data" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by requiring a signature over the configuration before it can be used by
the client. Clients MUST NOT rely on the ServerConfiguration message the client. Clients MUST NOT rely on the ServerConfiguration message
until successfully receiving and processing the server's Certificate, until successfully receiving and processing the server's Certificate,
CertificateVerify, and Finished. If there is a failure in processing CertificateVerify, and Finished. If there is a failure in processing
those messages, the client MUST discard the ServerConfiguration. those messages, the client MUST discard the ServerConfiguration.
6.3.4. Authentication Messages 6.3.4. Authentication Messages
As discussed in Section 6.2, TLS uses a common set of messages for As discussed in Section 6.2, TLS uses a common set of messages for
authentication, key confirmation, and handshake integrity: authentication, key confirmation, and handshake integrity:
skipping to change at page 65, line 23 skipping to change at page 65, line 36
This message conveys the endpoint's certificate chain to the peer. This message conveys the endpoint's certificate chain to the peer.
The certificate MUST be appropriate for the negotiated cipher The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm and any negotiated extensions. suite's key exchange algorithm and any negotiated extensions.
Structure of this message: Structure of this message:
opaque ASN1Cert<1..2^24-1>; opaque ASN1Cert<1..2^24-1>;
struct { struct {
opaque certificate_request_context<0..255>; opaque certificate_request_context<0..2^8-1>;
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_request_context: certificate_request_context:
If this message is in response to a CertificateRequest, the value If this message is in response to a CertificateRequest, the value
if certificate_request_context in that message. Otherwise, in the of certificate_request_context in that message. Otherwise, in the
case of server authentication or client authentication in 0-RTT, case of server authentication or client authentication in 0-RTT,
this field SHALL be zero length. this field SHALL be zero length.
certificate_list certificate_list
This is a sequence (chain) of certificates. The sender's This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate MUST come first in the list. Each following
certificate SHOULD directly certify one preceding it. Because certificate SHOULD directly certify one preceding it. Because
certificate validation requires that trust anchors be distributed certificate validation requires that trust anchors be distributed
independently, a certificate that specifies a trust anchor MAY be independently, a certificate that specifies a trust anchor MAY be
omitted from the chain, provided that supported peers are known to omitted from the chain, provided that supported peers are known to
skipping to change at page 66, line 6 skipping to change at page 66, line 18
certificate to certify the one immediately preceding it, however some certificate to certify the one immediately preceding it, however some
implementations allowed some flexibility. Servers sometimes send implementations allowed some flexibility. Servers sometimes send
both a current and deprecated intermediate for transitional purposes, both a current and deprecated intermediate for transitional purposes,
and others are simply configured incorrectly, but these cases can and others are simply configured incorrectly, but these cases can
nonetheless be validated properly. For maximum compatibility, all nonetheless be validated properly. For maximum compatibility, all
implementations SHOULD be prepared to handle potentially extraneous implementations SHOULD be prepared to handle potentially extraneous
certificates and arbitrary orderings from any TLS version, with the certificates and arbitrary orderings from any TLS version, with the
exception of the end-entity certificate which MUST be first. exception of the end-entity certificate which MUST be first.
The server's certificate list MUST always be non-empty. A client The server's certificate list MUST always be non-empty. A client
will MAY send an empty certificate list if it does not have an will send an empty certificate list if it does not have an
appropriate certificate to send in response to the server's appropriate certificate to send in response to the server's
authentication request. authentication request.
6.3.4.1.1. Server Certificate Selection 6.3.4.1.1. Server Certificate Selection
The following rules apply to the certificates sent by the server: The following rules apply to the certificates sent by the server:
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
negotiated otherwise (e.g., [RFC5081]). negotiated otherwise (e.g., [RFC5081]).
skipping to change at page 66, line 31 skipping to change at page 66, line 43
+----------------------+---------------------------+ +----------------------+---------------------------+
| Key Exchange Alg. | Certificate Key Type | | Key Exchange Alg. | Certificate Key Type |
+----------------------+---------------------------+ +----------------------+---------------------------+
| DHE_RSA or ECDHE_RSA | RSA public key | | DHE_RSA or ECDHE_RSA | RSA public key |
| | | | | |
| ECDHE_ECDSA | ECDSA or EdDSA public key | | ECDHE_ECDSA | ECDSA or EdDSA public key |
+----------------------+---------------------------+ +----------------------+---------------------------+
- The certificate MUST allow the key to be used for signing (i.e., - The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme and hash algorithm pair indicated present) with a signature scheme indicated in the client's
in the client's "signature_algorithms" extension. "signature_algorithms" extension.
- An ECDSA or EdDSA public key MUST use a curve and point format
supported by the client, as described in [RFC4492].
- The "server_name" and "trusted_ca_keys" extensions [RFC6066] are - The "server_name" and "trusted_ca_keys" extensions [RFC6066] are
used to guide certificate selection. As servers MAY require the used to guide certificate selection. As servers MAY require the
presence of the "server_name" extension, clients SHOULD send this presence of the "server_name" extension, clients SHOULD send this
extension. extension.
All certificates provided by the server MUST be signed by a hash/ All certificates provided by the server MUST be signed by a signature
signature algorithm pair that appears in the "signature_algorithms" algorithm that appears in the "signature_algorithms" extension
extension provided by the client, if they are able to provide such a provided by the client, if they are able to provide such a chain (see
chain (see Section 6.3.2.1). Certificates that are self-signed or Section 6.3.2.1). Certificates that are self-signed or certificates
certificates that are expected to be trust anchors are not validated that are expected to be trust anchors are not validated as part of
as part of the chain and therefore MAY be signed with any algorithm. the chain and therefore MAY be signed with any algorithm.
If the server cannot produce a certificate chain that is signed only If the server cannot produce a certificate chain that is signed only
via the indicated supported pairs, then it SHOULD continue the via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the that may include algorithms that are not known to be supported by the
client. This fallback chain MAY use the deprecated SHA-1 hash client. This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by algorithm only if the "signature_algorithms" extension provided by
the client permits it. If the client cannot construct an acceptable the client permits it. If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the chain using the provided certificates and decides to abort the
handshake, then it MUST send an "unsupported_certificate" alert handshake, then it MUST send an "unsupported_certificate" alert
message and close the connection. message and close the connection.
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
skipping to change at page 69, line 4 skipping to change at page 69, line 14
appear immediately after the Certificate Message and immediately appear immediately after the Certificate Message and immediately
prior to the Finished message. prior to the Finished message.
Structure of this message: Structure of this message:
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque hashed_data[hash_length]; opaque hashed_data[hash_length];
}; };
} CertificateVerify; } CertificateVerify;
Where hashed_data is the hash output described in Section 6.3.4, Where hashed_data is the hash output described in Section 6.3.4,
namely Hash(Handshake Context + Certificate). namely Hash(Handshake Context + Certificate). For concreteness,
this means that the value that is signed is:
padding + context_string + 00 + hashed_data
The context string for a server signature is "TLS 1.3, server The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify". A hash of the handshake messages is signed CertificateVerify". A hash of the handshake messages is signed
rather than the messages themselves because the digitally-signed rather than the messages themselves because the digitally-signed
format requires padding and context bytes at the beginning of the format requires padding and context bytes at the beginning of the
input. Thus, by signing a digest of the messages, an input. Thus, by signing a digest of the messages, an
implementation need only maintain one running hash per hash type implementation need only maintain one running hash per hash type
for CertificateVerify, Finished and other messages. for CertificateVerify, Finished and other messages.
If sent by a server, the signature algorithm and hash algorithm If sent by a server, the signature algorithm MUST be one offered
MUST be a pair offered in the client's "signature_algorithms" in the client's "signature_algorithms" extension unless no valid
extension unless no valid certificate chain can be produced certificate chain can be produced without unsupported algorithms
without unsupported algorithms (see Section 6.3.2.1). Note that (see Section 6.3.2.1). Note that there is a possibility for
there is a possibility for inconsistencies here. For instance, inconsistencies here. For instance, the client might offer
the client might offer ECDHE_ECDSA key exchange but omit any ECDSA ECDHE_ECDSA key exchange but omit any ECDSA and EdDSA values from
and EdDSA pairs from its "signature_algorithms" extension. In its "signature_algorithms" extension. In order to negotiate
order to negotiate correctly, the server MUST check any candidate correctly, the server MUST check any candidate cipher suites
cipher suites against the "signature_algorithms" extension before against the "signature_algorithms" extension before selecting
selecting them. This is somewhat inelegant but is a compromise them. This is somewhat inelegant but is a compromise designed to
designed to minimize changes to the original cipher suite design. minimize changes to the original cipher suite design.
If sent by a client, the hash and signature algorithms used in the If sent by a client, the signature algorithm used in the signature
signature MUST be one of those present in the MUST be one of those present in the supported_signature_algorithms
supported_signature_algorithms field of the CertificateRequest field of the CertificateRequest message.
message.
In addition, the hash and signature algorithms MUST be compatible In addition, the signature algorithm MUST be compatible with the
with the key in the sender's end-entity certificate. RSA keys MAY key in the sender's end-entity certificate. RSA signatures MUST
be used with any permitted hash algorithm, subject to restrictions use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS-
in the certificate, if any. RSA signatures MUST be based on v1_5 algorithms appear in "signature_algorithms". SHA-1 MUST NOT
RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in be used in any signatures in CertificateVerify. (Note that
"signature_algorithms". SHA-1 MUST NOT be used in any signatures rsa_pkcs1_sha1 and dsa_sha1, the only defined SHA-1 signature
in CertificateVerify, regardless of whether SHA-1 appears in algorithms, are undefined for CertificateVerify signatures.)
"signature_algorithms".
Note: when used with non-certificate-based handshakes (e.g., PSK), Note: When used with non-certificate-based handshakes (e.g., PSK),
the client's signature does not cover the server's certificate the client's signature does not cover the server's certificate
directly, although it does cover the server's Finished message, which directly, although it does cover the server's Finished message, which
transitively includes the server's certificate when the PSK derives transitively includes the server's certificate when the PSK derives
from a certificate-authenticated handshake. [PSK-FINISHED] describes from a certificate-authenticated handshake. [PSK-FINISHED] describes
a concrete attack on this mode if the Finished is omitted from the a concrete attack on this mode if the Finished is omitted from the
signature. It is unsafe to use certificate-based client signature. It is unsafe to use certificate-based client
authentication when the client might potentially share the same PSK/ authentication when the client might potentially share the same PSK/
key-id pair with two different endpoints. In order to ensure this, key-id pair with two different endpoints. In order to ensure this,
implementations MUST NOT mix certificate-based client authentication implementations MUST NOT mix certificate-based client authentication
with pure PSK modes (i.e., those where the PSK was not derived from a with pure PSK modes (i.e., those where the PSK was not derived from a
skipping to change at page 71, line 20 skipping to change at page 71, line 33
and are not included in the hash computations. and are not included in the hash computations.
6.3.5. Post-Handshake Messages 6.3.5. Post-Handshake Messages
TLS also allows other messages to be sent after the main handshake. TLS also allows other messages to be sent after the main handshake.
These message use a handshake content type and are encrypted under These message use a handshake content type and are encrypted under
the application traffic key. the application traffic key.
6.3.5.1. New Session Ticket Message 6.3.5.1. New Session Ticket Message
After the server has received the client Finished message, it MAY At any time after the server has received the client Finished
send a NewSessionTicket message. This message creates a pre-shared message, it MAY send a NewSessionTicket message. This message
key (PSK) binding between the resumption master secret and the ticket creates a pre-shared key (PSK) binding between the resumption master
label. The client MAY use this PSK for future handshakes by secret and the ticket label. The client MAY use this PSK for future
including it in the "pre_shared_key" extension in its ClientHello handshakes by including it in the "pre_shared_key" extension in its
(Section 6.3.2.4) and supplying a suitable PSK cipher suite. ClientHello (Section 6.3.2.4) and supplying a suitable PSK cipher
suite. Servers may send multiple tickets on a single connection, for
instance after post-handshake authentication.
struct { struct {
uint32 ticket_lifetime_hint; uint32 ticket_lifetime;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} NewSessionTicket; } NewSessionTicket;
ticket_lifetime_hint ticket_lifetime
Indicates the lifetime in seconds as a 32-bit unsigned integer in Indicates the lifetime in seconds as a 32-bit unsigned integer in
network byte order from the time of ticket issuance. A value of network byte order from the time of ticket issuance. Servers MUST
zero is reserved to indicate that the lifetime of the ticket is NOT use any value more than 604800 seconds (7 days). The value of
unspecified. zero indicates that the ticket should be discarded immediately.
Clients MUST NOT cache session tickets for longer than 7 days,
regardless of the ticket_lifetime. It MAY delete the ticket
earlier based on local policy. A server MAY treat a ticket as
valid for a shorter period of time than what is stated in the
ticket_lifetime.
ticket ticket
The value of the ticket to be used as the PSK identifier. The value of the ticket to be used as the PSK identifier.
The ticket lifetime hint is informative only. A client SHOULD delete
the ticket and associated state when the time expires. It MAY delete
the ticket earlier based on local policy. A server MAY treat a
ticket as valid for a shorter or longer period of time than what is
stated in the ticket_lifetime_hint.
The ticket itself is an opaque label. It MAY either be a database The ticket itself is an opaque label. It MAY either be a database
lookup key or a self-encrypted and self-authenticated value. lookup key or a self-encrypted and self-authenticated value.
Section 4 of [RFC5077] describes a recommended ticket construction Section 4 of [RFC5077] describes a recommended ticket construction
mechanism. mechanism.
[[TODO: Should we require that tickets be bound to the existing [[TODO: Should we require that tickets be bound to the existing
symmetric cipher suite. See the TODO above about early_data and symmetric cipher suite. See the TODO above about early_data and
PSK.??] PSK.??]
6.3.5.2. Post-Handshake Authentication 6.3.5.2. Post-Handshake Authentication
skipping to change at page 73, line 12 skipping to change at page 73, line 24
and they cross in flight, this only results in an update of one and they cross in flight, this only results in an update of one
generation; when each side receives the other side's update it just generation; when each side receives the other side's update it just
updates its receive keys and notes that the generations match and updates its receive keys and notes that the generations match and
thus no send update is needed. thus no send update is needed.
Note that the side which sends its KeyUpdate first needs to retain Note that the side which sends its KeyUpdate first needs to retain
the traffic keys (though not the traffic secret) for the previous the traffic keys (though not the traffic secret) for the previous
generation of keys until it receives the KeyUpdate from the other generation of keys until it receives the KeyUpdate from the other
side. side.
Both sender and receiver must encrypt their KeyUpdate messages with
the old keys. Additionally, both sides MUST enforce that a KeyUpdate
with the old key is received before accepting any messages encrypted
with the new key. Failure to do so may allow message truncation
attacks.
7. Cryptographic Computations 7. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, key the client and server random values. The authentication, key
exchange, and record protection algorithms are determined by the exchange, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello cipher_suite selected by the server and revealed in the ServerHello
message. The random values are exchanged in the hello messages. All message. The random values are exchanged in the hello messages. All
that remains is to calculate the key schedule. that remains is to calculate the key schedule.
skipping to change at page 74, line 51 skipping to change at page 75, line 20
handshake_hash, L) handshake_hash, L)
Where handshake_hash includes all messages up through the Where handshake_hash includes all messages up through the
server CertificateVerify message, but not including any server CertificateVerify message, but not including any
0-RTT handshake messages (the server's Finished is not 0-RTT handshake messages (the server's Finished is not
included because the master_secret is need to compute included because the master_secret is need to compute
the finished key). [[OPEN ISSUE: Should we be including the finished key). [[OPEN ISSUE: Should we be including
0-RTT handshake messages here and below?. 0-RTT handshake messages here and below?.
https://github.com/tlswg/tls13-spec/issues/351 https://github.com/tlswg/tls13-spec/issues/351
]] At this point, ]] At this point,
SS, ES, xSS, xES, mSS, and mSS SHOULD be securely deleted, SS, ES, xSS, xES, mSS, and mES SHOULD be securely deleted,
along with any ephemeral (EC)DH secrets. along with any ephemeral (EC)DH secrets.
7. resumption_secret = HKDF-Expand-Label(master_secret, 7. resumption_secret = HKDF-Expand-Label(master_secret,
"resumption master secret" "resumption master secret"
handshake_hash, L) handshake_hash, L)
8. exporter_secret = HKDF-Expand-Label(master_secret, 8. exporter_secret = HKDF-Expand-Label(master_secret,
"exporter master secret", "exporter master secret",
handshake_hash, L) handshake_hash, L)
Where handshake_hash contains the entire handshake up to Where handshake_hash contains the entire handshake up to
and including the client's Finished, but not including and including the client's Finished, but not including
any 0-RTT handshake messages or post-handshake messages. any 0-RTT handshake messages or post-handshake messages.
AT this point master_secret SHOULD be securely deleted. AT this point master_secret SHOULD be securely deleted.
The traffic keys are computed from xSS, xES, and the traffic_secret The traffic keys are computed from xSS, xES, and the traffic_secret
as described in Section 7.3 below. The traffic_secret may be updated as described in Section 7.3 below. The traffic_secret may be updated
throughout the connection as described in Section 7.2. throughout the connection as described in Section 7.2.
Note: although the steps above are phrased as individual HKDF-Extract Note: Although the steps above are phrased as individual HKDF-Extract
and HKDF-Expand operations, because each HKDF-Expand operation is and HKDF-Expand operations, because each HKDF-Expand operation is
paired with an HKDF-Extract, it is possible to implement this key paired with an HKDF-Extract, it is possible to implement this key
schedule with a black-box HKDF API, albeit at some loss of efficiency schedule with a black-box HKDF API, albeit at some loss of efficiency
as some HKDF-Extract operations will be repeated. as some HKDF-Extract operations will be repeated.
7.2. Updating Traffic Keys and IVs 7.2. Updating Traffic Keys and IVs
Once the handshake is complete, it is possible for either side to Once the handshake is complete, it is possible for either side to
update its sending traffic keys using the KeyUpdate handshake message update its sending traffic keys using the KeyUpdate handshake message
Section 6.3.5.3. The next generation of traffic keys is computed by Section 6.3.5.3. The next generation of traffic keys is computed by
skipping to change at page 76, line 32 skipping to change at page 77, line 6
key = HKDF-Expand-Label(Secret, key = HKDF-Expand-Label(Secret,
phase + ", " + purpose, phase + ", " + purpose,
handshake_context, handshake_context,
key_length) key_length)
The following table describes the inputs to the key calculation for The following table describes the inputs to the key calculation for
each class of traffic keys: each class of traffic keys:
+-------------+---------+-----------------+-------------------------+ +-------------+---------+-----------------+-------------------------+
| Record Type | Secret | Label | Handshake Context | | Record Type | Secret | Phase | Handshake Context |
+-------------+---------+-----------------+-------------------------+ +-------------+---------+-----------------+-------------------------+
| 0-RTT | xSS | "early | ClientHello + | | 0-RTT | xSS | "early | ClientHello + |
| Handshake | | handshake key | ServerConfiguration + | | Handshake | | handshake key | ServerConfiguration + |
| | | expansion" | Server Certificate | | | | expansion" | Server Certificate |
| | | | | | | | | |
| 0-RTT | xSS | "early | ClientHello + | | 0-RTT | xSS | "early | ClientHello + |
| Application | | application | ServerConfiguration + | | Application | | application | ServerConfiguration + |
| | | data key | Server Certificate | | | | data key | Server Certificate |
| | | expansion" | | | | | expansion" | |
| | | | | | | | | |
skipping to change at page 77, line 12 skipping to change at page 77, line 35
The following table indicates the purpose values for each type of The following table indicates the purpose values for each type of
key: key:
+------------------+--------------------+ +------------------+--------------------+
| Key Type | Purpose | | Key Type | Purpose |
+------------------+--------------------+ +------------------+--------------------+
| Client Write Key | "client write key" | | Client Write Key | "client write key" |
| | | | | |
| Server Write Key | "server write key" | | Server Write Key | "server write key" |
| | | | | |
| Client Write IV | "client write IV" | | Client Write IV | "client write iv" |
| | | | | |
| Server Write IV | "server write IV" | | Server Write IV | "server write iv" |
+------------------+--------------------+ +------------------+--------------------+
All the traffic keying material is recomputed whenever the underlying All the traffic keying material is recomputed whenever the underlying
Secret changes (e.g., when changing from the handshake to application Secret changes (e.g., when changing from the handshake to application
data keys or upon a key update). data keys or upon a key update).
7.3.1. The Handshake Hash 7.3.1. The Handshake Hash
The handshake hash is defined as the hash of all handshake messages The handshake hash ("handshake_hash") is defined as the hash (using
sent or received, starting at ClientHello up to the present time, the Hash algorithm for the handshake) of all handshake messages sent
with the exception of the client's 0-RTT authentication messages or received, starting at ClientHello up to the present time, with the
(Certificate, CertificateVerify, and Finished) including the type and exception of the client's 0-RTT authentication messages (Certificate,
length fields of the handshake messages. This is the concatenation CertificateVerify, and Finished) including the type and length fields
the exchanged Handshake structures in plaintext form (even if they of the handshake messages. This is the concatenation of the
were encrypted on the wire). [[OPEN ISSUE: See exchanged Handshake structures in plaintext form (even if they were
https://github.com/tlswg/tls13-spec/issues/351 for the question of encrypted on the wire). [[OPEN ISSUE: See https://github.com/tlswg/
whether the 0-RTT handshake messages are hashed.]] tls13-spec/issues/351 for the question of whether the 0-RTT handshake
messages are hashed.]]
7.3.2. Diffie-Hellman 7.3.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the shared secret, and is used in the negotiated key (Z) is used as the shared secret, and is used in the
key schedule as specified above. Leading bytes of Z that contain all key schedule as specified above. Leading bytes of Z that contain all
zero bits are stripped before it is used as the input to HKDF. zero bits are stripped before it is used as the input to HKDF.
7.3.3. Elliptic Curve Diffie-Hellman 7.3.3. Elliptic Curve Diffie-Hellman
skipping to change at page 78, line 22 skipping to change at page 78, line 45
- The public key to put into ECPoint.point structure is the result - The public key to put into ECPoint.point structure is the result
of applying the ECDH function to the secret key of appropriate of applying the ECDH function to the secret key of appropriate
length (into scalar input) and the standard public basepoint (into length (into scalar input) and the standard public basepoint (into
u-coordinate point input). u-coordinate point input).
- The ECDH shared secret is the result of applying ECDH function to - The ECDH shared secret is the result of applying ECDH function to
the secret key (into scalar input) and the peer's public key (into the secret key (into scalar input) and the peer's public key (into
u-coordinate point input). The output is used raw, with no u-coordinate point input). The output is used raw, with no
processing. processing.
For X25519 and X448, see [I-D.irtf-cfrg-curves]. For X25519 and X448, see [RFC7748].
7.3.4. Exporters
[RFC5705] defines keying material exporters for TLS in terms of the
TLS PRF. This document replaces the PRF with HKDF, thus requiring a
new construction. The exporter interface remains the same, however
the value is computed as:
HKDF-Expand-Label(HKDF-Extract(0, exporter_secret),
label, context_value, length)
Note: the inner HKDF-Extract is strictly unnecessary, but it
maintains the invariant that HKDF Extract and Expand calls are
paired.
8. Mandatory Algorithms 8. Mandatory Algorithms
8.1. MTI Cipher Suites 8.1. MTI Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
cipher suites: cipher suites:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
These cipher suites MUST support both digital signatures and key These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key exchange exchange with secp256r1 (NIST P-256) and SHOULD support key exchange
with X25519 [I-D.irtf-cfrg-curves]. with X25519 [RFC7748].
A TLS-compliant application SHOULD implement the following cipher A TLS-compliant application SHOULD implement the following cipher
suites: suites:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
8.2. MTI Extensions 8.2. MTI Extensions
skipping to change at page 80, line 12 skipping to change at page 81, line 7
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices B, C, and D. Appendices B, C, and D.
11. IANA Considerations 11. IANA Considerations
[[TODO: Rename "RSA" in TLS SignatureAlgorithm Registry to RSASSA-
PKCS1-v1_5 ]]
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 has updated these to reference this document. The
registries and their allocation policies are below: 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 [RFC2434]. 0-254 (decimal) are assigned via Specification Required [RFC2434].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
Use [RFC2434]. IANA [SHALL add/has added] a "Recommended" column Use [RFC2434]. IANA [SHALL add/has added] a "Recommended" column
to the cipher suite registry. All cipher suites listed in to the cipher suite registry. All cipher suites listed in
Appendix A.4 are marked as "Yes". All other cipher suites are Appendix A.4 are marked as "Yes". All other cipher suites are
skipping to change at page 81, line 18 skipping to change at page 82, line 9
they shall be in the ServerHello. "Encrypted", indicating that they shall be in the ServerHello. "Encrypted", indicating that
they shall be in the EncryptedExtensions block, and "No" they shall be in the EncryptedExtensions block, and "No"
indicating that they are not used in TLS 1.3. This column [shall indicating that they are not used in TLS 1.3. This column [shall
be/has been] initially populated with the values in this document. be/has been] initially populated with the values in this document.
IANA [shall update/has updated] this registry to add a IANA [shall update/has updated] this registry to add a
"Recommended" column. IANA [shall/has] initially populated this "Recommended" column. IANA [shall/has] initially populated this
column with the values in the table below. This table has been column with the values in the table below. This table has been
generated by marking Standards Track RFCs as "Yes" and all others generated by marking Standards Track RFCs as "Yes" and all others
as "No". as "No".
+-------------------------------------------+------------+----------+ +-----------------------------------------+-------------+-----------+
| Extension | Recommende | TLS 1.3 | | Extension | Recommended | TLS 1.3 |
| | d | | +-----------------------------------------+-------------+-----------+
+-------------------------------------------+------------+----------+ | server_name [RFC6066] | Yes | Encrypted |
| server_name [RFC6066] | Yes | Encrypte | | | | |
| | | d | | max_fragment_length [RFC6066] | Yes | Encrypted |
| | | | | | | |
| max_fragment_length [RFC6066] | Yes | Encrypte | | client_certificate_url [RFC6066] | Yes | Encrypted |
| | | d | | | | |
| | | | | trusted_ca_keys [RFC6066] | Yes | Encrypted |
| client_certificate_url [RFC6066] | Yes | Encrypte | | | | |
| | | d | | truncated_hmac [RFC6066] | Yes | No |
| | | | | | | |
| trusted_ca_keys [RFC6066] | Yes | Encrypte | | status_request [RFC6066] | Yes | No |
| | | d | | | | |
| | | | | user_mapping [RFC4681] | Yes | Encrypted |
| truncated_hmac [RFC6066] | Yes | No | | | | |
| | | | | client_authz [RFC5878] | No | Encrypted |
| status_request [RFC6066] | Yes | No | | | | |
| | | | | server_authz [RFC5878] | No | Encrypted |
| user_mapping [RFC4681] | Yes | Encrypte | | | | |
| | | d | | cert_type [RFC6091] | Yes | Encrypted |
| | | | | | | |
| client_authz [RFC5878] | No | Encrypte | | supported_groups [RFC-ietf-tls- | Yes | Client |
| | | d | | negotiated-ff-dhe] | | |
| | | | | | | |
| server_authz [RFC5878] | No | Encrypte | | ec_point_formats [RFC4492] | Yes | No |
| | | d | | | | |
| | | | | srp [RFC5054] | No | No |
| cert_type [RFC6091] | Yes | Encrypte | | | | |
| | | d | | signature_algorithms [RFC5246] | Yes | Client |
| | | | | | | |
| supported_groups [RFC-ietf-tls- | Yes | Client | | use_srtp [RFC5764] | Yes | Encrypted |
| negotiated-ff-dhe] | | | | | | |
| | | | | heartbeat [RFC6520] | Yes | Encrypted |
| ec_point_formats [RFC4492] | Yes | No | | | | |
| | | | | application_layer_protocol_negotiation | Yes | Encrypted |
| srp [RFC5054] | No | No | | [RFC7301] | | |
| | | | | | | |
| signature_algorithms [RFC5246] | Yes | Client | | status_request_v2 [RFC6961] | Yes | Encrypted |
| | | | | | | |
| use_srtp [RFC5764] | Yes | Encrypte | | signed_certificate_timestamp [RFC6962] | No | Encrypted |
| | | d | | | | |
| | | | | client_certificate_type [RFC7250] | Yes | Encrypted |
| heartbeat [RFC6520] | Yes | Encrypte | | | | |
| | | d | | server_certificate_type [RFC7250] | Yes | Encrypted |
| | | | | | | |
| application_layer_protocol_negotiation[RF | Yes | Encrypte | | padding [RFC7685] | Yes | Client |
| C7301] | | d | | | | |
| | | | | encrypt_then_mac [RFC7366] | Yes | No |
| status_request_v2 [RFC6961] | Yes | Encrypte | | | | |
| | | d | | extended_master_secret [RFC7627] | Yes | No |
| | | | | | | |
| signed_certificate_timestamp [RFC6962] | No | Encrypte | | SessionTicket TLS [RFC4507] | Yes | No |
| | | d | | | | |
| | | | | renegotiation_info [RFC5746] | Yes | No |
| client_certificate_type [RFC7250] | Yes | Encrypte | | | | |
| | | d | | key_share [[this document]] | Yes | Clear |
| | | | | | | |
| server_certificate_type [RFC7250] | Yes | Encrypte | | pre_shared_key [[this document]] | Yes | Clear |
| | | d | | | | |
| | | | | early_data [[this document]] | Yes | Clear |
| padding [RFC7685] | Yes | Client | +-----------------------------------------+-------------+-----------+
| | | |
| encrypt_then_mac [RFC7366] | Yes | No |
| | | |
| extended_master_secret [RFC7627] | Yes | No |
| | | |
| SessionTicket TLS [RFC4507] | Yes | No |
| | | |
| renegotiation_info [RFC5746] | Yes | No |
| | | |
| key_share [[this document]] | Yes | Clear |
| | | |
| pre_shared_key [[this document]] | Yes | Clear |
| | | |
| early_data [[this document]] | Yes | Clear |
+-------------------------------------------+------------+----------+
This document reuses two registries defined in [RFC5246].
- TLS SignatureAlgorithm Registry: The registry has been initially
populated with the values described in Section 6.3.2.1. Future
values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434].
- TLS HashAlgorithm Registry: The registry has been initially In addition, this document defines two new registries to be
populated with the values described in Section 6.3.2.1. Future maintained by IANA
values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434].
In addition, this document defines a new registry to be maintained by - TLS SignatureScheme Registry: Values with the first byte in the
IANA. range 0-254 (decimal) are assigned via Specification Required
[RFC2434]. Values with the first byte 255 (decimal) are reserved
for Private Use [RFC2434]. This registry SHALL have a
"Recommended" column. The registry [shall be/ has been] initially
populated with the values described in Section 6.3.2.1. The
following values SHALL be marked as "Recommended":
ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256,
rsa_pss_sha384, rsa_pss_sha512, ed25519.
- TLS ConfigurationExtensionType Registry: Values with the first - TLS ConfigurationExtensionType Registry: Values with the first
byte in the range 0-254 (decimal) are assigned via Specification byte in the range 0-254 (decimal) are assigned via Specification
Required [RFC2434]. Values with the first byte 255 (decimal) are Required [RFC2434]. Values with the first byte 255 (decimal) are
reserved for Private Use [RFC2434]. This registry SHALL have a reserved for Private Use [RFC2434]. This registry SHALL have a
"Recommended" column. The registry [shall be/ has been] initially "Recommended" column. The registry [shall be/ has been] initially
populated with the values described in Section 6.3.3.3, with all populated with the values described in Section 6.3.3.3, with all
values marked with "Recommended" value "Yes". values marked with "Recommended" value "Yes".
12. References 12. References
skipping to change at page 84, line 7 skipping to change at page 84, line 28
ietf-tls-chacha20-poly1305-04 (work in progress), December ietf-tls-chacha20-poly1305-04 (work in progress), December
2015. 2015.
[I-D.irtf-cfrg-curves] [I-D.irtf-cfrg-curves]
Langley, A. and M. Hamburg, "Elliptic Curves for Langley, A. and M. Hamburg, "Elliptic Curves for
Security", draft-irtf-cfrg-curves-11 (work in progress), Security", draft-irtf-cfrg-curves-11 (work in progress),
October 2015. October 2015.
[I-D.irtf-cfrg-eddsa] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-01 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-04
(work in progress), December 2015. (work in progress), March 2016.
[I-D.mattsson-tls-ecdhe-psk-aead]
Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for Transport Layer Security (TLS)",
draft-mattsson-tls-ecdhe-psk-aead-03 (work in progress),
December 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 84, line 46 skipping to change at page 85, line 26
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008, DOI 10.17487/RFC5288, August 2008,
<http://www.rfc-editor.org/info/rfc5288>. <http://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
DOI 10.17487/RFC5289, August 2008, DOI 10.17487/RFC5289, August 2008,
<http://www.rfc-editor.org/info/rfc5289>. <http://www.rfc-editor.org/info/rfc5289>.
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-
256/384 and AES Galois Counter Mode", RFC 5487,
DOI 10.17487/RFC5487, March 2009,
<http://www.rfc-editor.org/info/rfc5487>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>. <http://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
skipping to change at page 85, line 30 skipping to change at page 86, line 20
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<http://www.rfc-editor.org/info/rfc6655>. <http://www.rfc-editor.org/info/rfc6655>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<http://www.rfc-editor.org/info/rfc7251>. <http://www.rfc-editor.org/info/rfc7251>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
[SHS] National Institute of Standards and Technology, U.S. [SHS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", NIST FIPS Department of Commerce, "Secure Hash Standard", NIST FIPS
PUB 180-4, March 2012. PUB 180-4, March 2012.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
skipping to change at page 90, line 14 skipping to change at page 91, line 5
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello
Padding Extension", RFC 7685, DOI 10.17487/RFC7685, Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
October 2015, <http://www.rfc-editor.org/info/rfc7685>. October 2015, <http://www.rfc-editor.org/info/rfc7685>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM v. 21, n. 2, pp. Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
120-126., February 1978. 120-126., February 1978.
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security Symposium (NDSS
2016) , 2016.
[SSL2] Netscape Communications Corp., "The SSL Protocol", [SSL2] Netscape Communications Corp., "The SSL Protocol",
February 1995. February 1995.
[SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0
Protocol", November 1996. Protocol", November 1996.
[TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are
practical", USENIX Security Symposium, 2003. practical", USENIX Security Symposium, 2003.
[X501] "Information Technology - Open Systems Interconnection - [X501] "Information Technology - Open Systems Interconnection -
skipping to change at page 93, line 30 skipping to change at page 94, line 30
server_configuration(17), server_configuration(17),
finished(20), finished(20),
key_update(24), key_update(24),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_configuration:ServerConfiguration; case server_configuration: ServerConfiguration;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case session_ticket: NewSessionTicket; case session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
} body; } body;
} Handshake; } Handshake;
A.3.1. Key Exchange Messages A.3.1. Key Exchange Messages
struct { struct {
opaque random_bytes[32]; opaque random_bytes[32];
} Random; } Random;
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
skipping to change at page 94, line 16 skipping to change at page 95, line 16
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { Extension extensions<0..2^16-1>;
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello; } ServerHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
supported_groups(10), supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), key_share(40),
pre_shared_key(TBD), pre_shared_key(41),
key_share(TBD), early_data(42),
(65535) (65535)
} ExtensionType; } ExtensionType;
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
struct { struct {
select (role) { select (role) {
skipping to change at page 96, line 5 skipping to change at page 97, line 5
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
opaque context<0..255>; opaque context<0..255>;
case server: case server:
struct {}; struct {};
} }
} EarlyDataIndication; } EarlyDataIndication;
A.3.1.1. Signature Algorithm Extension A.3.1.1. Signature Algorithm Extension
enum { enum {
none(0), // RSASSA-PKCS-v1_5 algorithms.
md5_RESERVED(1), rsa_pkcs1_sha1 (0x0201),
sha1(2), rsa_pkcs1_sha256 (0x0401),
sha224_RESERVED(3), rsa_pkcs1_sha384 (0x0501),
sha256(4), sha384(5), sha512(6), rsa_pkcs1_sha512 (0x0601),
(255)
} HashAlgorithm;
enum { // DSA algorithms (deprecated).
anonymous_RESERVED(0), dsa_sha1 (0x0202),
rsa(1), dsa_sha256 (0x0402),
dsa(2), dsa_sha384 (0x0502),
ecdsa(3), dsa_sha512 (0x0602),
rsapss(4),
eddsa(5),
(255)
} SignatureAlgorithm;
struct { // ECDSA algorithms.
HashAlgorithm hash; ecdsa_secp256r1_sha256 (0x0403),
SignatureAlgorithm signature; ecdsa_secp384r1_sha384 (0x0503),
} SignatureAndHashAlgorithm; ecdsa_secp521r1_sha512 (0x0603),
SignatureAndHashAlgorithm // RSASSA-PSS algorithms.
supported_signature_algorithms<2..2^16-2>; rsa_pss_sha256 (0x0700),
rsa_pss_sha384 (0x0701),
rsa_pss_sha512 (0x0702),
// EdDSA algorithms.
ed25519 (0x0703),
ed448 (0x0704),
// Reserved Code Points.
obsolete_RESERVED (0x0000..0x0200),
obsolete_RESERVED (0x0203..0x0400),
obsolete_RESERVED (0x0404..0x0500),
obsolete_RESERVED (0x0504..0x0600),
obsolete_RESERVED (0x0604..0x06FF),
private_use (0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
SignatureScheme supported_signature_algorithms<2..2^16-2>;
A.3.1.2. Named Group Extension A.3.1.2. Named Group Extension
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups (ECDHE).
obsolete_RESERVED (1..22), obsolete_RESERVED (1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25), secp256r1 (23), secp384r1 (24), secp521r1 (25),
obsolete_RESERVED (26..28),
x25519 (29), x448 (30),
// ECDH functions. // Finite Field Groups (DHE).
ecdh_x25519 (29), ecdh_x448 (30),
// Signature-only curves.
eddsa_ed25519 (31), eddsa_ed448 (32),
// Finite Field Groups.
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe6144 (259), ffdhe8192 (260), ffdhe6144 (259), ffdhe8192 (260),
// Reserved Code Points. // Reserved Code Points.
ffdhe_private_use (0x01FC..0x01FF), ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
obsolete_RESERVED (0xFF01..0xFF02), obsolete_RESERVED (0xFF01..0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
skipping to change at page 98, line 20 skipping to change at page 99, line 17
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
opaque certificate_extension_oid<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>; opaque certificate_extension_values<0..2^16-1>;
} CertificateExtension; } CertificateExtension;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
SignatureAndHashAlgorithm SignatureScheme
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
CertificateExtension certificate_extensions<0..2^16-1>; CertificateExtension certificate_extensions<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
enum { (65535) } ConfigurationExtensionType; enum { (65535) } ConfigurationExtensionType;
enum { client_authentication(1), early_data(2), enum { client_authentication(1), early_data(2),
client_authentication_and_data(3), (255) } EarlyDataType; client_authentication_and_data(3), (255) } EarlyDataType;
skipping to change at page 99, line 7 skipping to change at page 100, line 7
uint32 expiration_date; uint32 expiration_date;
KeyShareEntry static_key_share; KeyShareEntry static_key_share;
EarlyDataType early_data_type; EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>; ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration; } ServerConfiguration;
A.3.3. Authentication Messages A.3.3. Authentication Messages
opaque ASN1Cert<1..2^24-1>; opaque ASN1Cert<1..2^24-1>;
struct { struct {
opaque certificate_request_context<0..255>; opaque certificate_request_context<0..2^8-1>;
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque hashed_data[hash_length]; opaque hashed_data[hash_length];
}; };
} CertificateVerify; } CertificateVerify;
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.3.4. Ticket Establishment A.3.4. Ticket Establishment
struct { struct {
uint32 ticket_lifetime_hint; uint32 ticket_lifetime;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} NewSessionTicket; } NewSessionTicket;
A.4. Cipher Suites A.4. Cipher Suites
A cipher suite defines a cipher specification supported in TLS and A cipher suite defines a cipher specification supported in TLS and
negotiated via hello messages in the TLS handshake. Cipher suite negotiated via hello messages in the TLS handshake. Cipher suite
names follow a general naming convention composed of a series of names follow a general naming convention composed of a series of
component algorithm names separated by underscores: component algorithm names separated by underscores:
CipherSuite TLS_KEA_SIGN_WITH_CIPHER_HASH = VALUE; CipherSuite TLS_KEA_AUTH_WITH_CIPHER_HASH = VALUE;
+-----------+-------------------------------------------------+
| Component | Contents | +-----------+-------------------------------------------------------+
+-----------+-------------------------------------------------+ | Component | Contents |
| TLS | The string "TLS" | +-----------+-------------------------------------------------------+
| | | | TLS | The string "TLS" |
| KEA | The key exchange algorithm | | | |
| | | | KEA | The key exchange algorithm (e.g. ECDHE, DHE) |
| SIGN | The signature algorithm | | | |
| | | | AUTH | The authentication algorithm (e.g. certificates, PSK) |
| WITH | The string "WITH" | | | |
| | | | WITH | The string "WITH" |
| CIPHER | The symmetric cipher used for record protection | | | |
| | | | CIPHER | The symmetric cipher used for record protection |
| HASH | The hash algorithm used with HKDF | | | |
| | | | HASH | The hash algorithm used with HKDF |
| VALUE | The two byte ID assigned for this cipher suite | | | |
+-----------+-------------------------------------------------+ | VALUE | The two byte ID assigned for this cipher suite |
+-----------+-------------------------------------------------------+
The "CIPHER" component commonly has sub-components used to designate The "CIPHER" component commonly has sub-components used to designate
the cipher name, bits, and mode, if applicable. For example, the cipher name, bits, and mode, if applicable. For example,
"AES_256_GCM" represents 256-bit AES in the GCM mode of operation. "AES_256_GCM" represents 256-bit AES in the GCM mode of operation.
Cipher suite names that lack a "HASH" value that are defined for use Cipher suite names that lack a "HASH" value that are defined for use
with TLS 1.2 or later use the SHA-256 hash algorithm by default. with TLS 1.2 or later use the SHA-256 hash algorithm by default.
The primary key exchange algorithm used in TLS is Ephemeral Diffie- The primary key exchange algorithm used in TLS is Ephemeral Diffie-
Hellman [DH]. The finite field based version is denoted "DHE" and Hellman [DH]. The finite field based version is denoted "DHE" and
the elliptic curve based version is denoted "ECDHE". Prior versions the elliptic curve based version is denoted "ECDHE". Prior versions
skipping to change at page 101, line 38 skipping to change at page 102, line 38
| | | | | | | |
| TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x | [RFC6655] | | TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x | [RFC6655] |
| | 9F} | | | | 9F} | |
| | | | | | | |
| TLS_DHE_RSA_WITH_AES_128_CCM_ | {0xC0,0x | [RFC6655] | | TLS_DHE_RSA_WITH_AES_128_CCM_ | {0xC0,0x | [RFC6655] |
| 8 | A2} | | | 8 | A2} | |
| | | | | | | |
| TLS_DHE_RSA_WITH_AES_256_CCM_ | {0xC0,0x | [RFC6655] | | TLS_DHE_RSA_WITH_AES_256_CCM_ | {0xC0,0x | [RFC6655] |
| 8 | A3} | | | 8 | A3} | |
| | | | | | | |
| TLS_ECDHE_RSA_WITH_CHACHA20_P | {TBD,TBD | [I-D.ietf-tls-chacha20 | | TLS_ECDHE_RSA_WITH_CHACHA20_P | {0xCC,0x | [I-D.ietf-tls-chacha20 |
| OLY1305_SHA256 | } | -poly1305] | | OLY1305_SHA256 | A8} | -poly1305] |
| | | | | | | |
| TLS_ECDHE_ECDSA_WITH_CHACHA20 | {TBD,TBD | [I-D.ietf-tls-chacha20 | | TLS_ECDHE_ECDSA_WITH_CHACHA20 | {0xCC,0x | [I-D.ietf-tls-chacha20 |
| _POLY1305_SHA256 | } | -poly1305] | | _POLY1305_SHA256 | A9} | -poly1305] |
| | | | | | | |
| TLS_DHE_RSA_WITH_CHACHA20_POL | {TBD,TBD | [I-D.ietf-tls-chacha20 | | TLS_DHE_RSA_WITH_CHACHA20_POL | {0xCC,0x | [I-D.ietf-tls-chacha20 |
| Y1305_SHA256 | } | -poly1305] | | Y1305_SHA256 | AA} | -poly1305] |
+-------------------------------+----------+------------------------+ +-------------------------------+----------+------------------------+
[[TODO: CHACHA20_POLY1305_SHA256 cipher suite IDs are TBD.]] Note: The values listed for ChaCha/Poly are preliminary but are being
or will be used for interop testing and therefore are likely to be
assigned.
Note: ECDHE AES GCM was not yet standards track prior to the Note: ECDHE AES GCM was not yet standards track prior to the
publication of this specification. This document promotes it to publication of this specification. This document promotes the above-
Standards Track. listed ciphers to standards track.
The following is a list of standards track ephemeral pre-shared key
cipher suites which are currently available in TLS 1.3:
+------------------------------+----------+-------------------------+
| Cipher Suite Name | Value | Specification |
+------------------------------+----------+-------------------------+
| TLS_DHE_PSK_WITH_AES_128_GCM | {0x00,0x | [RFC5487] |
| _SHA256 | AA} | |
| | | |
| TLS_DHE_PSK_WITH_AES_256_GCM | {0x00,0x | [RFC5487] |
| _SHA384 | AB} | |
| | | |
| TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0x | [RFC6655] |
| | A6} | |
| | | |
| TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0x | [RFC6655] |
| | A7} | |
| | | |
| TLS_PSK_DHE_WITH_AES_128_CCM | {0xC0,0x | [RFC6655] |
| _8 | AA} | |
| | | |
| TLS_PSK_DHE_WITH_AES_256_CCM | {0xC0,0x | [RFC6655] |
| _8 | AB} | |
| | | |
| TLS_ECDHE_PSK_WITH_AES_128_G | {0xD0,0x | [I-D.mattsson-tls-ecdhe |
| CM_SHA256 | 01} | -psk-aead] |
| | | |
| TLS_ECDHE_PSK_WITH_AES_256_G | {0xD0,0x | [I-D.mattsson-tls-ecdhe |
| CM_SHA384 | 02} | -psk-aead] |
| | | |
| TLS_ECDHE_PSK_WITH_AES_128_C | {0xD0,0x | [I-D.mattsson-tls-ecdhe |
| CM_8_SHA256 | 03} | -psk-aead] |
| | | |
| TLS_ECDHE_PSK_WITH_AES_128_C | {0xD0,0x | [I-D.mattsson-tls-ecdhe |
| CM_SHA256 | 04} | -psk-aead] |
| | | |
| TLS_ECDHE_PSK_WITH_AES_256_C | {0xD0,0x | [I-D.mattsson-tls-ecdhe |
| CM_SHA384 | 05} | -psk-aead] |
| | | |
| TLS_ECDHE_PSK_WITH_CHACHA20_ | {0xCC,0x | [I-D.ietf-tls-chacha20- |
| POLY1305_SHA256 | AC} | poly1305] |
| | | |
| TLS_DHE_PSK_WITH_CHACHA20_PO | {0xCC,0x | [I-D.ietf-tls-chacha20- |
| LY1305_SHA256 | AD} | poly1305] |
+------------------------------+----------+-------------------------+
Note: The values listed for ECDHE and ChaCha/Poly are preliminary but
are being or will be used for interop testing and therefore are
likely to be assigned.
Note: [RFC6655] is inconsistent with respect to the ordering of
components within PSK AES CCM cipher suite names. The names above
are as defined.
All cipher suites in this section are specified for use with both TLS All cipher suites in this section are specified for use with both TLS
1.2 and TLS 1.3, as well as the corresponding versions of DTLS. (see 1.2 and TLS 1.3, as well as the corresponding versions of DTLS. (see
Appendix C) Appendix C)
New cipher suite values are assigned by IANA as described in New cipher suite values are assigned by IANA as described in
Section 11. Section 11.
A.4.1. Unauthenticated Operation A.4.1. Unauthenticated Operation
skipping to change at page 106, line 37 skipping to change at page 109, line 37
negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version negotiate 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 number to the negotiated version for the ServerHello and all records
thereafter. thereafter.
For maximum compatibility with previously non-standard behavior and For maximum compatibility with previously non-standard behavior and
misconfigured deployments, all implementations SHOULD support misconfigured deployments, all implementations SHOULD support
validation of certification paths based on the expectations in this validation of certification paths based on the expectations in this
document, even when handling prior TLS versions' handshakes. (see document, even when handling prior TLS versions' handshakes. (see
Section 6.3.4.1.1) Section 6.3.4.1.1)
TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627]
extension which digested large parts of the handshake transcript into
the master secret. Because TLS 1.3 always hashes in the transcript
up to the server CertificateVerify, implementations which support
both TLS 1.3 and earlier versions SHOULD indicate the use of the
Extended Master Secret extension in their APIs whenever TLS 1.3 is
used.
C.1. Negotiating with an older server C.1. Negotiating with an older server
A TLS 1.3 client who wishes to negotiate with such older servers will A TLS 1.3 client who wishes to negotiate with such older servers will
send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in
ClientHello.client_version. If the server does not support this ClientHello.client_version. If the server does not support this
version it will respond with a ServerHello containing an older version it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol. negotiation will proceed as appropriate for the negotiated protocol.
A client resuming a session SHOULD initiate the connection using the A client resuming a session SHOULD initiate the connection using the
version that was previously negotiated. version that was previously negotiated.
If the version chosen by the server is not supported by the client If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert (or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection. message and close the connection.
If a TLS server receives a ClientHello containing a version number If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server. reply according to the highest version supported by the server.
skipping to change at page 111, line 51 skipping to change at page 115, line 13
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
- Christopher Allen (co-editor of TLS 1.0) - Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
- Steven M. Bellovin - Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
- David Benjamin
Google
davidben@google.com
- Benjamin Beurdouche - Benjamin Beurdouche
- Karthikeyan Bhargavan (co-author of [RFC7627]) - Karthikeyan Bhargavan (co-author of [RFC7627])
INRIA INRIA
karthikeyan.bhargavan@inria.fr karthikeyan.bhargavan@inria.fr
- Simon Blake-Wilson (co-author of [RFC4492]) - Simon Blake-Wilson (co-author of [RFC4492])
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
- Nelson Bolyard (co-author of [RFC4492]) - Nelson Bolyard (co-author of [RFC4492])
Sun Microsystems, Inc. Sun Microsystems, Inc.
skipping to change at page 113, line 17 skipping to change at page 116, line 31
chris@corriente.net chris@corriente.net
- Kipp Hickman - Kipp Hickman
- Alfred Hoenes - Alfred Hoenes
- David Hopwood - David Hopwood
Independent Consultant Independent Consultant
david.hopwood@blueyonder.co.uk david.hopwood@blueyonder.co.uk
- Subodh Iyengar
Facebook
subodh@fb.com
- Daniel Kahn Gillmor - Daniel Kahn Gillmor
ACLU ACLU
dkg@fifthhorseman.net dkg@fifthhorseman.net
- Phil Karlton (co-author of SSL 3.0) - Phil Karlton (co-author of SSL 3.0)
- Paul Kocher (co-author of SSL 3.0) - Paul Kocher (co-author of SSL 3.0)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
skipping to change at page 114, line 32 skipping to change at page 117, line 51
- Jim Roskind - Jim Roskind
Netscape Communications Netscape Communications
jar@netscape.com jar@netscape.com
- Michael Sabin - Michael Sabin
- Dan Simon - Dan Simon
Microsoft, Inc. Microsoft, Inc.
dansimon@microsoft.com dansimon@microsoft.com
- Nick Sullivan
CloudFlare Inc.
nick@cloudflare.com
- Bjoern Tackmann - Bjoern Tackmann
University of California, San Diego University of California, San Diego
btackmann@eng.ucsd.edu btackmann@eng.ucsd.edu
- Martin Thomson - Martin Thomson
Mozilla Mozilla
mt@mozilla.com mt@mozilla.com
- Tom Weinstein - Tom Weinstein
 End of changes. 124 change blocks. 
492 lines changed or deleted 614 lines changed or added

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