draft-ietf-tls-tls13-02.txt   draft-ietf-tls-tls13-03.txt 
Network Working Group T. Dierks Network Working Group T. Dierks
Internet-Draft Independent Internet-Draft Independent
Obsoletes: 3268, 4346, 4366, 5246 E. Rescorla Obsoletes: 3268, 4346, 4366, 5246 (if E. Rescorla
(if approved) RTFM, Inc. approved) RTFM, Inc.
Updates: 4492 (if approved) July 7, 2014 Updates: 4492 (if approved) October 27, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: January 8, 2015 Expires: April 30, 2015
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-02 draft-ietf-tls-tls13-03
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 provides communications security (TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. tampering, or message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 8, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . . 6 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5
1.3. Major Differences from TLS 1.1 . . . . . . . . . . . . . . 6 1.3. Major Differences from TLS 1.1 . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Goals of This Document . . . . . . . . . . . . . . . . . . . . 8 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 9 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . . 12 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . . 13 4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 13
4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14
5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 15 5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 15
6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16 6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16
6.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 6.1. Connection States . . . . . . . . . . . . . . . . . . . . 17
6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19
6.2.2. Record Payload Protection . . . . . . . . . . . . . . 20 6.2.2. Record Payload Protection . . . . . . . . . . . . . . 20
6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 22 6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 22
7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23 7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23
7.1. Change Cipher Spec Protocol . . . . . . . . . . . . . . . 24 7.1. Change Cipher Spec Protocol . . . . . . . . . . . . . . . 24
7.2. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . 25 7.2.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25
7.2.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . 26 7.2.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26
7.3. Handshake Protocol Overview . . . . . . . . . . . . . . . 30 7.3. Handshake Protocol Overview . . . . . . . . . . . . . . . 30
7.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . 34 7.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 34
7.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . . 35 7.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 35
7.4.2. Client Key Exchange Message . . . . . . . . . . . . . 39 7.4.2. Client Key Share Message . . . . . . . . . . . . . . 39
7.4.3. Server Key Exchange Message . . . . . . . . . . . . . 47 7.4.3. Server Key Share Message . . . . . . . . . . . . . . 52
7.4.4. Encrypted Extensions . . . . . . . . . . . . . . . . . 48 7.4.4. Encrypted Extensions . . . . . . . . . . . . . . . . 52
7.4.5. Server Certificate . . . . . . . . . . . . . . . . . . 49 7.4.5. Server Certificate . . . . . . . . . . . . . . . . . 53
7.4.6. Certificate Request . . . . . . . . . . . . . . . . . 52 7.4.6. Certificate Request . . . . . . . . . . . . . . . . . 55
7.4.7. Server Certificate Verify . . . . . . . . . . . . . . 53 7.4.7. Server Certificate Verify . . . . . . . . . . . . . . 57
7.4.8. Server Finished . . . . . . . . . . . . . . . . . . . 55 7.4.8. Server Finished . . . . . . . . . . . . . . . . . . . 58
7.4.9. Client Certificate . . . . . . . . . . . . . . . . . . 56 7.4.9. Client Certificate . . . . . . . . . . . . . . . . . 60
7.4.10. Client Certificate Verify . . . . . . . . . . . . . . 58 7.4.10. Client Certificate Verify . . . . . . . . . . . . . . 61
8. Cryptographic Computations . . . . . . . . . . . . . . . . . . 58 8. Cryptographic Computations . . . . . . . . . . . . . . . . . 62
8.1. Computing the Master Secret . . . . . . . . . . . . . . . 59 8.1. Computing the Master Secret . . . . . . . . . . . . . . . 62
8.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 59 8.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 63
9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 59 8.1.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 63
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 59 9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 63
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 63
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . 63
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . . 61 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.2. Informative References . . . . . . . . . . . . . . . . . . 63 13.1. Normative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Protocol Data Structures and Constant Values . . . . 67 13.2. Informative References . . . . . . . . . . . . . . . . . 66
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . . 67 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 67 Appendix A. Protocol Data Structures and Constant Values . . . . 70
A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 68 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 70
A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . 69 A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 70
A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . . 69 A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . 70
A.4.2. Server Authentication and Key Exchange Messages . . . 71 A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 71
A.4.3. Client Authentication and Key Exchange Messages . . . 72 A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 72
A.4.4. Handshake Finalization Message . . . . . . . . . . . . 72 A.4.2. Server Authentication and Key Exchange Messages . . . 74
A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . . 72 A.4.3. Client Authentication and Key Exchange Messages . . . 74
A.6. The Security Parameters . . . . . . . . . . . . . . . . . 74 A.4.4. Handshake Finalization Message . . . . . . . . . . . 75
A.7. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 74 A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 75 A.6. The Security Parameters . . . . . . . . . . . . . . . . . 77
Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 78 A.7. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 77
Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 79 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 78
D.1. Random Number Generation and Seeding . . . . . . . . . . . 79 Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 81
D.2. Certificates and Authentication . . . . . . . . . . . . . 79 Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 81
D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 79 D.1. Random Number Generation and Seeding . . . . . . . . . . 81
D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 79 D.2. Certificates and Authentication . . . . . . . . . . . . . 82
Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 81 D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 82
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 . . . . . . . . 81 D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 82
E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . . 82 Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 83
E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 84 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 . . . . . . . 83
Appendix F. Security Analysis . . . . . . . . . . . . . . . . . . 84 E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . 85
F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . . 84 E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 87
F.1.1. Authentication and Key Exchange . . . . . . . . . . . 85 Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 87
F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . . 86 F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 87
F.1.3. Detecting Attacks Against the Handshake Protocol . . . 87 F.1.1. Authentication and Key Exchange . . . . . . . . . . . 87
F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 87 F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 89
F.2. Protecting Application Data . . . . . . . . . . . . . . . 88 F.1.3. Detecting Attacks Against the Handshake Protocol . . 89
F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 88 F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 89
F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 88 F.2. Protecting Application Data . . . . . . . . . . . . . . . 90
Appendix G. Working Group Information . . . . . . . . . . . . . . 89 F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 90
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 89 F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 90
Appendix G. Working Group Information . . . . . . . . . . . . . 91
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 91
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 30 skipping to change at page 5, line 38
of protocols that run on top of TLS. of protocols that run on top of TLS.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-02 draft-03
- Remove GMT time.
- Merge in support for ECC from RFC 4492 but without explicit
curves.
- Remove the unnecessary length field from the AD input to AEAD
ciphers.
- Rename {Client,Server}KeyExchange to {Client,Server}KeyShare
- Add an explicit HelloRetryRequest to reject the client's
- Increment version number. - Increment version number.
- Reworked handshake to provide 1-RTT mode. - Reworked handshake to provide 1-RTT mode.
- Remove custom DHE groups. - Remove custom DHE groups.
- Removed support for compression. - Removed support for compression.
- Removed support for static RSA and DH key exchange. - Removed support for static RSA and DH key exchange.
skipping to change at page 9, line 52 skipping to change at page 9, line 27
A vector (single-dimensioned array) is a stream of homogeneous data A vector (single-dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case, the length time or left unspecified until runtime. In either case, the length
declares the number of bytes, not the number of elements, in the declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type, T', that is a fixed- vector. The syntax for specifying a new type, T', that is a fixed-
length vector of type T is length vector of type T is
T T'[n]; T T'[n];
Here, T' occupies n bytes in the data stream, where n is a multiple Here, T' occupies n bytes in the data stream, where n is a multiple
of the size of T. The length of the vector is not included in the of the size of T. The length of the vector is not included in the
encoded stream. encoded stream.
In the following example, Datum is defined to be three consecutive In the following example, Datum is defined to be three consecutive
bytes that the protocol does not interpret, while Data is three bytes that the protocol does not interpret, while Data is three
consecutive Datum, consuming a total of nine bytes. consecutive Datum, consuming a total of nine bytes.
opaque Datum[3]; /* three uninterpreted bytes */ opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */ Datum Data[9]; /* 3 consecutive 3 byte vectors */
Variable-length vectors are defined by specifying a subrange of legal Variable-length vectors are defined by specifying a subrange of legal
skipping to change at page 13, line 47 skipping to change at page 13, line 23
state (see Section 6.1). state (see Section 6.1).
A digitally-signed element is encoded as a struct DigitallySigned: A digitally-signed element is encoded as a struct DigitallySigned:
struct { struct {
SignatureAndHashAlgorithm algorithm; SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} DigitallySigned; } DigitallySigned;
The algorithm field specifies the algorithm used (see The algorithm field specifies the algorithm used (see
Section 7.4.2.3.1 for the definition of this field). Note that the Section 7.4.2.5.1 for the definition of this field). Note that the
algorithm field was introduced in TLS 1.2, and is not in earlier algorithm field was introduced in TLS 1.2, and is not in earlier
versions. The signature is a digital signature using those versions. The signature is a digital signature using those
algorithms over the contents of the element. The contents themselves algorithms over the contents of the element. The contents themselves
do not appear on the wire but are simply calculated. The length of do not appear on the wire but are simply calculated. The length of
the signature is specified by the signing algorithm and key. the signature is specified by the signing algorithm and key.
In RSA signing, the opaque vector contains the signature generated In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447]. using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447].
As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680] As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680]
[X690]. For hash algorithms without parameters (which includes [X690]. For hash algorithms without parameters (which includes SHA-
SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be 1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL,
NULL, but implementations MUST accept both without parameters and but implementations MUST accept both without parameters and with NULL
with NULL parameters. Note that earlier versions of TLS used a parameters. Note that earlier versions of TLS used a different RSA
different RSA signature scheme that did not include a DigestInfo signature scheme that did not include a DigestInfo encoding.
encoding.
In DSA, the 20 bytes of the SHA-1 hash are run directly through the In DSA, the 20 bytes of the SHA-1 hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces Digital Signing Algorithm with no additional hashing. This produces
two values, r and s. The DSA signature is an opaque vector, as two values, r and s. The DSA signature is an opaque vector, as
above, the contents of which are the DER encoding of: above, the contents of which are the DER encoding of:
Dss-Sig-Value ::= SEQUENCE { Dss-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
Note: In current terminology, DSA refers to the Digital Signature Note: In current terminology, DSA refers to the Digital Signature
Algorithm and DSS refers to the NIST standard. In the original SSL Algorithm and DSS refers to the NIST standard. In the original SSL
and TLS specs, "DSS" was used universally. This document uses "DSA" and TLS specs, "DSS" was used universally. This document uses "DSA"
to refer to the algorithm, "DSS" to refer to the standard, and it to refer to the algorithm, "DSS" to refer to the standard, and it
uses "DSS" in the code point definitions for historical continuity. uses "DSS" in the code point definitions for historical continuity.
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 default hash function is SHA-1 [SHS].
However, an alternative hash function, such as one of the new SHA
hash functions specified in FIPS 180-2 may be used instead if the
certificate containing the EC public key explicitly requires use of
another hash function. (The mechanism for specifying the required
hash function has not been standardized, but this provision
anticipates such standardization and obviates the need to update this
document in response. Future PKIX RFCs may choose, for example, to
specify the hash function to be used with a public key in the
parameters field of subjectPublicKeyInfo.) [[OPEN ISSUE: This needs
updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]
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.
In the following example In the following example
struct { struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
skipping to change at page 21, line 32 skipping to change at page 21, line 31
length length
The length (in bytes) of the following TLSCiphertext.fragment. The length (in bytes) of the following TLSCiphertext.fragment.
The length MUST NOT exceed 2^14 + 2048. The length MUST NOT exceed 2^14 + 2048.
fragment fragment
The AEAD encrypted form of TLSPlaintext.fragment. The AEAD encrypted form of TLSPlaintext.fragment.
Each AEAD cipher suite MUST specify how the nonce supplied to the Each AEAD cipher suite MUST specify how the nonce supplied to the
AEAD operation is constructed, and what is the length of the AEAD operation is constructed, and what is the length of the
TLSCiphertext.nonce_explicit part. In many cases, it is appropriate TLSCiphertext.nonce_explicit part. In many cases, it is appropriate
to use the partially implicit nonce technique described in Section to use the partially implicit nonce technique described in
3.2.1 of [RFC5116]; with record_iv_length being the length of the Section 3.2.1 of [RFC5116]; with record_iv_length being the length of
explicit part. In this case, the implicit part SHOULD be derived the explicit part. In this case, the implicit part SHOULD be derived
from key_block as client_write_iv and server_write_iv (as described from key_block as client_write_iv and server_write_iv (as described
in Section 6.3), and the explicit part is included in in Section 6.3), and the explicit part is included in
GenericAEAEDCipher.nonce_explicit. GenericAEAEDCipher.nonce_explicit.
The plaintext is the TLSPlaintext.fragment. The plaintext is the TLSPlaintext.fragment.
The additional authenticated data, which we denote as The additional authenticated data, which we denote as
additional_data, is defined as follows: additional_data, is defined as follows:
additional_data = seq_num + TLSPlaintext.type + additional_data = seq_num + TLSPlaintext.type +
TLSPlaintext.version + TLSPlaintext.length; TLSPlaintext.version
[[OPEN ISSUE: Fix length which gives us a problem here for algorithms
which pad. See: https://github.com/tlswg/tls13-spec/issues/47]]
where "+" denotes concatenation. where "+" denotes concatenation.
Note: In versions of TLS prior to 1.3, the additional_data included a
length field. This presents a problem for cipher constructions with
data-dependent padding (such as CBC). TLS 1.3 removes the length
field and relies on the AEAD cipher to provide integrity for the
length of the data.
The AEAD output consists of the ciphertext output by the AEAD The AEAD output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than encryption operation. The length will generally be larger than
TLSPlaintext.length, but by an amount that varies with the AEAD TLSPlaintext.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSPlaintext.length values. Each overhead could vary with different TLSPlaintext.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically, Symbolically,
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
additional_data) additional_data)
[[OPEN ISSUE: Reduce these values? [[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13-
https://github.com/tlswg/tls13-spec/issues/55]] spec/issues/55]]
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
nonce, the "additional_data", and the AEADEncrypted value. The nonce, the "additional_data", and the AEADEncrypted value. The
output is either the plaintext or an error indicating that the output is either the plaintext or an error indicating that the
decryption failed. There is no separate integrity check. That is: decryption failed. There is no separate integrity check. That is:
TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce, TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce,
AEADEncrypted, AEADEncrypted,
additional_data) additional_data)
If the decryption fails, a fatal bad_record_mac alert MUST be If the decryption fails, a fatal bad_record_mac alert MUST be
generated. generated.
As a special case, we define the NULL_NULL AEAD cipher which is As a special case, we define the NULL_NULL AEAD cipher which is
simply the identity operation and thus provides no security. This simply the identity operation and thus provides no security. This
cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL
cipher suite. cipher suite.
6.3. Key Calculation 6.3. Key Calculation
[[OPEN ISSUE: This may be revised. See [[OPEN ISSUE: This needs to be revised. See
https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol
requires an algorithm to generate keys required by the current requires an algorithm to generate keys required by the current
connection state (see Appendix A.6) from the security parameters connection state (see Appendix A.6) from the security parameters
provided by the handshake protocol. provided by the handshake protocol.
The master secret is expanded into a sequence of secure bytes, which The master secret is expanded into a sequence of secure bytes, which
is then split to a client write encryption key and a server write is then split to a client write encryption key and a server write
encryption key. Each of these is generated from the byte sequence in encryption key. Each of these is generated from the byte sequence in
that order. Unused values are empty. Some ciphers may additionally that order. Unused values are empty. Some ciphers may additionally
require a client write IV and a server write IV. require a client write IV and a server write IV.
skipping to change at page 31, line 18 skipping to change at page 31, line 12
information over a channel less secure than what they require. The information over a channel less secure than what they require. The
TLS protocol is secure in that any cipher suite offers its promised TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate AES-GCM [GCM] with a 1024-bit DHE level of security: if you negotiate AES-GCM [GCM] with a 1024-bit DHE
key exchange with a host whose certificate you have verified, you can key exchange with a host whose certificate you have verified, you can
expect to be that secure. expect to be that secure.
These goals are achieved by the handshake protocol, which can be These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message which summarized as follows: The client sends a ClientHello message which
contains a random nonce (ClientHello.random), its preferences for contains a random nonce (ClientHello.random), its preferences for
Protocol Version, Cipher Suite, and a variety of extensions. In the Protocol Version, Cipher Suite, and a variety of extensions. In the
same flight, it sends a ClientKeyExchange message which contains its same flight, it sends a ClientKeyShare message which contains its
share of the parameters for key agreement for some set of expected share of the parameters for key agreement for some set of expected
server parameters (DHE/ECDHE groups, etc.). server parameters (DHE/ECDHE groups, etc.).
The server responds to the ClientHello with a ServerHello message, or If the client has provided a ClientKeyShare with an appropriate set
else a fatal error will occur and the connection will fail. The of keying material, the server responds to the ClientHello with a
ServerHello contains the server's nonce (ServerHello.random), the ServerHello message. The ServerHello contains the server's nonce
server's choice of the Protocol Version, Session ID and Cipher Suite, (ServerHello.random), the server's choice of the Protocol Version,
and the server's response to the extensions the client offered. Session ID and Cipher Suite, and the server's response to the
extensions the client offered.
If the client has provided a ClientKeyExchange with an appropriate The server can then generate its own keying material share and send a
set of keying material, the server can then generate its own keying ServerKeyShare message which contains its share of the parameters for
material share and send a ServerKeyExchange message which contains the key agreement. The server can now compute the shared secret. At
its share of the parameters for the key agreement. The server can this point, a ChangeCipherSpec message is sent by the server, and the
now compute the shared secret. At this point, a ChangeCipherSpec server copies the pending Cipher Spec into the current Cipher Spec.
message is sent by the server, and the server copies the pending The remainder of the server's handshake messages will be encrypted
Cipher Spec into the current Cipher Spec. The remainder of the under that Cipher Spec.
server's handshake messages will be encrypted under that Cipher Spec.
Following these messages, the server will send an EncryptedExtensions Following these messages, the server will send an EncryptedExtensions
message which contains a response to any client's extensions which message which contains a response to any client's extensions which
are not necessary to establish the Cipher Suite. The server will are not necessary to establish the Cipher Suite. The server will
then send its certificate in a Certificate message if it is to be then send its certificate in a Certificate message if it is to be
authenticated. The server may optionally request a certificate from authenticated. The server may optionally request a certificate from
the client by sending a CertificateRequest message at this point. the client by sending a CertificateRequest message at this point.
Finally, if the server is authenticated, it will send a Finally, if the server is authenticated, it will send a
CertificateVerify message which provides a signature over the entire CertificateVerify message which provides a signature over the entire
handshake up to this point. This serves both to authenticate the handshake up to this point. This serves both to authenticate the
server and to establish the integrity of the negotiation. Finally, server and to establish the integrity of the negotiation. Finally,
the server sends a Finished message which includes an integrity check the server sends a Finished message which includes an integrity check
over the handshake keyed by the shared secret and demonstrates that over the handshake keyed by the shared secret and demonstrates that
the server and client have agreed upon the same keys. [[TODO: If the the server and client have agreed upon the same keys. [[TODO: If the
server is not requesting client authentication, it MAY start sending server is not requesting client authentication, it MAY start sending
application data following the Finished, though the server has no way application data following the Finished, though the server has no way
of knowing who will be receiving the data. Add this.]] of knowing who will be receiving the data. Add this.]]
Once the client receives the ServerKeyExchange, it can also compute Once the client receives the ServerKeyShare, it can also compute the
the shared key. At this point ChangeCipherSpec message is sent by shared key. At this point ChangeCipherSpec message is sent by the
the client, and the client copies the pending Cipher Spec into the client, and the client copies the pending Cipher Spec into the
current Cipher Spec. The remainder of the client's messages will be current Cipher Spec. The remainder of the client's messages will be
encrypted under this Cipher Spec. If the server has sent a encrypted under this Cipher Spec. If the server has sent a
CertificateRequest message, the client MUST send the Certificate CertificateRequest message, the client MUST send the Certificate
message, though it may contain zero certificates. If the client has message, though it may contain zero certificates. If the client has
sent a certificate, a digitally-signed CertificateVerify message is sent a certificate, a digitally-signed CertificateVerify message is
sent to explicitly verify possession of the private key in the sent to explicitly verify possession of the private key in the
certificate. Finally, the client sends the Finished message. At certificate. Finally, the client sends the Finished message. At
this point, the handshake is complete, and the client and server may this point, the handshake is complete, and the client and server may
exchange application layer data. (See flow chart below.) exchange application layer data. (See flow chart below.)
Application data MUST NOT be sent prior to the Finished message. Application data MUST NOT be sent prior to the Finished message.
[[TODO: can we make this clearer and more clearly match the text [[TODO: can we make this clearer and more clearly match the text
above about server-side False Start.]] Client Server above about server-side False Start.]] Client Server
ClientHello ClientHello
ClientKeyExchange --------> ClientKeyShare -------->
ServerHello ServerHello
ServerKeyExchange ServerKeyShare
[ChangeCipherSpec] [ChangeCipherSpec]
EncryptedExtensions* EncryptedExtensions*
Certificate* Certificate*
CertificateRequest* CertificateRequest*
CertificateVerify* CertificateVerify*
<-------- Finished <-------- Finished
[ChangeCipherSpec] [ChangeCipherSpec]
Certificate* Certificate*
CertificateVerify* CertificateVerify*
Finished --------> Finished -------->
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1. Message flow for a full handshake Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not * Indicates optional or situation-dependent messages that are not
always sent. always sent.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an Note: To help avoid pipeline stalls, ChangeCipherSpec is an
independent TLS protocol content type, and is not actually a TLS independent TLS protocol content type, and is not actually a TLS
handshake message. handshake message.
If the client has not provided an appropriate ClientKeyExchange (e.g. If the client has not provided an appropriate ClientKeyShare (e.g. it
it includes only DHE or ECDHE groups unacceptable or unsupported by includes only DHE or ECDHE groups unacceptable or unsupported by the
the server), the server corrects the mismatch with the ServerHello server), the server corrects the mismatch with a HelloRetryRequest
(which the client can detect by comparing the selected cipher suite and the client will need to restart the handshake with an appropriate
and parameters with the ClientKeyExchange it offered) and the client ClientKeyShare, as shown in Figure 2:
will need to restart the handshake with an appropriate
ClientKeyExchange, as shown in Figure 2:
Client Server Client Server
ClientHello ClientHello
ClientKeyExchange --------> ClientKeyShare -------->
<-------- ServerHello <-------- HelloRetryRequest
ClientHello ClientHello
ClientKeyExchange --------> ClientKeyShare -------->
ServerHello ServerHello
ServerKeyExchange ServerKeyShare
[ChangeCipherSpec] [ChangeCipherSpec]
EncryptedExtensions* EncryptedExtensions*
Certificate* Certificate*
CertificateRequest* CertificateRequest*
CertificateVerify* CertificateVerify*
<-------- Finished <-------- Finished
[ChangeCipherSpec] [ChangeCipherSpec]
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: Do we restart the handshake hash?]] [[OPEN ISSUE: We [[OPEN ISSUE: Do we restart the handshake hash?]] [[OPEN ISSUE: We
need to make sure that this flow doesn't introduce downgrade issues. need to make sure that this flow doesn't introduce downgrade issues.
Potential options include continuing the handshake hashes (as long as Potential options include continuing the handshake hashes (as long as
clients don't change their opinion of the server's capabilities with clients don't change their opinion of the server's capabilities with
aborted handshakes) and requiring the client to send the same aborted handshakes) and requiring the client to send the same
ClientHello (as is currently done) and then checking you get the same ClientHello (as is currently done) and then checking you get the same
negotiated parameters.]] negotiated parameters.]]
If no common cryptographic parameters can be negotiated, the server
will send a fatal alert.
When the client and server decide to resume a previous session or When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security duplicate an existing session (instead of negotiating new security
parameters), the message flow is as follows: parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match. be resumed. The server then checks its session cache for a match.
If a match is found, and the server is willing to re-establish the If a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both ServerHello with the same Session ID value. At this point, both
client and server MUST send ChangeCipherSpec messages and proceed client and server MUST send ChangeCipherSpec messages and proceed
skipping to change at page 35, line 7 skipping to change at page 35, line 7
The TLS Handshake Protocol is one of the defined higher-level clients The TLS Handshake Protocol is one of the defined higher-level clients
of the TLS Record Protocol. This protocol is used to negotiate the of the TLS Record Protocol. This protocol is used to negotiate the
secure attributes of a session. Handshake messages are supplied to secure attributes of a session. Handshake messages are supplied to
the TLS record layer, where they are encapsulated within one or more the TLS record layer, where they are encapsulated within one or more
TLSPlaintext structures, which are processed and transmitted as TLSPlaintext structures, which are processed and transmitted as
specified by the current active session state. specified by the current active session state.
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12), certificate(11), reserved(12), server_key_share (17),
certificate_request(13), certificate_verify(15), certificate_request(13), certificate_verify(15),
client_key_exchange(16), finished(20), (255) reserved(16), client_key_share(18), finished(20), (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 hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case client_key_exchange: ClientKeyExchange; case client_key_share: ClientKeyShare;
case server_hello: ServerHello; case server_hello: ServerHello;
case server_key_exchange: ServerKeyExchange; case hello_retry_requst: HelloRetryRequest;
case server_key_share: ServerKeyShare;
case certificate: Certificate; case certificate: Certificate;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
The handshake protocol messages are presented below in the order they The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be results in a fatal error. Unneeded handshake messages can be
skipping to change at page 36, line 50 skipping to change at page 36, line 48
When this message will be sent: When this message will be sent:
When a client first connects to a server, it is required to send When a client first connects to a server, it is required to send
the ClientHello as its first message. The client can also send a the ClientHello as its first message. The client can also send a
ClientHello in response to a HelloRequest or on its own initiative ClientHello in response to a HelloRequest or on its own initiative
in order to renegotiate the security parameters in an existing in order to renegotiate the security parameters in an existing
connection. Finally, the client will send a ClientHello when the connection. Finally, the client will send a ClientHello when the
server has responded to its ClientHello with a ServerHello that server has responded to its ClientHello with a ServerHello that
selects cryptographic parameters that don't match the client's selects cryptographic parameters that don't match the client's
ClientKeyExchange. In that case, the client MUST send the same ClientKeyShare. In that case, the client MUST send the same
ClientHello (without modification) along with the new ClientHello (without modification) along with the new
ClientKeyExchange. ClientKeyShare.
Structure of this message: Structure of this message:
The ClientHello message includes a random structure, which is used The ClientHello message includes a random structure, which is used
later in the protocol. later in the protocol.
struct { struct {
uint32 gmt_unix_time; opaque random_bytes[32];
opaque random_bytes[28];
} Random; } Random;
gmt_unix_time
The current time and date in standard UNIX 32-bit format (seconds
since the midnight starting Jan 1, 1970, UTC, ignoring leap
seconds) according to the sender's internal clock. Clocks are not
required to be set correctly by the basic TLS protocol; higher-
level or application protocols may define additional requirements.
Note that, for historical reasons, the data element is named using
GMT, the predecessor of the current worldwide time base, UTC.
random_bytes random_bytes
28 bytes generated by a secure random number generator. 32 bytes generated by a secure random number generator.
The ClientHello message includes a variable-length session Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the
Random value to encode the time since the UNIX epoch.
Note: The ClientHello message includes a variable-length session
identifier. If not empty, the value identifies a session between the identifier. If not empty, the value identifies a session between the
same client and server whose security parameters the client wishes to same client and server whose security parameters the client wishes to
reuse. The session identifier MAY be from an earlier connection, reuse. The session identifier MAY be from an earlier connection,
this connection, or from another currently active connection. The this connection, or from another currently active connection. The
second option is useful if the client only wishes to update the second option is useful if the client only wishes to update the
random structures and derived values of a connection, and the third random structures and derived values of a connection, and the third
option makes it possible to establish several independent secure option makes it possible to establish several independent secure
connections without repeating the full handshake protocol. These connections without repeating the full handshake protocol. These
independent connections may occur sequentially or simultaneously; a independent connections may occur sequentially or simultaneously; a
SessionID becomes valid when the handshake negotiating it completes SessionID becomes valid when the handshake negotiating it completes
skipping to change at page 39, line 31 skipping to change at page 39, line 21
method with the code point of 0. If a TLS 1.3 ClientHello is method with the code point of 0. If a TLS 1.3 ClientHello is
received with any other value in this field, the server MUST received with any other value in this field, the server MUST
generate a fatal "illegal_parameter" alert. Note that TLS 1.3 generate a fatal "illegal_parameter" alert. Note that TLS 1.3
servers may receive TLS 1.2 or prior ClientHellos which contain servers may receive TLS 1.2 or prior ClientHellos which contain
other compression methods and MUST follow the procedures for the other 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 MAY 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 7.4.2.3. defined in Section 7.4.2.5.
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.
After sending the ClientHello message, the client waits for a After sending the ClientHello message, the client waits for a
ServerHello message. Any handshake message returned by the server, ServerHello message. Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error. except for a HelloRequest, is treated as a fatal error.
7.4.2. Client Key Exchange Message 7.4.2. Client Key Share Message
When this message will be sent: When this message will be sent:
This message is always sent by the client. It MUST immediately This message is always sent by the client. It MUST immediately
follow the ClientHello message. In backward compatibility mode follow the ClientHello message. In backward compatibility mode
(see Section XXX) it will be included in the EarlyData extension (see Section XXX) it will be included in the EarlyData extension
(Section 7.4.2.3.2) in the ClientHello. (Section 7.4.2.5.4) in the ClientHello.
Meaning of this message: Meaning of this message:
This message contains the client's cryptographic parameters for This message contains the client's cryptographic parameters for
zero or more key establishment methods. zero or more key establishment methods.
Structure of this message: Structure of this message:
enum { dhe(1), (255) } KeyExchangeAlgorithm;
struct { struct {
KeyExchangeAlgorithm algorithm; NamedGroup group;
select (KeyExchangeAlgorithm) { opaque key_exchange<1..2^16-1>;
dhe: } ClientKeyShareOffer;
ClientDiffieHellmanParams;
} exchange_keys; group The named group for the key share offer. This identifies the
} ClientKeyExchangeOffer; specific key exchange method that the ClientKeyShareOffer
describes. Finite Field Diffie-Hellman parameters are described
in Section 7.4.2.1; Elliptic Curve Diffie-Hellman parameters are
described in Section 7.4.2.2.
key_exchange Key exchange information. The contents of this field
are determined by the value of NamedGroup entry and its
corresponding definition.
struct { struct {
ClientKeyExchangeOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyExchange; } ClientKeyShare;
offers offers
A list of ClientKeyExchangeOffer values. A list of ClientKeyShareOffer values.
[[OPEN ISSUE: Should we rename CKE here?]] Clients may offer an Clients may offer an arbitrary number of ClientKeyShareOffer values,
arbitrary number of ClientKeyExchangeOffer values, each representing each representing a single set of key agreement parameters; for
a single set of key agreement parameters; for instance a client might instance a client might offer shares for several elliptic curves or
offer shares for several elliptic curves or multiple integer DH multiple integer DH groups. The shares for each ClientKeyShareOffer
groups. The shares for each ClientKeyExchangeOffer MUST by generated MUST by generated independently. Clients MUST NOT offer multiple
independently. Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters. It is explicitly
ClientKeyExchangeOffers for the same parameters. It is explicitly permitted to send an empty ClientKeyShare message, as this is used to
permitted to send an empty ClientKeyExchange message, as this is used elicit the server's parameters if the client has no useful
to elicit the server's parameters if the client has no useful information. [TODO: Recommendation about what the client offers.
information. Presumably which integer DH groups and which curves.] [TODO: Work
out how this interacts with PSK and SRP.]
[TODO: Recommendation about what the client offers. Presumably which 7.4.2.1. Diffie-Hellman Parameters
integer DH groups and which curves.] [TODO: Work out how this
interacts with PSK and SRP.]
7.4.2.1. Client Diffie-Hellman Parameters Diffie-Hellman parameters for both clients and servers are encoded in
the opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer.
When one of the ClientKeyExchangeOffers is a Diffie-Hellman key, the opaque dh_Y<1..2^16-1>;
client SHALL encode it using ClientDiffieHellmanParams. This
structure conveys the client's Diffie-Hellman public value (dh_Yc)
and the group which it is being provided for.
Structure of this message: 7.4.2.2. ECHDE Parameters
struct { ECDHE parameters for both clients and servers are encoded in the
DiscreteLogDHEGroup group; // from draft-gillmor opaque key_exchange field of the ClientKeyShareOffer or
opaque dh_Yc<1..2^16-1>; ServerKeyShare structures. The opaque value conveys the Elliptic
} ClientDiffieHellmanParams; Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point, which can represent an elliptic curve point in
uncompressed or compressed format.
group opaque point <1..2^8-1>;
The DHE group to which these parameters correspond.
dh_Yc point
The client's Diffie-Hellman public value (g^X mod p). This is the byte string representation of an elliptic curve point
following the conversion routine in Section 4.3.6 of ANSI X9.62
{{X962}.
7.4.2.2. Server Hello [[OPEN ISSUE: We will need to adjust the compressed/uncompressed
point issue if we have new curves that don't need point compression.
This depends on the CFRG's recommendations. The expectation is that
future curves will come with defined point formats and that existing
curves conform to X9.62.]]
7.4.2.3. Server Hello
When this message will be sent: When this message will be sent:
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms. message when it was able to find an acceptable set of algorithms
If it cannot find such a match, it will respond with a handshake and the client's ClientKeyShare message was acceptable. If the
failure alert. client proposed groups are not acceptable by the server, it will
respond with an insufficient_security fatal alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { select (extensions_present) {
case false: case false:
skipping to change at page 42, line 41 skipping to change at page 43, line 5
the value from the state of the session being resumed. the value from the state of the session being resumed.
extensions extensions
A list of extensions. Note that only extensions offered by the A list of extensions. Note that only extensions offered by the
client can appear in the server's list. In TLS 1.3 as opposed to client can appear in the server's list. In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions Section 7.4.4 between the ServerHello and the EncryptedExtensions Section 7.4.4
message. The ServerHello MUST only include extensions which are message. The ServerHello MUST only include extensions which are
required to establish the cryptographic context. required to establish the cryptographic context.
7.4.2.3. Hello Extensions 7.4.2.4. HelloRetryRequest
When this message will be sent:
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an
acceptable offer. If it cannot find such a match, it will respond
with a handshake failure alert.
Structure of this message:
struct {
ProtocolVersion server_version;
CipherSuite cipher_suite;
NamedGroup selected_group;
Extension extensions<0..2^16-1>;
} HelloRetryRequest;
[[OPEN ISSUE: Merge in DTLS Cookies?]]
selected_group
The group which the client MUST use for its new ClientHello.
The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello. The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello/ClientKeyShare pair.
Upon receipt of a HelloRetryRequest, the client MUST send a new
ClientHello/ClientKeyShare pair to the server. The ClientKeyShare
MUST contain both the groups in the original ClientKeyShare as well
as a ClientKeyShareOffer consistent with the "selected_group" field.
I.e., it MUST be a superset of the previous ClientKeyShareOffer.
Upon re-sending the ClientHello/ClientKeyShare and receiving the
server's ServerHello/ServerKeyShare, the client MUST verify that the
selected ciphersuite and NamedGroup match that supplied in the
HelloRetryRequest.
7.4.2.5. Hello Extensions
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 {
signature_algorithms(13), early_data(TBD), (65535) signature_algorithms(13), early_data(TBD), (65535)
skipping to change at page 44, line 34 skipping to change at page 45, line 43
- It would be technically possible to use extensions to change major - It would be technically possible to use extensions to change major
aspects of the design of TLS; for example the design of cipher aspects of the design of TLS; for example the design of cipher
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.
7.4.2.3.1. Signature Algorithms 7.4.2.5.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/hash algorithm pairs may be used in
digital signatures. The "extension_data" field of this extension digital signatures. The "extension_data" field of this extension
contains a "supported_signature_algorithms" value. contains a "supported_signature_algorithms" value.
enum { enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255) sha512(6), (255)
} HashAlgorithm; } HashAlgorithm;
skipping to change at page 46, line 4 skipping to change at page 47, line 4
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 indicates permissible signature algorithms but not hash
algorithms. Section 7.4.5 and Section 7.4.3 describe the appropriate algorithms. Section 7.4.5 and Section 7.4.3 describe the appropriate
rules. rules.
If the client supports only the default hash and signature algorithms If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms (listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server use them for verifying messages sent by the server, i.e., server
certificates and server key exchange), it MUST send the certificates and server key share), it MUST send the
signature_algorithms extension, listing the algorithms it is willing signature_algorithms extension, listing the algorithms it is willing
to accept. to accept.
If the client does not send the signature_algorithms extension, the If the client does not send the signature_algorithms extension, the
server MUST do the following: server MUST do the following:
- If the negotiated key exchange algorithm is one of (DHE_RSA, - If the negotiated key exchange algorithm is one of (DHE_RSA,
ECDHE_RSA), behave as if client had sent the value {sha1,rsa}. ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.
- If the negotiated key exchange algorithm is DHE_DSS, behave as if - If the negotiated key exchange algorithm is DHE_DSS, behave as if
skipping to change at page 46, line 36 skipping to change at page 47, line 36
However, even if clients do offer it, the rules specified in [TLSEXT] However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand. require servers to ignore extensions they do not understand.
Servers MUST NOT send this extension. TLS servers MUST support Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. receiving this extension.
When performing session resumption, this extension is not included in When performing session resumption, this extension is not included in
Server Hello, and the server ignores the extension in Client Hello Server Hello, and the server ignores the extension in Client Hello
(if present). (if present).
7.4.2.3.2. Early Data Extension 7.4.2.5.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most
preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic curves" and only contained elliptic curve groups. See
[RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe].
The "extension_data" field of this extension SHALL contain a
"NamedGroupList" value:
enum {
// Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
// Finite Field Groups.
ffdhe2432(256), ffdhe3072(257), ffdhe4096(258),
ffdhe6144(259), ffdhe8192(260),
// Reserved Code Points.
reserved (0xFE00..0xFEFF),
reserved(0xFF01),
reserved(0xFF02),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<1..2^16-1>
} NamedGroupList;
sect163k1, etc: Indicates support of the corresponding named curve
The named curves defined here are those specified in SEC 2 [13].
Note that many of these curves are also recommended in ANSI X9.62
[X962] and FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are
reserved for private use. Values 0xFF01 and 0xFF02 were used in
previous versions of TLS but MUST NOT be offered by TLS 1.3
implementations. [[OPEN ISSUE: Triage curve list.]]
ffdhe2432, etc: Indicates support of the corresponding finite field
group, defined in [I-D.ietf-tls-negotiated-ff-dhe]
Items in named_curve_list are ordered according to the client's
preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192;
value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
and prefers to use secp192r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the
extension type (Supported Group Extension):
00 0A 00 06 00 04 00 13 00 15
The client MUST supply a "named_groups" extension containing at least
one group for each key exchange algorithm (currently DHE and ECDHE)
for which it offers a cipher suite. If the client does not supply a
"named_groups" extension with a compatible group, the server MUST NOT
negotiate a cipher suite of the relevant type. For instance, if a
client supplies only ECDHE groups, the server MUST NOT negotiate
finite field Diffie-Hellman. If no acceptable group can be selected
across all cipher suites, then the server MUST generate a fatal
"handshake_failure" alert.
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message. The server
must consider the supported groups in both cases.
[[TODO: IANA Considerations.]]
7.4.2.5.3. Supported Point Formats Extension
[[OPEN ISSUE: Can we simply mandate support for compressed points?
If so, we can omit this extension entirely.
https://github.com/tlswg/tls13-spec/issues/80.]]
A client that proposes ECC cipher suites in its ClientHello message
SHOULD send the Supported Point Formats Extension to indicate the
elliptic curve point formats it supports. If the Supported Point
Formats Extension is indeed sent, it MUST contain the value 0
(uncompressed) as one of the items in the list of point formats.
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Three point formats are included in the definition of ECPointFormat
above. The uncompressed point format is the default format in that
implementations of this document MUST support it for all of their
supported curves. Compressed point formats reduce bandwidth by
including only the x-coordinate and a single bit of the y-coordinate
of the point. Implementations of this document MAY support the
ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
where the former applies only to prime curves and the latter applies
only to characteristic-2 curves. (These formats are specified in
[X962].) Values 248 through 255 are reserved for private use.
The ECPointFormat name space is maintained by IANA. See Section 12
for information on how new value assignments are added.
Items in ec_point_format_list are ordered according to the sender's
preferences (favorite choice first).
An endpoint that can parse only the uncompressed point format (value
0) includes an extension consisting of the following octets; note
that the first two octets indicate the extension type (Supported
Point Formats Extension):
00 0B 00 02 01 00
An endpoint that in the case of prime fields prefers the compressed
format (ansiX962_compressed_prime, value 1) over the uncompressed
format (value 0), but in the case of characteristic-2 fields prefers
the uncompressed format (value 0) over the compressed format
(ansiX962_compressed_char2, value 2), may indicate these preferences
by including an extension consisting of the following octets:
00 0B 00 04 03 01 00 02
If the client supplies a Supported Points Formats Extension in the
ClientHello, the server may send its own Supported Points Format
extension in the ServerHello. This extension allows a server to
enumerate the point formats it can parse (for the curve that will
appear in its ServerKeyExchange message when using the ECDHE_ECDSA or
ECDHE_RSA key exchange algorithm, or for the curve that is used in
the server's public key that will appear in its Certificate message
when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
The server's Supported Point Formats Extension has the same structure
and semantics as the client's Supported Point Formats Extension.
Note that the server may include items that were not found in the
client's list (e.g., the server may prefer to receive points in
compressed format even when a client cannot parse this format: the
same client may nevertheless be capable of outputting points in
compressed format).
An endpoint that receives a hello message containing a Supported
Point Formats Extension MUST respect the sender's choice of point
formats during the handshake. If no Supported Point Formats
Extension is received this is equivalent to an extension allowing
only the uncompressed point format.
7.4.2.5.4. Early Data Extension
TLS versions before 1.3 have a strict message ordering and do not TLS versions before 1.3 have a strict message ordering and do not
permit additional messages to follow the ClientHello. The EarlyData permit additional messages to follow the ClientHello. The EarlyData
extension allows TLS messages which would otherwise be sent as extension allows TLS messages which would otherwise be sent as
separate records to be instead inserted in the ClientHello. The separate records to be instead inserted in the ClientHello. The
extension simply contains the TLS records which would otherwise have extension simply contains the TLS records which would otherwise have
been included in the client's first flight. been included in the client's first flight.
struct { struct {
TLSCipherText messages<5 .. 2^24-1>; TLSCipherText messages<5 .. 2^24-1>;
skipping to change at page 47, line 10 skipping to change at page 51, line 27
Extra messages for the client's first flight MAY either be Extra messages for the client's first flight MAY either be
transmitted standalone or sent as EarlyData. However, when a client transmitted standalone or sent as EarlyData. However, when a client
does not know whether TLS 1.3 can be negotiated - e.g., because the does not know whether TLS 1.3 can be negotiated - e.g., because the
server may support a prior version of TLS or because of network server may support a prior version of TLS or because of network
intermediaries - it SHOULD use the EarlyData extension. If the intermediaries - it SHOULD use the EarlyData extension. If the
EarlyData extension is used, then clients MUST NOT send any messages EarlyData extension is used, then clients MUST NOT send any messages
other than the ClientHello in their initial flight. other than the ClientHello in their initial flight.
Any data included in EarlyData is not integrated into the handshake Any data included in EarlyData is not integrated into the handshake
hashes directly. E.g., if the ClientKeyExchange is included in hashes directly. E.g., if the ClientKeyShare is included in
EarlyData, then the handshake hashes consist of ClientHello + EarlyData, then the handshake hashes consist of ClientHello +
ServerHello, etc. However, because the ClientKeyExchange is in a ServerHello, etc. However, because the ClientKeyShare is in a
ClientHello extension, it is still hashed transitively. This ClientHello extension, it is still hashed transitively. This
procedure guarantees that the Finished message covers these messages procedure guarantees that the Finished message covers these messages
even if they are ultimately ignored by the server (e.g., because it even if they are ultimately ignored by the server (e.g., because it
is sent to a TLS 1.2 server). TLS 1.3 servers MUST understand is sent to a TLS 1.2 server). TLS 1.3 servers MUST understand
messages sent in EarlyData, and aside from hashing them differently, messages sent in EarlyData, and aside from hashing them differently,
MUST treat them as if they had been sent immediately after the MUST treat them as if they had been sent immediately after the
ClientHello. ClientHello.
Servers MUST NOT send the EarlyData extension. Negotiating TLS 1.3 Servers MUST NOT send the EarlyData extension. Negotiating TLS 1.3
serves as acknowledgement that it was processed as described above. serves as acknowledgement that it was processed as described above.
[[OPEN ISSUE: This is a fairly general mechanism which is possibly [[OPEN ISSUE: This is a fairly general mechanism which is possibly
overkill in the 1-RTT case, where it would potentially be more overkill in the 1-RTT case, where it would potentially be more
attractive to just have a "ClientKeyExchange" extension. However, attractive to just have a "ClientKeyShare" extension. However, for
for the 0-RTT case we will want to send the Certificate, the 0-RTT case we will want to send the Certificate,
CertificateVerify, and application data, so a more general extension CertificateVerify, and application data, so a more general extension
seems appropriate at least until we have determined we don't need it seems appropriate at least until we have determined we don't need it
for 0-RTT.]] for 0-RTT.]]
7.4.2.4. Negotiated DL DHE Groups 7.4.3. Server Key Share Message
Previous versions of TLS before 1.3 allowed the server to specify a
custom DHE group. This version of TLS requires the use of specific
named groups. [I-D.gillmor-tls-negotiated-dl-dhe] describes a
mechanism for negotiating such groups.
If the ClientHello contains a DHE cipher suite, it MUST also include
a "negotiated_dl_dhe_groups" extension. If the server selects a DHE
cipher suite, it MUST respond with that extension to indicate the
selected group. If no acceptable group can be selected across all
cipher suites, then the server MUST generate a fatal
"handshake_failure" alert. [[TODO: Presumably we want to bring
[I-D.gillmor-tls-negotiated-dl-dhe] into this specification.]]
7.4.3. Server Key Exchange Message
When this message will be sent: When this message will be sent:
This message will be sent immediately after the ServerHello This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyExchange message message if the client has provided a ClientKeyShare message which
which is compatible with the selected cipher suite and group is compatible with the selected cipher suite and group parameters.
parameters.
Meaning of this message: Meaning of this message:
This message conveys cryptographic information to allow the client This message conveys cryptographic information to allow the client
to compute the premaster secret: a Diffie-Hellman public key with to compute the premaster secret: a Diffie-Hellman public key with
which the client can complete a key exchange (with the result which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other being the premaster secret) or a public key for some other
algorithm. algorithm.
Structure of this message: Structure of this message:
struct { struct {
opaque dh_Ys<1..2^16-1>; NamedGroup group;
} ServerDiffieHellmanParams; /* Ephemeral DH parameters */ opaque key_exchange<1..2^16-1>;
} ServerKeyShare;
dh_Ys
The server's Diffie-Hellman public value (g^X mod p).
struct { group The named group for the key share offer. This identifies the
select (KeyExchangeAlgorithm) { selected key exchange method from the ClientKeyShare message
case dhe: (Section 7.4.2), identifying which value from the
ServerDiffieHellmanParams; ClientKeyShareOffer the server has accepted as is responding to.
/* may be extended, e.g., for ECDH -- see [RFC4492] */
} params;
} ServerKeyExchange;
params key_exchange Key exchange information. The contents of this field
The server's key exchange parameters. These correspond to the are determined by the value of NamedGroup entry and its
group indicated by the ServerHello message using the cipher suite corresponding definition.
and the "negotiated_dl_dhe_groups"
[I-D.gillmor-tls-negotiated-dl-dhe] extension. [[TODO:
incorporate ECDHE if the WG decides to.]] [[OPEN ISSUE: Note that
we explicitly do not indicate the group here since that's
specified in the ServerHello. We could duplicate it here, but
that seems more confusing since there is room for mismatch.]]
7.4.4. Encrypted Extensions 7.4.4. Encrypted Extensions
When this message will be sent: When this message will be sent:
If this message is sent, it MUST be sent immediately after the If this message is sent, it MUST be sent immediately after the
server's ChangeCipherSpec (and hence as the first handshake server's ChangeCipherSpec (and hence as the first handshake
message after the ServerKeyExchange). message after the ServerKeyShare).
Meaning of this message: Meaning of this message:
The EncryptedExtensions message simply contains any extensions The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to which should be protected, i.e., any which are not needed to
establish the cryptographic context. The same extension types establish the cryptographic context. The same extension types
MUST NOT appear in both the ServerHello and EncryptedExtensions. MUST NOT appear in both the ServerHello and EncryptedExtensions.
If the same extension appears in both locations, the client MUST If the same extension appears in both locations, the client MUST
rely only on the value in the EncryptedExtensions block. [[OPEN rely only on the value in the EncryptedExtensions block. [[OPEN
ISSUE: Should we just produce a canonical list of what goes where ISSUE: Should we just produce a canonical list of what goes where
skipping to change at page 49, line 35 skipping to change at page 53, line 26
A list of extensions. A list of extensions.
7.4.5. Server Certificate 7.4.5. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a Certificate message whenever the agreed- The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document (this includes all key exchange methods defined in this document
except DH_anon). This message will always immediately follow the except DH_anon). This message will always immediately follow the
ChangeCipherSpec which follows the server's ServerKeyExchange ChangeCipherSpec which follows the server's ServerKeyShare
message. message.
Meaning of this message: Meaning of this message:
This message conveys the server's certificate chain to the client. This message conveys the server's certificate chain to the client.
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:
skipping to change at page 54, line 48 skipping to change at page 58, line 38
Because DSA signatures do not contain any secure indication of Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key. Currently, DSA [DSS] may only be hashes may be used with any key. Currently, DSA [DSS] may only be
used with SHA-1. Future revisions of DSS [DSS-3] are expected to used with SHA-1. Future revisions of DSS [DSS-3] are expected to
allow the use of other digest algorithms with DSA, as well as allow the use of other digest algorithms with DSA, as well as
guidance as to which digest algorithms should be used with each guidance as to which digest algorithms should be used with each
key size. In addition, future revisions of [RFC3280] may specify key size. In addition, future revisions of [RFC3280] may specify
mechanisms for certificates to indicate which digest algorithms mechanisms for certificates to indicate which digest algorithms
are to be used with DSA. [[TODO: Update this to deal with DSS-3 are to be used with DSA. [[TODO: Update this to deal with DSS-3
and DSS-4. https://github.com/tlswg/tls13-spec/issues/59]] and DSS-4. https://github.com/tlswg/tls13-spec/issues/59]]
7.4.8. Server Finished 7.4.8. Server Finished
When this message will be sent: When this message will be sent:
The Server's Finished message is the final message sent by the The Server's Finished message is the final message sent by the
server and indicates that the key exchange and authentication server and indicates that the key exchange and authentication
processes were successful. processes were successful.
Meaning of this message: Meaning of this message:
skipping to change at page 59, line 30 skipping to change at page 63, line 16
A conventional Diffie-Hellman computation is performed. The A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the contain all zero bits are stripped before it is used as the
pre_master_secret. pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate. be either ephemeral or contained within the server's certificate.
8.1.2. Elliptic Curve Diffie-Hellman
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the premaster secret is the x-coordinate of
the ECDH shared secret elliptic curve point represented as an octet
string. Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.
(Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything
other than for computing the master secret.)
9. Mandatory Cipher Suites 9. Mandatory 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 cipher otherwise, a TLS-compliant application MUST implement the cipher
suite TODO:Needs to be selected [1]. (See Appendix A.5 for the suite TODO:Needs to be selected [1]. (See Appendix A.5 for the
definition). definition).
10. Application Data Protocol 10. Application Data Protocol
Application data messages are carried by the record layer and are Application data messages are carried by the record layer and are
skipping to change at page 60, line 39 skipping to change at page 64, line 44
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
This document also uses a registry originally created in [RFC4366]. This document also uses a registry originally created in [RFC4366].
IANA has updated it to reference this document. The registry and its IANA has updated it to reference this document. The registry and its
allocation policy (unchanged from [RFC4366]) is listed below: allocation policy (unchanged from [RFC4366]) is listed below:
- TLS ExtensionType Registry: Future values are allocated via IETF - TLS ExtensionType Registry: Future values are allocated via IETF
Consensus [RFC2434]. IANA has updated this registry to include Consensus [RFC2434]. IANA has updated this registry to include
the signature_algorithms extension and its corresponding value the signature_algorithms extension and its corresponding value
(see Section 7.4.2.3). (see Section 7.4.2.5).
This document also uses two registries originally created in
[RFC4492]. IANA [should update/has updated] it to reference this
document. The registries and their allocation policies are listed
below.
- TLS NamedCurve registry: Future values are allocated via IETF
Consensus [RFC2434].
- TLS ECPointFormat Registry: Future values are allocated via IETF
Consensus [RFC2434].
In addition, this document defines two new registries to be In addition, this document defines two new registries to be
maintained by IANA: maintained by IANA:
- TLS SignatureAlgorithm Registry: The registry has been initially - TLS SignatureAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.2.3.1. Future populated with the values described in Section 7.4.2.5.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
- TLS HashAlgorithm Registry: The registry has been initially - TLS HashAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.2.3.1. Future populated with the values described in Section 7.4.2.5.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
13. References 13. References
13.1. Normative References 13.1. Normative References
[AES] National Institute of Standards [AES] National Institute of Standards and Technology,
and Technology, "Specification "Specification for the Advanced Encryption Standard
for the Advanced Encryption (AES)", NIST FIPS 197, November 2001.
Standard (AES)", NIST FIPS 197,
November 2001.
[DSS] National Institute of Standards [DSS] National Institute of Standards and Technology, U.S.
and Technology, U.S. Department Department of Commerce, "Digital Signature Standard", NIST
of Commerce, "Digital Signature FIPS PUB 186-2, 2000.
Standard", NIST FIPS PUB 186-2,
2000.
[RFC1321] Rivest, R., "The MD5 Message- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Digest Algorithm", RFC 1321, April 1992.
April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
R. Canetti, "HMAC: Keyed-Hashing Hashing for Message Authentication", RFC 2104, February
for Message Authentication", 1997.
RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
in RFCs to Indicate Requirement Requirement Levels", BCP 14, RFC 2119, March 1997.
Levels", BCP 14, RFC 2119,
March 1997.
[RFC2434] Narten, T. and H. Alvestrand, [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
"Guidelines for Writing an IANA IANA Considerations Section in RFCs", BCP 26, RFC 2434,
Considerations Section in RFCs", October 1998.
BCP 26, RFC 2434, October 1998.
[RFC3280] Housley, R., Polk, W., Ford, W., [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
and D. Solo, "Internet X.509 X.509 Public Key Infrastructure Certificate and
Public Key Infrastructure Certificate Revocation List (CRL) Profile", RFC 3280,
Certificate and Certificate April 2002.
Revocation List (CRL) Profile",
RFC 3280, April 2002.
[RFC3447] Jonsson, J. and B. Kaliski, [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Standards (PKCS) #1: RSA Version 2.1", RFC 3447, February 2003.
Cryptography Specifications
Version 2.1", RFC 3447,
February 2003.
[RFC5288] Salowey, J., Choudhury, A., and [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
D. McGrew, "AES Galois Counter Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
Mode (GCM) Cipher Suites for August 2008.
TLS", RFC 5288, August 2008.
[SCH] Schneier, B., "Applied [SCH] Schneier, B., "Applied Cryptography: Protocols,
Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.", 1996.
Algorithms, and Source Code in
C, 2nd ed.", 1996.
[SHS] National Institute of Standards [SHS] National Institute of Standards and Technology, U.S.
and Technology, U.S. Department Department of Commerce, "Secure Hash Standard", NIST FIPS
of Commerce, "Secure Hash PUB 180-2, August 2002.
Standard", NIST FIPS PUB 180-2,
August 2002.
[TRIPLEDES] National Institute of Standards [TRIPLEDES]
and Technology, "Recommendation National Institute of Standards and Technology,
for the Triple Data Encryption "Recommendation for the Triple Data Encryption Algorithm
Algorithm (TDEA) Block Cipher", (TDEA) Block Cipher", NIST Special Publication 800-67, May
NIST Special Publication 800-67, 2004.
May 2004.
[X680] ITU-T, "Information technology - [X680] ITU-T, "Information technology - Abstract Syntax Notation
Abstract Syntax Notation One One (ASN.1): Specification of basic notation", ISO/IEC
(ASN.1): Specification of basic 8824-1:2002, 2002.
notation", ISO/IEC 8824-1:2002,
2002.
[X690] ITU-T, "Information technology - [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical
Specification of Basic Encoding Encoding Rules (CER) and Distinguished Encoding Rules
Rules (BER), Canonical Encoding (DER)", ISO/IEC 8825-1:2002, 2002.
Rules (CER) and Distinguished
Encoding Rules (DER)", ISO/ [X962] ANSI, "Public Key Cryptography For The Financial Services
IEC 8825-1:2002, 2002. Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998.
13.2. Informative References 13.2. Informative References
[BLEI] Bleichenbacher, D., "Chosen [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS", CRYPTO98
Protocols Based on RSA LNCS vol. 1462, pages: 1-12, 1998, Advances in Cryptology,
Encryption Standard PKCS", 1998.
CRYPTO98 LNCS vol. 1462, pages:
1-12, 1998, Advances in
Cryptology, 1998.
[CBCATT] Moeller, B., "Security of CBC [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Ciphersuites in SSL/TLS: Problems and Countermeasures", May 2004,
Problems and Countermeasures", <http://www.openssl.org/~bodo/tls-cbc.txt>.
May 2004, <http://
www.openssl.org/~bodo/
tls-cbc.txt>.
[CCM] "NIST Special Publication 800- [CCM] "NIST Special Publication 800-38C: The CCM Mode for
38C: The CCM Mode for Authentication and Confidentiality", May 2004,
Authentication and <http://csrc.nist.gov/publications/nistpubs/800-38C/
Confidentiality", May 2004, <htt SP800-38C.pdf>.
p://csrc.nist.gov/publications/
nistpubs/800-38C/SP800-38C.pdf>.
[DES] "Data Encryption Standard [DES] "Data Encryption Standard (DES)", NIST FIPS PUB 46-3,
(DES)", NIST FIPS PUB 46-3, October 1999.
October 1999.
[DSS-3] National Institute of Standards [DSS-3] National Institute of Standards and Technology, U.S.,
and Technology, U.S., "Digital "Digital Signature Standard", NIST FIPS PUB 186-3 Draft,
Signature Standard", NIST FIPS 2006.
PUB 186-3 Draft, 2006.
[ECDSA] American National Standards [ECDSA] American National Standards Institute, "Public Key
Institute, "Public Key Cryptography for the Financial Services Industry: The
Cryptography for the Financial Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
Services Industry: The Elliptic ANS X9.62-2005, November 2005.
Curve Digital Signature
Algorithm (ECDSA)", ANSI ANS
X9.62-2005, November 2005.
[ENCAUTH] Krawczyk, H., "The Order of [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)",
for Protecting Communications 2001.
(Or: How Secure is SSL?)", 2001.
[FI06] "Bleichenbacher's RSA signature [FI06] "Bleichenbacher's RSA signature forgery based on
forgery based on implementation implementation error", August 2006, <http://www.imc.org/
error", August 2006, <http:// ietf-openpgp/mail-archive/msg14307.html>.
www.imc.org/ietf-openpgp/
mail-archive/msg14307.html>.
[GCM] Dworkin, M., "Recommendation for [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Block Cipher Modes of Operation: Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Galois/Counter Mode (GCM) and Special Publication 800-38D, November 2007.
GMAC", NIST Special Publication
800-38D, November 2007.
[I-D.gillmor-tls-negotiated-dl-dhe] Gillmor, D., "Negotiated [I-D.ietf-tls-negotiated-ff-dhe]
Discrete Log Diffie-Hellman Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for TLS", d Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
raft-gillmor-tls-negotiated-dl- ff-dhe-02 (work in progress), October 2014.
dhe-02 (work in progress),
April 2014.
[PKCS6] RSA Laboratories, "PKCS #6: RSA [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
Extended Certificate Syntax Syntax Standard, version 1.5", November 1993.
Standard, version 1.5",
November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Cryptographic Message Syntax Syntax Standard, version 1.5", November 1993.
Standard, version 1.5",
November 1993.
[RFC0793] Postel, J., "Transmission [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
Control Protocol", STD 7, 793, September 1981.
RFC 793, September 1981.
[RFC1948] Bellovin, S., "Defending Against [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
Sequence Number Attacks", RFC 1948, May 1996.
RFC 1948, May 1996.
[RFC2246] Dierks, T. and C. Allen, "The [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
TLS Protocol Version 1.0", RFC 2246, January 1999.
RFC 2246, January 1999.
[RFC2785] Zuccherato, R., "Methods for [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/
Attacks on the Diffie-Hellman MIME", RFC 2785, March 2000.
Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[RFC3268] Chown, P., "Advanced Encryption [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Standard (AES) Ciphersuites for Ciphersuites for Transport Layer Security (TLS)", RFC
Transport Layer Security (TLS)", 3268, June 2002.
RFC 3268, June 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)",
Diffie-Hellman groups for RFC 3526, May 2003.
Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3766] Orman, H. and P. Hoffman, [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
"Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86,
Public Keys Used For Exchanging RFC 3766, April 2004.
Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4086] Eastlake, D., Schiller, J., and [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Requirements for Security",
BCP 106, RFC 4086, June 2005.
[RFC4302] Kent, S., "IP Authentication [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
Header", RFC 4302, 2005.
December 2005.
[RFC4303] Kent, S., "IP Encapsulating [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
Security Payload (ESP)", 4303, December 2005.
RFC 4303, December 2005.
[RFC4307] Schiller, J., "Cryptographic [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
Internet Key Exchange Version 2 December 2005.
(IKEv2)", RFC 4307,
December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Transport Layer Security (TLS) (TLS) Protocol Version 1.1", RFC 4346, April 2006.
Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Hopwood, D., Mikkelsen, J., and and T. Wright, "Transport Layer Security (TLS)
T. Wright, "Transport Layer Extensions", RFC 4366, April 2006.
Security (TLS) Extensions",
RFC 4366, April 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
Moeller, "Elliptic Curve for Transport Layer Security (TLS)", RFC 4492, May 2006.
Cryptography (ECC) Cipher Suites
for Transport Layer Security
(TLS)", RFC 4492, May 2006.
[RFC4506] Eisler, M., "XDR: External Data [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
Representation Standard", STD 67, RFC 4506, May 2006.
STD 67, RFC 4506, May 2006.
[RFC5081] Mavrogiannopoulos, N., "Using [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
OpenPGP Keys for Transport Layer Layer Security (TLS) Authentication", RFC 5081, November
Security (TLS) Authentication", 2007.
RFC 5081, November 2007.
[RFC5116] McGrew, D., "An Interface and [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Algorithms for Authenticated Encryption", RFC 5116, January 2008.
Encryption", RFC 5116,
January 2008.
[RSA] Rivest, R., Shamir, A., and L. [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Adleman, "A Method for Obtaining Obtaining Digital Signatures and Public-Key
Digital Signatures and Public- Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
Key Cryptosystems", 120-126., February 1978.
Communications of the ACM v. 21,
n. 2, pp. 120-126.,
February 1978.
[SSL2] Netscape Communications Corp., [SSL2] Netscape Communications Corp., "The SSL Protocol",
"The SSL Protocol", February 1995.
February 1995.
[SSL3] Freier, A., Karlton, P., and P. [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0
Kocher, "The SSL 3.0 Protocol", Protocol", November 1996.
November 1996.
[TIMING] Boneh, D. and D. Brumley, [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are
"Remote timing attacks are practical", USENIX Security Symposium, 2003.
practical", USENIX Security
Symposium, 2003.
[TLSEXT] Eastlake 3rd, D., "Transport [TLSEXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Layer Security (TLS) Extensions: Extensions: Extension Definitions", February 2008.
Extension Definitions",
February 2008.
[X501] "Information Technology - Open [X501] "Information Technology - Open Systems Interconnection -
Systems Interconnection - The The Directory: Models", ITU-T X.501, 1993.
Directory: Models", ITU-T X.501,
1993.
URIs 13.3. URIs
[1] <https://github.com/tlswg/tls13-spec/issues/32> [1] https://github.com/tlswg/tls13-spec/issues/32
[2] <mailto:tls@ietf.org> [2] mailto:tls@ietf.org
Appendix A. Protocol Data Structures and Constant Values Appendix A. Protocol Data Structures and Constant Values
This section describes protocol types and constants. This section describes protocol types and constants.
[[TODO: Clean this up to match the in-text description.]] [[TODO: Clean this up to match the in-text description.]]
A.1. Record Layer A.1. Record Layer
struct { struct {
skipping to change at page 69, line 6 skipping to change at page 72, line 4
unsupported_extension(110), /* new */ unsupported_extension(110), /* new */
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.4. Handshake Protocol A.4. Handshake Protocol
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12), hello_retry_request(4),
certificate(11), server_key_share (17),
certificate_request(13), server_hello_done(14), certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16), certificate_verify(15), client_key_share(18),
finished(20), finished(20),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_requst: HelloRetryRequest;
case certificate: Certificate; case certificate: Certificate;
case server_key_exchange: ServerKeyExchange; case server_key_share: ServerKeyShare;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone; case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_share: ClientKeyShare;
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
A.4.1. Hello Messages A.4.1. Hello Messages
struct { } HelloRequest; struct { } HelloRequest;
struct { struct {
uint32 gmt_unix_time; opaque random_bytes[32];
opaque random_bytes[28];
} Random; } Random;
opaque SessionID<0..32>; opaque SessionID<0..32>;
uint8 CipherSuite[2]; uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
skipping to change at page 71, line 4 skipping to change at page 74, line 6
struct { struct {
HashAlgorithm hash; HashAlgorithm hash;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
A.4.2. Server Authentication and Key Exchange Messages A.4.2. Server Authentication and Key Exchange Messages
opaque ASN1Cert<2^24-1>; opaque ASN1Cert<2^24-1>;
struct { struct {
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
enum { dhe_dss, dhe_rsa, dh_anon
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; NamedGroup group;
opaque dh_g<1..2^16-1>; opaque key_exchange<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; } ServerKeyShare;
} ServerDHParams; /* Ephemeral DH parameters */
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
/* may be extended, e.g., for ECDH --- see [RFC4492] */
} ServerKeyExchange;
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), fortezza_dms_RESERVED(20),
(255) (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
struct { } ServerHelloDone; struct { } ServerHelloDone;
A.4.3. Client Authentication and Key Exchange Messages A.4.3. Client Authentication and Key Exchange Messages
struct { struct {
select (KeyExchangeAlgorithm) { ClientKeyShareOffer offers<0..2^16-1>;
case dhe_dss: } ClientKeyShare;
case dhe_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct { struct {
select (PublicValueEncoding) { NamedGroup group;
case implicit: struct {}; opaque key_exchange<1..2^16-1>;
case explicit: opaque DH_Yc<1..2^16-1>; } ClientKeyShareOffer;
} dh_public;
} ClientDiffieHellmanPublic;
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages[handshake_messages_length]; opaque handshake_messages[handshake_messages_length];
} }
} CertificateVerify; } CertificateVerify;
A.4.4. Handshake Finalization Message A.4.4. Handshake Finalization Message
struct { struct {
skipping to change at page 73, line 10 skipping to change at page 75, line 28
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST TLS connection during the first handshake on that channel, but MUST
NOT be negotiated, as it provides no more protection than an NOT be negotiated, as it provides no more protection than an
unsecured connection. unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
The following cipher suite definitions, defined in {{RFC5288}, are The following cipher suite definitions, defined in {{RFC5288}, are
used for server-authenticated (and optionally client-authenticated) used for server-authenticated (and optionally client-authenticated)
Diffie-Hellman. DH denotes cipher suites in which the server's Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the
certificate contains the Diffie-Hellman parameters signed by the Diffie-Hellman parameters are signed by a signature-capable
certificate authority (CA). DHE denotes ephemeral Diffie-Hellman,
where the Diffie-Hellman parameters are signed by a signature-capable
certificate, which has been signed by the CA. The signing algorithm certificate, which has been signed by the CA. The signing algorithm
used by the server is specified after the DHE component of the used by the server is specified after the DHE component of the
CipherSuite name. The server can request any signature-capable CipherSuite name. The server can request any signature-capable
certificate from the client for client authentication, or it may certificate from the client for client authentication.
request a Diffie-Hellman certificate. Any Diffie-Hellman certificate
provided by the client must use the parameters (group and generator)
described by the server.
CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C} CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D} CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E} CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F} CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2} CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3} CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
The following cipher suites, defined in {{RFC5288}, are used for The following cipher suite definitions, defined in {{RFC5289}, are
completely anonymous Diffie-Hellman communications in which neither used for server-authenticated (and optionally client-authenticated)
party is authenticated. Note that this mode is vulnerable to man-in- Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie-
the-middle attacks. Using this mode therefore is of limited use: Hellman, where the Diffie-Hellman parameters are signed by a
These cipher suites MUST NOT be used by TLS 1.2 implementations signature-capable certificate, which has been signed by the CA. The
unless the application layer has specifically requested to allow signing algorithm used by the server is specified after the DHE
anonymous key exchange. (Anonymous key exchange may sometimes be component of the CipherSuite name. The server can request any
acceptable, for example, to support opportunistic encryption when no signature-capable certificate from the client for client
set-up for authentication is in place, or when TLS is used as part of authentication.
more complex security protocols that have other means to ensure
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2B};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x2C};
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F};
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
The following ciphers, defined in [RFC5288], are used for completely
anonymous Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks. Using this mode therefore is of limited use: These
cipher suites MUST NOT be used by TLS 1.2 implementations unless the
application layer has specifically requested to allow anonymous key
exchange. (Anonymous key exchange may sometimes be acceptable, for
example, to support opportunistic encryption when no set-up for
authentication is in place, or when TLS is used as part of more
complex security protocols that have other means to ensure
authentication.) authentication.)
CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6} CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}
CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7} CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}
[[TODO: Add all the defined AEAD ciphers. This currently only lists [[TODO: Add all the defined AEAD ciphers. This currently only lists
GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using
non-anonymous key exchange without actually verifying the key non-anonymous key exchange without actually verifying the key
exchange is essentially equivalent to anonymous key exchange, and the exchange is essentially equivalent to anonymous key exchange, and the
same precautions apply. While non-anonymous key exchange will same precautions apply. While non-anonymous key exchange will
generally involve a higher computational and communicational cost generally involve a higher computational and communicational cost
than anonymous key exchange, it may be in the interest of than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange. application layer is allowing anonymous key exchange.
New cipher suite values have been assigned by IANA as described in The PRFs SHALL be as follows:
o For cipher suites ending with _SHA256, the PRF is the TLS PRF with
SHA-256 as the hash function.
o For cipher suites ending with _SHA384, the PRF is the TLS PRF with
SHA-384 as the hash function.
New cipher suite values are been assigned by IANA as described in
Section 12. Section 12.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL reserved to avoid collision with Fortezza-based cipher suites in SSL
3. 3.
A.6. The Security Parameters A.6. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS record layer in order Protocol and provided as parameters to the TLS record layer in order
skipping to change at page 76, line 26 skipping to change at page 79, line 13
connection connection
A connection is a transport (in the OSI layering model definition) A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such that provides a suitable type of service. For TLS, such
connections are peer-to-peer relationships. The connections are connections are peer-to-peer relationships. The connections are
transient. Every connection is associated with one session. transient. Every connection is associated with one session.
Digital Signature Standard (DSS) Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and Algorithm, approved by the National Institute of Standards and
Technology, defined in NIST FIPS PUB 186-2, "Digital Signature Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
Standard", published January 2000 by the U.S. Department of Standard", published January 2000 by the U.S. Department of
Commerce [DSS]. A significant update [DSS-3] has been drafted and Commerce [DSS]. A significant update [DSS-3] has been drafted and
was published in March 2006. was published in March 2006.
digital signatures digital signatures
Digital signatures utilize public key cryptography and one-way Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate. authenticated, and is difficult to forge or repudiate.
handshake handshake
An initial negotiation between client and server that establishes An initial negotiation between client and server that establishes
skipping to change at page 85, line 33 skipping to change at page 88, line 23
master_secret (see Section 8.1). The master_secret is required to master_secret (see Section 8.1). The master_secret is required to
generate the Finished messages and record protection keys (see generate the Finished messages and record protection keys (see
Section 7.4.8 and Section 6.3). By sending a correct Finished Section 7.4.8 and Section 6.3). By sending a correct Finished
message, parties thus prove that they know the correct message, parties thus prove that they know the correct
pre_master_secret. pre_master_secret.
F.1.1.1. Anonymous Key Exchange F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using Diffie-Hellman Completely anonymous sessions can be established using Diffie-Hellman
for key exchange. The server's public parameters are contained in for key exchange. The server's public parameters are contained in
the server key exchange message, and the client's are sent in the the server key share message, and the client's are sent in the client
client key exchange message. Eavesdroppers who do not know the key share message. Eavesdroppers who do not know the private values
private values should not be able to find the Diffie-Hellman result should not be able to find the Diffie-Hellman result (i.e., the
(i.e., the pre_master_secret). pre_master_secret).
Warning: Completely anonymous connections only provide protection Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-proof against passive eavesdropping. Unless an independent tamper-proof
channel is used to verify that the Finished messages were not channel is used to verify that the Finished messages were not
replaced by an attacker, server authentication is required in replaced by an attacker, server authentication is required in
environments where active man-in-the-middle attacks are a concern. environments where active man-in-the-middle attacks are a concern.
F.1.1.2. Diffie-Hellman Key Exchange with Authentication F.1.1.2. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the server can either When Diffie-Hellman key exchange is used, the client and server use
supply a certificate containing fixed Diffie-Hellman parameters or the client key exchange and server key exchange messages to send
use the server key exchange message to send a set of temporary temporary Diffie-Hellman parameters. The signature in the
Diffie-Hellman parameters signed with a DSA or RSA certificate. certificate verify message (if present) covers the entire handshake
Temporary parameters are hashed with the hello.random values before up to that point and thus attests the certificate holder's desire to
signing to ensure that attackers do not replay old parameters. In use the the ephemeral DHE keys.
either case, the client can verify the certificate or signature to
ensure that the parameters belong to the server.
If the client has a certificate containing fixed Diffie-Hellman
parameters, its certificate contains the information required to
complete the key exchange. Note that in this case the client and
server will generate the same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in memory any longer than necessary,
it should be converted into the master_secret as soon as possible.
Client Diffie-Hellman parameters must be compatible with those
supplied by the server for the key exchange to work.
If the client has a standard DSA or RSA certificate or is
unauthenticated, it sends a set of temporary parameters to the server
in the client key exchange message, then optionally uses a
certificate verify message to authenticate itself.
If the same DH keypair is to be used for multiple handshakes, either
because the client or server has a certificate containing a fixed DH
keypair or because the server is reusing DH keys, care must be taken
to prevent small subgroup attacks. Implementations SHOULD follow the
guidelines found in [RFC2785].
Small subgroup attacks are most easily avoided by using one of the Peers SHOULD validate each other's public key Y (dh_Ys offered by the
DHE cipher suites and generating a fresh DH private key (X) for each server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
handshake. If a suitable base (such as 2) is chosen, g^X mod p can This simple check ensures that the remote peer is properly behaved
be computed very quickly; therefore, the performance cost is and isn't forcing the local system into a small subgroup.
minimized. Additionally, using a fresh key for each handshake
provides Perfect Forward Secrecy. Implementations SHOULD generate a
new X for each handshake when using DHE cipher suites.
Because TLS allows the server to provide arbitrary DH groups, the Additionally, using a fresh key for each handshake provides Perfect
client should verify that the DH group is of suitable size as defined Forward Secrecy. Implementations SHOULD generate a new X for each
by local policy. The client SHOULD also verify that the DH public handshake when using DHE cipher suites.
exponent appears to be of adequate size. [RFC3766] provides a useful
guide to the strength of various group sizes. The server MAY choose
to assist the client by providing a known group, such as those
defined in [RFC4307] or [RFC3526]. These can be verified by simple
comparison.
F.1.2. Version Rollback Attacks F.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0, Because TLS includes substantial improvements over SSL Version 2.0,
attackers may try to make TLS-capable clients and servers fall back attackers may try to make TLS-capable clients and servers fall back
to Version 2.0. This attack can occur if (and only if) two TLS- to Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an SSL 2.0 handshake. capable parties use an SSL 2.0 handshake.
Although the solution using non-random PKCS #1 block type 2 message Although the solution using non-random PKCS #1 block type 2 message
padding is inelegant, it provides a reasonably secure way for Version padding is inelegant, it provides a reasonably secure way for Version
skipping to change at page 89, line 12 skipping to change at page 91, line 15
certificate authorities are acceptable; a dishonest certificate certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage. authority can do tremendous damage.
Appendix G. Working Group Information Appendix G. Working Group Information
The discussion list for the IETF TLS working group is located at the The discussion list for the IETF TLS working group is located at the
e-mail address tls@ietf.org [2]. Information on the group and e-mail address tls@ietf.org [2]. Information on the group and
information on how to subscribe to the list is at information on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/tls https://www1.ietf.org/mailman/listinfo/tls
Archives of the list can be found at: Archives of the list can be found at: http://www.ietf.org/mail-
http://www.ietf.org/mail-archive/web/tls/current/index.html archive/web/tls/current/index.html
Appendix H. Contributors Appendix H. Contributors
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
Martin Abadi Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
Steven M. Bellovin Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Simon Blake-Wilson Simon Blake-Wilson (co-author of RFC4492)
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
Nelson Bolyard
Sun Microsystems, Inc.
nelson@bolyard.com (co-author of RFC4492)
Ran Canetti Ran Canetti
IBM IBM
canetti@watson.ibm.com canetti@watson.ibm.com
Pete Chown Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
Taher Elgamal Taher Elgamal
taher@securify.com taher@securify.com
skipping to change at page 89, line 44 skipping to change at page 92, line 4
IBM IBM
canetti@watson.ibm.com canetti@watson.ibm.com
Pete Chown Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
Taher Elgamal Taher Elgamal
taher@securify.com taher@securify.com
Securify Securify
Pasi Eronen Pasi Eronen
pasi.eronen@nokia.com pasi.eronen@nokia.com
Nokia Nokia
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
Vipul Gupta (co-author of RFC4492)
Sun Microsystems Laboratories
vipul.gupta@sun.com
Kipp Hickman Kipp Hickman
Chris Hawk (co-author of RFC4492)
Corriente Networks LLC
chris@corriente.net
Alfred Hoenes Alfred Hoenes
David Hopwood David Hopwood
Independent Consultant Independent Consultant
david.hopwood@blueyonder.co.uk david.hopwood@blueyonder.co.uk
Daniel Kahn Gillmor
ACLU
dkg@fifthhorseman.net
Phil Karlton (co-author of SSLv3) Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3) Paul Kocher (co-author of SSLv3)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
Hugo Krawczyk Hugo Krawczyk
IBM IBM
hugo@ee.technion.ac.il hugo@ee.technion.ac.il
Jan Mikkelsen Jan Mikkelsen
Transactionware Transactionware
janm@transactionware.com janm@transactionware.com
Bodo Moeller (co-author of RFC4492)
Google
bodo@openssl.org
Magnus Nystrom Magnus Nystrom
RSA Security RSA Security
magnus@rsasecurity.com magnus@rsasecurity.com
Alfredo Pironti
INRIA
alfredo.pironti@inria.fr
Robert Relyea Robert Relyea
Netscape Communications Netscape Communications
relyea@netscape.com relyea@netscape.com
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
Martin Thomson
Mozilla
mt@mozilla.com
Tom Weinstein Tom Weinstein
Tim Wright Tim Wright
Vodafone Vodafone
timothy.wright@vodafone.com timothy.wright@vodafone.com
Authors' Addresses Authors' Addresses
Tim Dierks Tim Dierks
Independent Independent
 End of changes. 162 change blocks. 
612 lines changed or deleted 746 lines changed or added

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