draft-ietf-tls-tls13-05.txt   draft-ietf-tls-tls13-06.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 3268, 4346, 4366, 5246 (if March 09, 2015 Obsoletes: 3268, 4346, 4366, 5246 (if June 29, 2015
approved) approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2015 Expires: December 31, 2015
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-05 draft-ietf-tls-tls13-06
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 September 10, 2015. This Internet-Draft will expire on December 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 10 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12 4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12
4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 16 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. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24 7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24
7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25 7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25
7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25 7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26
7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 29 7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 30
7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 33 7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 34
7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 34 7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 35
7.3.2. Client Key Share Message . . . . . . . . . . . . . . 37 7.3.2. Client Key Share . . . . . . . . . . . . . . . . . . 38
7.3.3. Server Key Share Message . . . . . . . . . . . . . . 48 7.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 49
7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 49 7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 50
7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 49 7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 50
7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 52 7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 53
7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 53 7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 54
7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 55 7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 56
7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 56 7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 57
7.3.10. Client Certificate Verify . . . . . . . . . . . . . . 58 7.3.10. Client Certificate Verify . . . . . . . . . . . . . . 59
8. Cryptographic Computations . . . . . . . . . . . . . . . . . 58 8. Cryptographic Computations . . . . . . . . . . . . . . . . . 59
8.1. Computing the Master Secret . . . . . . . . . . . . . . . 59 8.1. Computing the Master Secret . . . . . . . . . . . . . . . 60
8.1.1. The Session Hash . . . . . . . . . . . . . . . . . . 60 8.1.1. The Session Hash . . . . . . . . . . . . . . . . . . 61
8.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 61 8.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 62
8.1.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 61 8.1.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 62
9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 61 9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 62
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 61 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 62
11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 63
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . 63 13.1. Normative References . . . . . . . . . . . . . . . . . . 64
13.2. Informative References . . . . . . . . . . . . . . . . . 65 13.2. Informative References . . . . . . . . . . . . . . . . . 66
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix A. Protocol Data Structures and Constant Values . . . . 69 Appendix A. Protocol Data Structures and Constant Values . . . . 69
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70
A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71
A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 74 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 74
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 74 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 74
A.3.4. Handshake Finalization Messages . . . . . . . . . . . 75 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 75
A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75 A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75
A.5. The Security Parameters . . . . . . . . . . . . . . . . . 77 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 76
A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 77 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 77
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 78 Appendix B. Cipher Suite Definitions . . . . . . . . . . . . . . 78
Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 81 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 78
Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 81 C.1. Random Number Generation and Seeding . . . . . . . . . . 78
D.1. Random Number Generation and Seeding . . . . . . . . . . 81 C.2. Certificates and Authentication . . . . . . . . . . . . . 78
D.2. Certificates and Authentication . . . . . . . . . . . . . 82 C.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 79
D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 82 C.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 79
D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 82 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 80
Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 83 D.1. Negotiating with an older server . . . . . . . . . . . . 80
E.1. Compatibility with prior versions . . . . . . . . . . . . 83 D.2. Negotiating with an older client . . . . . . . . . . . . 81
E.2. Compatibility with SSL . . . . . . . . . . . . . . . . . 85 D.3. Backwards Compatibility Security Restrictions . . . . . . 81
Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 85 Appendix E. Security Analysis . . . . . . . . . . . . . . . . . 82
F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 85 E.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 82
F.1.1. Authentication and Key Exchange . . . . . . . . . . . 86 E.1.1. Authentication and Key Exchange . . . . . . . . . . . 83
F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 87 E.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 84
F.1.3. Detecting Attacks Against the Handshake Protocol . . 87 E.1.3. Detecting Attacks Against the Handshake Protocol . . 84
F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 87 E.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 84
F.2. Protecting Application Data . . . . . . . . . . . . . . . 88 E.2. Protecting Application Data . . . . . . . . . . . . . . . 85
F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 88 E.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 85
F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 89 E.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 86
Appendix G. Working Group Information . . . . . . . . . . . . . 89 Appendix F. Working Group Information . . . . . . . . . . . . . 86
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 89 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 86
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 5, line 27 skipping to change at page 5, line 27
the communication. the communication.
One advantage of TLS is that it is application protocol independent. One advantage of TLS is that it is application protocol independent.
Higher-level protocols can layer on top of the TLS protocol Higher-level protocols can layer on top of the TLS protocol
transparently. The TLS standard, however, does not specify how transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS. of protocols that run on top of TLS.
1.1. Requirements Terminology 1.1. Conventions and 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
The following terms are used:
client: The endpoint initiating the TLS connection.
connection: A transport-layer connection between two endpoints.
endpoint: Either the client or server of the connection.
handshake: An initial negotiation between client and server that
establishes the parameters of their transactions.
peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is remote to the primary subject of
discussion.
receiver: An endpoint that is receiving records.
sender: An endpoint that is transmitting records.
session: An association between a client and a server resulting from
a handshake.
server: The endpoint which did not initiate the TLS connection.
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-06
- Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field.
- Update format of signatures with context.
- Remove explicit IV.
draft-05 draft-05
- Prohibit SSL negotiation for backwards compatibility. - Prohibit SSL negotiation for backwards compatibility.
- Fix which MS is used for exporters. - Fix which MS is used for exporters.
draft-04 draft-04
- Modify key computations to include session hash. - Modify key computations to include session hash.
- Remove ChangeCipherSpec - Remove ChangeCipherSpec
- Renumber the new handshake messages to be somewhat more consistent - Renumber the new handshake messages to be somewhat more consistent
with existing convention and to remove a duplicate registration. with existing convention and to remove a duplicate registration.
- Remove renegotiation. - Remove renegotiation.
- Update format of signatures with context.
- Remove point format negotiation. - Remove point format negotiation.
draft-03 draft-03
- Remove GMT time. - Remove GMT time.
- Merge in support for ECC from RFC 4492 but without explicit - Merge in support for ECC from RFC 4492 but without explicit
curves. curves.
- Remove the unnecessary length field from the AD input to AEAD - Remove the unnecessary length field from the AD input to AEAD
skipping to change at page 15, line 22 skipping to change at page 15, line 37
5. The Pseudorandom Function 5. The Pseudorandom Function
A construction is required to do expansion of secrets into blocks of A construction is required to do expansion of secrets into blocks of
data for the purposes of key generation or validation. This data for the purposes of key generation or validation. This
pseudorandom function (PRF) takes as input a secret, a seed, and an pseudorandom function (PRF) takes as input a secret, a seed, and an
identifying label and produces an output of arbitrary length. identifying label and produces an output of arbitrary length.
In this section, we define one PRF, based on HMAC [RFC2104]. This In this section, we define one PRF, based on HMAC [RFC2104]. This
PRF with the SHA-256 hash function is used for all cipher suites PRF with the SHA-256 hash function is used for all cipher suites
defined in this document and in TLS documents published prior to this defined in this document and in TLS documents published prior to this
document when TLS 1.2 is negotiated. New cipher suites MUST document when TLS 1.2 or later is negotiated. New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function. SHA-256 or a stronger standard hash function.
First, we define a data expansion function, P_hash(secret, data), First, we define a data expansion function, P_hash(secret, data),
that uses a single hash function to expand a secret and seed into an that uses a single hash function to expand a secret and seed into an
arbitrary quantity of output: arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ... HMAC_hash(secret, A(3) + seed) + ...
skipping to change at page 16, line 31 skipping to change at page 16, line 45
Three protocols that use the record protocol are described in this Three protocols that use the record protocol are described in this
document: the handshake protocol, the alert protocol, and the document: the handshake protocol, the alert protocol, and the
application data protocol. In order to allow extension of the TLS application data protocol. In order to allow extension of the TLS
protocol, additional record content types can be supported by the protocol, additional record content types can be supported by the
record protocol. New record content type values are assigned by IANA record protocol. New record content type values are assigned by IANA
in the TLS Content Type Registry as described in Section 12. in the TLS Content Type Registry as described in Section 12.
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST send an implementation receives an unexpected record type, it MUST send an
unexpected_message alert. "unexpected_message" alert.
Any protocol designed for use over TLS must be carefully designed to Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. As a practical matter, deal with all possible attacks against it. As a practical matter,
this means that the protocol designer must be aware of what security this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on properties TLS does and does not provide and cannot safely rely on
the latter. the latter.
Note in particular that type and length of a record are not protected Note in particular that type and length of a record are not protected
by encryption. If this information is itself sensitive, application by encryption. If this information is itself sensitive, application
designers may wish to take steps (padding, cover traffic) to minimize designers may wish to take steps (padding, cover traffic) to minimize
skipping to change at page 17, line 25 skipping to change at page 17, line 39
An algorithm used to generate keys from the master secret (see An algorithm used to generate keys from the master secret (see
Section 5 and Section 6.3). Section 5 and Section 6.3).
record protection algorithm record protection algorithm
The algorithm to be used for record protection. This algorithm The algorithm to be used for record protection. This algorithm
must be of the AEAD type and thus provides integrity and must be of the AEAD type and thus provides integrity and
confidentiality as a single primitive. It is possible to have confidentiality as a single primitive. It is possible to have
AEAD algorithms which do not provide any confidentiality and AEAD algorithms which do not provide any confidentiality and
Section 6.2.2 defines a special NULL_NULL AEAD algorithm for use Section 6.2.2 defines a special NULL_NULL AEAD algorithm for use
in the initial handshake). This specification includes the key in the initial handshake). This specification includes the key
size of this algorithm and the lengths of explicit and implicit size of this algorithm and of the nonce for the AEAD algorithm.
initialization vectors (or nonces).
handshake master secret handshake master secret
A 48-byte secret shared between the two peers in the connection A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting the handshake. and used to generate keys for protecting the handshake.
master secret master secret
A 48-byte secret shared between the two peers in the connection A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting application data. and used to generate keys for protecting application data.
client random client random
skipping to change at page 18, line 19 skipping to change at page 18, line 22
enum { aes_gcm } RecordProtAlgorithm; enum { aes_gcm } RecordProtAlgorithm;
/* The algorithms specified in PRFAlgorithm and /* The algorithms specified in PRFAlgorithm and
RecordProtAlgorithm may be added to. */ RecordProtAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; PRFAlgorithm prf_algorithm;
RecordProtAlgorithm record_prot_algorithm; RecordProtAlgorithm record_prot_algorithm;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 iv_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
opaque hs_master_secret[48]; opaque hs_master_secret[48];
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
The record layer will use the security parameters to generate the The record layer will use the security parameters to generate the
following four items (some of which are not required by all ciphers, following four items:
and are thus empty):
client write key client write key
server write key server write key
client write IV client write iv
server write IV server write iv
The client write parameters are used by the server when receiving and The client write parameters are used by the server when receiving and
processing records and vice versa. The algorithm used for generating processing records and vice versa. The algorithm used for generating
these items from the security parameters is described in Section 6.3 these items from the security parameters is described in Section 6.3.
Once the security parameters have been set and the keys have been Once the security parameters have been set and the keys have been
generated, the connection states can be instantiated by making them generated, the connection states can be instantiated by making them
the current states. These current states MUST be updated for each the current states. These current states MUST be updated for each
record processed. Each connection state includes the following record processed. Each connection state includes the following
elements: elements:
cipher state cipher state
The current state of the encryption algorithm. This will consist The current state of the encryption algorithm. This will consist
of the scheduled key for that connection. of the scheduled key for that connection.
sequence number sequence number
Each connection state contains a sequence number, which is Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence maintained separately for read and write states. The sequence
number MUST be set to zero whenever a connection state is made the number MUST be set to zero whenever a connection state is made the
active state. Sequence numbers are of type uint64 and may not active state. Sequence numbers are of type uint64 and MUST NOT
exceed 2^64-1. Sequence numbers do not wrap. If a TLS exceed 2^64-1. Sequence numbers do not wrap. If a TLS
implementation would need to wrap a sequence number, it must implementation would need to wrap a sequence number, it MUST
terminate the connection. A sequence number is incremented after terminate the connection. A sequence number is incremented after
each record: specifically, the first record transmitted under a each record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0. particular connection state MUST use sequence number 0.
6.2. Record Layer 6.2. Record Layer
The TLS record layer receives uninterpreted data from higher layers The TLS record layer receives uninterpreted data from higher layers
in non-empty blocks of arbitrary size. in non-empty blocks of arbitrary size.
6.2.1. Fragmentation 6.2.1. Fragmentation
skipping to change at page 19, line 33 skipping to change at page 19, line 33
message boundaries are not preserved in the record layer (i.e., message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be into a single TLSPlaintext record, or a single message MAY be
fragmented across several records). fragmented across several records).
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/
enum { enum {
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type type
The higher-level protocol used to process the enclosed fragment. The higher-level protocol used to process the enclosed fragment.
version record_version
The version of the protocol being employed. This document The protocol version the current record is compatible with. This
describes TLS Version 1.3, which uses the version { 3, 4 }. The value MUST be set to { 3, 1 } for all records. This field is
version value 3.4 is historical, deriving from the use of {3, 1} deprecated and MUST be ignored for all purposes.
for TLS 1.0. (See Appendix A.1.) Note that a client that
supports multiple versions of TLS may not know what version will
be employed before it receives the ServerHello. See Appendix E
for discussion about what record layer version number should be
employed for ClientHello.
length length
The length (in bytes) of the following TLSPlaintext.fragment. The The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14. length MUST NOT exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
specified by the type field. specified by the type field.
This document describes TLS Version 1.3, which uses the version { 3,
4 }. The version value 3.4 is historical, deriving from the use of {
3, 1 } for TLS 1.0 and { 3, 0 } for SSL 3.0. In order to maximize
backwards compatibility, the record layer version identifies as
simply TLS 1.0. Endpoints supporting other versions negotiate the
version to use by following the procedure and requirements in
Appendix D.
Implementations MUST NOT send zero-length fragments of Handshake or Implementations MUST NOT send zero-length fragments of Handshake or
Alert types. Zero-length fragments of Application data MAY be sent Alert types. Zero-length fragments of Application data MAY be sent
as they are potentially useful as a traffic analysis countermeasure. as they are potentially useful as a traffic analysis countermeasure.
6.2.2. Record Payload Protection 6.2.2. Record Payload Protection
The record protection functions translate a TLSPlaintext structure The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext. The deprotection functions reverse the into a TLSCiphertext. The deprotection functions reverse the
process. In TLS 1.3 as opposed to previous versions of TLS, all process. In TLS 1.3 as opposed to previous versions of TLS, all
ciphers are modelled as "Authenticated Encryption with Additional ciphers are modeled as "Authenticated Encryption with Additional
Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption
and authentication operation which turns plaintext into authenticated and authentication operation which turns plaintext into authenticated
ciphertext and back again. ciphertext and back again.
AEAD ciphers take as input a single key, a nonce, a plaintext, and AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [RFC5116]. The key is either the described in Section 2.1 of [RFC5116]. The key is either the
client_write_key or the server_write_key. client_write_key or the server_write_key.
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
type type
The type field is identical to TLSPlaintext.type. The type field is identical to TLSPlaintext.type.
version record_version
The version field is identical to TLSPlaintext.version. The record_version field is identical to
TLSPlaintext.record_version and is always { 3, 1 }.
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 The length of the per-record nonce (iv_length) is set to max(8 bytes,
AEAD operation is constructed, and what is the length of the N_MIN) for the AEAD algorithm (see [RFC5116] Section 4). An AEAD
TLSCiphertext.nonce_explicit part. In many cases, it is appropriate algorithm where N_MAX is less than 8 bytes MUST not be used with TLS.
to use the partially implicit nonce technique described in The per-record nonce for the AEAD construction is formed as follows:
Section 3.2.1 of [RFC5116]; with record_iv_length being the length of
the explicit part. In this case, the implicit part SHOULD be derived 1. The 64-bit record sequence number is padded to the left with
from key_block as client_write_iv and server_write_iv (as described zeroes to iv_length.
in Section 6.3), and the explicit part is included in
GenericAEAEDCipher.nonce_explicit. 2. The padded sequence number is XORed with the static
client_write_iv or server_write_iv, depending on the role.
The resulting quantity (of length iv_length) is used as the per-
record nonce.
Note: This is a different construction from that in TLS 1.2, which
specified a partially explicit nonce.
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.record_version
where "+" denotes concatenation. where "+" denotes concatenation.
Note: In versions of TLS prior to 1.3, the additional_data included a Note: In versions of TLS prior to 1.3, the additional_data included a
length field. This presents a problem for cipher constructions with length field. This presents a problem for cipher constructions with
data-dependent padding (such as CBC). TLS 1.3 removes the length data-dependent padding (such as CBC). TLS 1.3 removes the length
field and relies on the AEAD cipher to provide integrity for the field and relies on the AEAD cipher to provide integrity for the
length of the data. 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
skipping to change at page 22, line 17 skipping to change at page 22, line 23
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 needs to 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.5) from the security parameters connection state (see Appendix A.5) 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.
require a client write IV and a server write IV.
When keys are generated, the current master secret (MS) is used as an When keys are generated, the current master secret (MS) is used as an
entropy source. For handshake records, this means the entropy source. For handshake records, this means the
hs_master_secret. For application data records, this means the hs_master_secret. For application data records, this means the
regular master_secret. regular master_secret.
To generate the key material, compute To generate the key material, compute
key_block = PRF(MS, key_block = PRF(MS,
"key expansion", "key expansion",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
where MS is the relevant master secret. The PRF is computed enough where MS is the relevant master secret. The PRF is computed enough
times to generate the necessary amount of data for the key_block, times to generate the necessary amount of data for the key_block,
which is then partitioned as follows: which is then partitioned as follows:
client_write_key[SecurityParameters.enc_key_length] client_write_key[SecurityParameters.enc_key_length]
skipping to change at page 23, line 11 skipping to change at page 23, line 15
"key expansion", "key expansion",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
where MS is the relevant master secret. The PRF is computed enough where MS is the relevant master secret. The PRF is computed enough
times to generate the necessary amount of data for the key_block, times to generate the necessary amount of data for the key_block,
which is then partitioned as follows: which is then partitioned as follows:
client_write_key[SecurityParameters.enc_key_length] client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length] client_write_IV[SecurityParameters.iv_length]
server_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.iv_length]
Currently, the client_write_IV and server_write_IV are only generated
for implicit nonce techniques as described in Section 3.2.1 of
[RFC5116].
7. The TLS Handshaking Protocols 7. The TLS Handshaking Protocols
TLS has three subprotocols that are used to allow peers to agree upon TLS has three subprotocols that are used to allow peers to agree upon
security parameters for the record layer, to authenticate themselves, security parameters for the record layer, to authenticate themselves,
to instantiate negotiated security parameters, and to report error to instantiate negotiated security parameters, and to report error
conditions to each other. conditions to each other.
The Handshake Protocol is responsible for negotiating a session, The Handshake Protocol is responsible for negotiating a session,
which consists of the following items: which consists of the following items:
session identifier session identifier
An arbitrary byte sequence chosen by the server to identify an An arbitrary byte sequence chosen by the server to identify an
active or resumable session state. active or resumable session state.
peer certificate peer certificate
X509v3 [RFC3280] certificate of the peer. This element of the X509v3 [RFC5280] certificate of the peer. This element of the
state may be null. state may be null.
cipher spec cipher spec
Specifies the authentication and key establishment algorithms, the Specifies the authentication and key establishment algorithms, the
pseudorandom function (PRF) used to generate keying material, and pseudorandom function (PRF) used to generate keying material, and
the record protection algorithm (See Appendix A.5 for formal the record protection algorithm (See Appendix A.5 for formal
definition.) definition.)
resumption premaster secret resumption premaster secret
48-byte secret shared between the client and server. 48-byte secret shared between the client and server.
skipping to change at page 24, line 21 skipping to change at page 25, line 9
connection. In this case, other connections corresponding to the connection. In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated, session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new preventing the failed session from being used to establish new
connections. Like other messages, alert messages are encrypted as connections. Like other messages, alert messages are encrypted as
specified by the current connection state. specified by the current connection state.
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), unexpected_message(10), /* fatal */
bad_record_mac(20), bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), record_overflow(22), /* fatal */
decompression_failure_RESERVED(30), decompression_failure_RESERVED(30), /* fatal */
handshake_failure(40), handshake_failure(40), /* fatal */
no_certificate_RESERVED(41), no_certificate_RESERVED(41), /* fatal */
bad_certificate(42), bad_certificate(42),
unsupported_certificate(43), unsupported_certificate(43),
certificate_revoked(44), certificate_revoked(44),
certificate_expired(45), certificate_expired(45),
certificate_unknown(46), certificate_unknown(46),
illegal_parameter(47), illegal_parameter(47), /* fatal */
unknown_ca(48), unknown_ca(48), /* fatal */
access_denied(49), access_denied(49), /* fatal */
decode_error(50), decode_error(50), /* fatal */
decrypt_error(51), decrypt_error(51), /* fatal */
export_restriction_RESERVED(60), export_restriction_RESERVED(60), /* fatal */
protocol_version(70), protocol_version(70), /* fatal */
insufficient_security(71), insufficient_security(71), /* fatal */
internal_error(80), internal_error(80), /* fatal */
user_canceled(90), user_canceled(90),
no_renegotiation(100), no_renegotiation(100), /* fatal */
unsupported_extension(110), unsupported_extension(110), /* fatal */
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
7.1.1. Closure Alerts 7.1.1. Closure Alerts
skipping to change at page 25, line 18 skipping to change at page 26, line 5
ending in order to avoid a truncation attack. Either party may ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages. initiate the exchange of closing messages.
close_notify close_notify
This message notifies the recipient that the sender will not send This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1, any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice. with widespread implementation practice.
Either party MAY initiate a close by sending a close_notify alert. Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored. Any data received after a closure alert is ignored.
Unless some other fatal alert has been transmitted, each party is Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side required to send a "close_notify" alert before closing the write side
of the connection. The other party MUST respond with a close_notify of the connection. The other party MUST respond with a
alert of its own and close down the connection immediately, "close_notify" alert of its own and close down the connection
discarding any pending writes. It is not required for the initiator immediately, discarding any pending writes. It is not required for
of the close to wait for the responding close_notify alert before the initiator of the close to wait for the responding "close_notify"
closing the read side of the connection. alert before closing the read side of the connection.
If the application protocol using TLS provides that any data may be If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding closed, the TLS implementation must receive the responding
close_notify alert before indicating to the application layer that "close_notify" alert before indicating to the application layer that
the TLS connection has ended. If the application protocol will not the TLS connection has ended. If the application protocol will not
transfer any additional data, but will only close the underlying transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify. No part transport without waiting for the responding "close_notify". No part
of this standard should be taken to dictate the manner in which a of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when usage profile for TLS manages its data transport, including when
connections are opened or closed. connections are opened or closed.
Note: It is assumed that closing a connection reliably delivers Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport. pending data before destroying the transport.
7.1.2. Error Alerts 7.1.2. Error Alerts
Error handling in the TLS Handshake protocol is very simple. When an Error handling in the TLS Handshake protocol is very simple. When an
skipping to change at page 26, line 17 skipping to change at page 27, line 4
the connection. For all errors where an alert level is not the connection. For all errors where an alert level is not
explicitly specified, the sending party MAY determine at its explicitly specified, the sending party MAY determine at its
discretion whether to treat this as a fatal error or not. If the discretion whether to treat this as a fatal error or not. If the
implementation chooses to send an alert but intends to close the implementation chooses to send an alert but intends to close the
connection immediately afterwards, it MUST send that alert at the connection immediately afterwards, it MUST send that alert at the
fatal alert level. fatal alert level.
If an alert with a level of warning is sent and received, generally If an alert with a level of warning is sent and received, generally
the connection can continue normally. If the receiving party decides the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a not to proceed with the connection (e.g., after having received a
no_renegotiation alert that it is not willing to accept), it SHOULD "no_renegotiation" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection. Given this, the send a fatal alert to terminate the connection. Given this, the
sending party cannot, in general, know how the receiving party will sending party cannot, in general, know how the receiving party will
behave. Therefore, warning alerts are not very useful when the behave. Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are sending party wants to continue the connection, and thus are
sometimes omitted. For example, if a peer decides to accept an sometimes omitted. For example, if a peer decides to accept an
expired certificate (perhaps after confirming this with the user) and expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a wants to continue the connection, it would not generally send a
certificate_expired alert. "certificate_expired" alert.
The following error alerts are defined: The following error alerts are defined:
unexpected_message unexpected_message
An inappropriate message was received. This alert is always fatal An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper and should never be observed in communication between proper
implementations. implementations.
bad_record_mac bad_record_mac
This alert is returned if a record is received which cannot be This alert is returned if a record is received which cannot be
deprotected. Because AEAD algorithms combine decryption and deprotected. Because AEAD algorithms combine decryption and
verification, this message is used for all deprotection failures. verification, this message is used for all deprotection failures.
This message is always fatal and should never be observed in This message is always fatal and should never be observed in
communication between proper implementations (except when messages communication between proper implementations (except when messages
were corrupted in the network). were corrupted in the network).
decryption_failed_RESERVED decryption_failed_RESERVED
This alert was used in some earlier versions of TLS, and may have This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode [CBCATT]. It MUST permitted certain attacks against the CBC mode [CBCATT]. It MUST
NOT be sent by compliant implementations. NOT be sent by compliant implementations. This message is always
fatal.
record_overflow record_overflow
A TLSCiphertext record was received that had a length more than A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSPlaintext record 2^14+2048 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes. This message is always fatal and with more than 2^14 bytes. This message is always fatal and
should never be observed in communication between proper should never be observed in communication between proper
implementations (except when messages were corrupted in the implementations (except when messages were corrupted in the
network). network).
decompression_failure decompression_failure_RESERVED
This alert was used in previous versions of TLS. TLS 1.3 does not This alert was used in previous versions of TLS. TLS 1.3 does not
include compression and TLS 1.3 implementations MUST NOT send this include compression and TLS 1.3 implementations MUST NOT send this
alert when in TLS 1.3 mode. alert when in TLS 1.3 mode. This message is always fatal.
handshake_failure handshake_failure
Reception of a handshake_failure alert message indicates that the Reception of a "handshake_failure" alert message indicates that
sender was unable to negotiate an acceptable set of security the sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error. parameters given the options available. This message is always
fatal.
no_certificate_RESERVED no_certificate_RESERVED
This alert was used in SSLv3 but not any version of TLS. It MUST This alert was used in SSL 3.0 but not any version of TLS. It
NOT be sent by compliant implementations. MUST NOT be sent by compliant implementations. This message is
always fatal.
bad_certificate bad_certificate
A certificate was corrupt, contained signatures that did not A certificate was corrupt, contained signatures that did not
verify correctly, etc. verify correctly, etc.
unsupported_certificate unsupported_certificate
A certificate was of an unsupported type. A certificate was of an unsupported type.
certificate_revoked certificate_revoked
A certificate was revoked by its signer. A certificate was revoked by its signer.
skipping to change at page 28, line 19 skipping to change at page 29, line 10
communication between proper implementations (except when messages communication between proper implementations (except when messages
were corrupted in the network). were corrupted in the network).
decrypt_error decrypt_error
A handshake cryptographic operation failed, including being unable A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message. to correctly verify a signature or validate a Finished message.
This message is always fatal. This message is always fatal.
export_restriction_RESERVED export_restriction_RESERVED
This alert was used in some earlier versions of TLS. It MUST NOT This alert was used in some earlier versions of TLS. It MUST NOT
be sent by compliant implementations. be sent by compliant implementations. This message is always
fatal.
protocol_version protocol_version
The protocol version the client has attempted to negotiate is The protocol version the peer has attempted to negotiate is
recognized but not supported. (For example, old protocol versions recognized but not supported. (For example, old protocol versions
might be avoided for security reasons.) This message is always might be avoided for security reasons.) This message is always
fatal. fatal.
insufficient_security insufficient_security
Returned instead of handshake_failure when a negotiation has Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more failed specifically because the server requires ciphers more
secure than those supported by the client. This message is always secure than those supported by the client. This message is always
fatal. fatal.
internal_error internal_error
An internal error unrelated to the peer or the correctness of the An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible protocol (such as a memory allocation failure) makes it impossible
to continue. This message is always fatal. to continue. This message is always fatal.
user_canceled user_canceled
This handshake is being canceled for some reason unrelated to a This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed "close_notify" is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning. by a "close_notify". This message is generally a warning.
no_renegotiation no_renegotiation
Sent by the client in response to a hello request or by the server Sent by the client in response to a HelloRequest or by the server
in response to a client hello after initial handshaking. Versions in response to a ClientHello after initial handshaking. Versions
of TLS prior to TLS 1.3 supported renegotiation of a previously of TLS prior to TLS 1.3 supported renegotiation of a previously
established connection; TLS 1.3 removes this feature. This established connection; TLS 1.3 removes this feature. This
message is always fatal. message is always fatal.
unsupported_extension unsupported_extension
sent by clients that receive an extended server hello containing sent by clients that receive an extended ServerHello containing an
an extension that they did not put in the corresponding client extension that they did not put in the corresponding ClientHello.
hello. This message is always fatal. This message is always fatal.
New Alert values are assigned by IANA as described in Section 12. New Alert values are assigned by IANA as described in Section 12.
7.2. Handshake Protocol Overview 7.2. Handshake Protocol Overview
The cryptographic parameters of the session state are produced by the The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record TLS Handshake Protocol, which operates on top of the TLS record
layer. When a TLS client and server first start communicating, they layer. When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms, agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption optionally authenticate each other, and use public-key encryption
skipping to change at page 29, line 45 skipping to change at page 30, line 40
- Allow the client and server to verify that their peer has - Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake calculated the same security parameters and that the handshake
occurred without tampering by an attacker. occurred without tampering by an attacker.
Note that higher layers should not be overly reliant on whether TLS Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two always negotiates the strongest possible connection between two
peers. There are a number of ways in which a man-in-the-middle peers. There are a number of ways in which a man-in-the-middle
attacker can attempt to make two entities drop down to the least attacker can attempt to make two entities drop down to the least
secure method they support. The protocol has been designed to secure method they support. The protocol has been designed to
minimize this risk, but there are still attacks available: for minimize this risk, but there are still attacks available. For
example, an attacker could block access to the port a secure service example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated runs on or attempt to get the peers to negotiate an unauthenticated
connection. The fundamental rule is that higher levels must be connection. The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit cognizant of what their security requirements are and never transmit
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 255-bit
key exchange with a host whose certificate you have verified, you can ECDHE key exchange with a host whose certificate chain you have
expect to be that secure. verified, you can expect that to be reasonably 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 ClientKeyShare 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.).
If the client has provided a ClientKeyShare with an appropriate set If the client has provided a ClientKeyShare with an appropriate set
skipping to change at page 31, line 16 skipping to change at page 32, line 10
the server has sent a CertificateRequest message, the client MUST the server has sent a CertificateRequest message, the client MUST
send the Certificate message, though it may contain zero send the Certificate message, though it may contain zero
certificates. If the client has sent a certificate, a digitally- certificates. If the client has sent a certificate, a digitally-
signed CertificateVerify message is sent to explicitly verify signed CertificateVerify message is sent to explicitly verify
possession of the private key in the certificate. Finally, the possession of the private key in the certificate. Finally, the
client sends the Finished message. client sends the Finished message.
At this point, the handshake is complete, and the client and server At this point, the handshake is complete, and the client and server
may exchange application layer data, which is protected using a new may exchange application layer data, which is protected using a new
set of keys derived from both the premaster secret and the handshake set of keys derived from both the premaster secret and the handshake
transcript (see [I-D.ietf-tls-session-hash] for the security transcript (See [I-D.ietf-tls-session-hash] for the security
rationale for this.) rationale for this.)
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
ClientKeyShare --------> ClientKeyShare -------->
ServerHello ServerHello
ServerKeyShare ServerKeyShare
skipping to change at page 35, line 6 skipping to change at page 36, line 6
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 will also send a the ClientHello as its first message. The client will also send a
ClientHello when the server has responded to its ClientHello with ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare. In that case, the client MUST match the client's ClientKeyShare. In that case, the client MUST
send the same ClientHello (without modification) along with the send the same ClientHello (without modification) along with the
new ClientKeyShare. If a server receives a ClientHello at any new ClientKeyShare. If a server receives a ClientHello at any
other time, it MUST send a fatal no_renegotiation alert. other time, it MUST send a fatal "no_renegotiation" alert.
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 {
opaque random_bytes[32]; opaque random_bytes[32];
} Random; } Random;
random_bytes random_bytes
32 bytes generated by a secure random number generator. 32 bytes generated by a secure random number generator.
Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the 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. Random value to encode the time since the UNIX epoch.
Note: The ClientHello message includes a variable-length session 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
skipping to change at page 36, line 7 skipping to change at page 37, line 7
content of the handshake as a whole, including the SessionID, is content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the protected by the Finished messages exchanged at the end of the
handshake.) handshake.)
The cipher suite list, passed from the client to the server in the The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each cipher suite defines a key preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a record protection algorithm (including secret exchange algorithm, a record protection algorithm (including secret
key length) and a PRF. The server will select a cipher suite or, if key length) and a PRF. The server will select a cipher suite or, if
no acceptable choices are presented, return a handshake failure alert no acceptable choices are presented, return a "handshake_failure"
and close the connection. If the list contains cipher suites the alert and close the connection. If the list contains cipher suites
server does not recognize, support, or wish to use, the server MUST the server does not recognize, support, or wish to use, the server
ignore those cipher suites, and process the remaining ones as usual. MUST ignore those cipher suites, and process the remaining ones as
usual.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
skipping to change at page 36, line 42 skipping to change at page 37, line 43
determining whether there are bytes following the compression_methods determining whether there are bytes following the compression_methods
at the end of the ClientHello. Note that this method of detecting at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS variable-length field, but it is used for compatibility with TLS
before extensions were defined. before extensions were defined.
client_version client_version
The version of the TLS protocol by which the client wishes to The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this (highest valued) version supported by the client. For this
version of the specification, the version will be 3.4 (see version of the specification, the version will be 3.4. (See
Appendix E for details about backward compatibility). Appendix D for details about backward compatibility.)
random random
A client-generated random structure. A client-generated random structure.
session_id session_id
The ID of a session the client wishes to use for this connection. The ID of a session the client wishes to use for this connection.
This field is empty if no session_id is available, or if the This field is empty if no session_id is available, or if the
client wishes to generate new security parameters. client wishes to generate new security parameters.
cipher_suites cipher_suites
skipping to change at page 37, line 39 skipping to change at page 38, line 42
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 or HelloRetryRequest message. ServerHello or HelloRetryRequest message.
7.3.2. Client Key Share Message 7.3.2. Client Key Share
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.3.2.5.3) in the ClientHello. (Section 7.3.2.5.3) 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:
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } ClientKeyShareOffer;
group The named group for the key share offer. This identifies the group
The named group for the key share offer. This identifies the
specific key exchange method that the ClientKeyShareOffer specific key exchange method that the ClientKeyShareOffer
describes. Finite Field Diffie-Hellman parameters are described describes. Finite Field Diffie-Hellman [DH] parameters are
in Section 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are described in Section 7.3.2.1; Elliptic Curve Diffie-Hellman
described in Section 7.3.2.2. parameters are described in Section 7.3.2.2.
key_exchange Key exchange information. The contents of this field key_exchange
are determined by the value of NamedGroup entry and its Key exchange information. The contents of this field are
corresponding definition. determined by the value of NamedGroup entry and its corresponding
definition.
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
offers offers
A list of ClientKeyShareOffer values. A list of ClientKeyShareOffer values.
Clients may offer an arbitrary number of ClientKeyShareOffer values, Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for each representing a single set of key agreement parameters; for
skipping to change at page 38, line 43 skipping to change at page 39, line 48
MUST by generated independently. Clients MUST NOT offer multiple MUST by generated independently. Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters. It is explicitly ClientKeyShareOffers for the same parameters. It is explicitly
permitted to send an empty ClientKeyShare message, as this is used to permitted to send an empty ClientKeyShare message, as this is used to
elicit the server's parameters if the client has no useful elicit the server's parameters if the client has no useful
information. [TODO: Recommendation about what the client offers. information. [TODO: Recommendation about what the client offers.
Presumably which integer DH groups and which curves.] [TODO: Work Presumably which integer DH groups and which curves.] [TODO: Work
out how this interacts with PSK and SRP.] out how this interacts with PSK and SRP.]
7.3.2.1. Diffie-Hellman Parameters 7.3.2.1. Diffie-Hellman Parameters
Diffie-Hellman parameters for both clients and servers are encoded in Diffie-Hellman [DH] parameters for both clients and servers are
the opaque key_exchange field of the ClientKeyShareOffer or encoded in the opaque key_exchange field of the ClientKeyShareOffer
ServerKeyShare structures. The opaque value contains the Diffie- or ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer. integer.
opaque dh_Y<1..2^16-1>; opaque dh_Y<1..2^16-1>;
7.3.2.2. ECHDE Parameters 7.3.2.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value conveys the Elliptic ServerKeyShare structures. The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point. string ECPoint.point.
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
point point
This is the byte string representation of an elliptic curve point This is the byte string representation of an elliptic curve point
following the conversion routine in Section 4.3.6 of ANSI X9.62 following the conversion routine in Section 4.3.6 of ANSI X9.62
{{X962}. [X962].
Although X9.62 supports multiple point formats, any given curve MUST Although X9.62 supports multiple point formats, any given curve MUST
specify only a single point format. All curves currently specified specify only a single point format. All curves currently specified
in this document MUST only be used with the uncompressed point in this document MUST only be used with the uncompressed point
format. format.
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS
1.3 removes this feature in favor of a single point format for each 1.3 removes this feature in favor of a single point format for each
curve. curve.
skipping to change at page 39, line 43 skipping to change at page 40, line 45
curves conform to X9.62.]] curves conform to X9.62.]]
7.3.2.3. Server Hello 7.3.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
and the client's ClientKeyShare message was acceptable. If the and the client's ClientKeyShare message was acceptable. If the
client proposed groups are not acceptable by the server, it will client proposed groups are not acceptable by the server, it will
respond with an insufficient_security fatal alert. 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 40, line 24 skipping to change at page 41, line 24
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
} ServerHello; } ServerHello;
The presence of extensions can be detected by determining whether The presence of extensions can be detected by determining whether
there are bytes following the cipher_suite field at the end of the there are bytes following the cipher_suite field at the end of the
ServerHello. ServerHello.
server_version server_version
This field will contain the lower of that suggested by the client This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For in the ClientHello and the highest supported by the server. For
this version of the specification, the version is 3.4. (See this version of the specification, the version is 3.4. (See
Appendix E for details about backward compatibility.) Appendix D for details about backward compatibility.)
random random
This structure is generated by the server and MUST be generated This structure is generated by the server and MUST be generated
independently of the ClientHello.random. independently of the ClientHello.random.
session_id session_id
This is the identity of the session corresponding to this This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection found and the server is willing to establish the new connection
skipping to change at page 41, line 16 skipping to change at page 42, line 16
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.3.4 between the ServerHello and the EncryptedExtensions Section 7.3.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.3.2.4. HelloRetryRequest 7.3.2.4. Hello Retry Request
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
but the client's ClientKeyShare message did not contain an but the client's ClientKeyShare message did not contain an
acceptable offer. If it cannot find such a match, it will respond acceptable offer. If it cannot find such a match, it will respond
with a handshake failure alert. with a "handshake_failure" alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
skipping to change at page 42, line 7 skipping to change at page 43, line 7
generate a correct ClientHello/ClientKeyShare pair. generate a correct ClientHello/ClientKeyShare pair.
Upon receipt of a HelloRetryRequest, the client MUST send a new Upon receipt of a HelloRetryRequest, the client MUST send a new
ClientHello/ClientKeyShare pair to the server. The ClientKeyShare ClientHello/ClientKeyShare pair to the server. The ClientKeyShare
MUST contain both the groups in the original ClientKeyShare as well MUST contain both the groups in the original ClientKeyShare as well
as a ClientKeyShareOffer consistent with the "selected_group" field. as a ClientKeyShareOffer consistent with the "selected_group" field.
I.e., it MUST be a superset of the previous ClientKeyShareOffer. I.e., it MUST be a superset of the previous ClientKeyShareOffer.
Upon re-sending the ClientHello/ClientKeyShare and receiving the Upon re-sending the ClientHello/ClientKeyShare and receiving the
server's ServerHello/ServerKeyShare, the client MUST verify that the server's ServerHello/ServerKeyShare, the client MUST verify that the
selected ciphersuite and NamedGroup match that supplied in the selected CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest. HelloRetryRequest.
7.3.2.5. Hello Extensions 7.3.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;
skipping to change at page 42, line 30 skipping to change at page 43, line 30
signature_algorithms(13), early_data(TBD), (65535) signature_algorithms(13), early_data(TBD), (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
The initial set of extensions is defined in a companion document The initial set of extensions is defined in [RFC6066]. The list of
[TLSEXT]. The list of extension types is maintained by IANA as extension types is maintained by IANA as described in Section 12.
described in Section 12.
An extension type MUST NOT appear in the ServerHello unless the same An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello. If a extension type appeared in the corresponding ClientHello. If a
client receives an extension type in ServerHello that it did not client receives an extension type in ServerHello that it did not
request in the associated ClientHello, it MUST abort the handshake request in the associated ClientHello, it MUST abort the handshake
with an unsupported_extension fatal alert. with an "unsupported_extension" fatal alert.
Nonetheless, "server-oriented" extensions may be provided in the Nonetheless, "server-oriented" extensions may be provided in the
future within this framework. Such an extension (say, of type x) future within this framework. Such an extension (say, of type x)
would require the client to first send an extension of type x in a would require the client to first send an extension of type x in a
ClientHello with empty extension_data to indicate that it supports ClientHello with empty extension_data to indicate that it supports
the extension type. In this case, the client is offering the the extension type. In this case, the client is offering the
capability to understand the extension type, and the server is taking capability to understand the extension type, and the server is taking
the client up on its offer. the client up on its offer.
When multiple extensions of different types are present in the When multiple extensions of different types are present in the
skipping to change at page 43, line 16 skipping to change at page 44, line 13
session and when requesting session resumption. Indeed, a client session and when requesting session resumption. Indeed, a client
that requests session resumption does not in general know whether the that requests session resumption does not in general know whether the
server will accept this request, and therefore it SHOULD send the server will accept this request, and therefore it SHOULD send the
same extensions as it would send if it were not attempting same extensions as it would send if it were not attempting
resumption. resumption.
In general, the specification of each extension type needs to In general, the specification of each extension type needs to
describe the effect of the extension both during full handshake and describe the effect of the extension both during full handshake and
session resumption. Most current TLS extensions are relevant only session resumption. Most current TLS extensions are relevant only
when a session is initiated: when an older session is resumed, the when a session is initiated: when an older session is resumed, the
server does not process these extensions in Client Hello, and does server does not process these extensions in ClientHello, and does not
not include them in Server Hello. However, some extensions may include them in ServerHello. However, some extensions may specify
specify different behavior during session resumption. different behavior during session resumption.
There are subtle (and not so subtle) interactions that may occur in There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may this protocol between new features and existing features which may
result in a significant reduction in overall security. The following result in a significant reduction in overall security. The following
considerations should be taken into account when designing new considerations should be taken into account when designing new
extensions: extensions:
- Some cases where a server does not agree to an extension are error - Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular conditions, and some are simply refusals to support particular
features. In general, error alerts should be used for the former, features. In general, error alerts should be used for the former,
and a field in the server extension response for the latter. and a field in the server extension response for the latter.
- Extensions should, as far as possible, be designed to prevent any - Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a followed regardless of whether the feature is believed to cause a
security problem. security problem. Often the fact that the extension fields are
included in the inputs to the Finished message hashes will be
Often the fact that the extension fields are included in the sufficient, but extreme care is needed when the extension changes
inputs to the Finished message hashes will be sufficient, but the meaning of messages sent in the handshake phase. Designers
extreme care is needed when the extension changes the meaning of and implementors should be aware of the fact that until the
messages sent in the handshake phase. Designers and implementors handshake has been authenticated, active attackers can modify
should be aware of the fact that until the handshake has been messages and insert, remove, or replace extensions.
authenticated, active attackers can modify messages and insert,
remove, or replace extensions.
- 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.
skipping to change at page 45, line 28 skipping to change at page 46, line 28
- 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
the client had sent the value {sha1,dsa}. the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as - If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as
if the client had sent value {sha1,ecdsa}. if the client had sent value {sha1,ecdsa}.
Note: this is a change from TLS 1.1 where there are no explicit Note: This extension is not meaningful for TLS versions prior to 1.2.
rules, but as a practical matter one can assume that the peer
supports MD5 and SHA-1.
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions. Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT] However, even if clients do offer it, the rules specified in
require servers to ignore extensions they do not understand. [RFC6066] 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 ServerHello, and the server ignores the extension in ClientHello (if
(if present). present).
7.3.2.5.2. Negotiated Groups 7.3.2.5.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most the named groups which the client supports, ordered from most
preferred to least preferred. preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic curves" and only contained elliptic curve groups. See "elliptic curves" and only contained elliptic curve groups. See
[RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. [RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe].
The "extension_data" field of this extension SHALL contain a The "extension_data" field of this extension SHALL contain a
"NamedGroupList" value: "NamedGroupList" value:
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3), sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6), sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9), sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12), sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15), sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18), secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21), secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24), secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2048(256), ffdhe3072(257), ffdhe4096(258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe8192(259), ffdhe6144 (259), ffdhe8192 (260),
ffdhe_private_use (0x01FC..0x01FF),
// Reserved Code Points. // Reserved Code Points.
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
reserved(0xFF01), reserved(0xFF01),
reserved(0xFF02), reserved(0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1> NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
sect163k1, etc sect163k1, etc
Indicates support of the corresponding named curve The named Indicates support of the corresponding named curve The named
curves defined here are those specified in SEC 2 [13]. Note that 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 many of these curves are also recommended in ANSI X9.62 [X962] and
FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for
private use. Values 0xFF01 and 0xFF02 were used in previous private use. Values 0xFF01 and 0xFF02 were used in previous
versions of TLS but MUST NOT be offered by TLS 1.3 versions of TLS but MUST NOT be offered by TLS 1.3
implementations. [[OPEN ISSUE: Triage curve list.]] implementations. [[OPEN ISSUE: Triage curve list.]]
skipping to change at page 47, line 14 skipping to change at page 48, line 11
Items in named_curve_list are ordered according to the client's Items in named_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192; 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) value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
and prefers to use secp192r1 would include a TLS extension consisting and prefers to use secp192r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type (Supported Group Extension): extension type (Supported Group Extension):
00 0A 00 06 00 04 00 13 00 15 00 0A 00 06 00 04 00 13 00 15
The client MUST supply a "named_groups" extension containing at least The client MUST supply a "named_groups" extension containing at least
one group for each key exchange algorithm (currently DHE and ECDHE) 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 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 "named_groups" extension with a compatible group, the server MUST NOT
negotiate a cipher suite of the relevant type. For instance, if a negotiate a cipher suite of the relevant type. For instance, if a
client supplies only ECDHE groups, the server MUST NOT negotiate client supplies only ECDHE groups, the server MUST NOT negotiate
finite field Diffie-Hellman. If no acceptable group can be selected finite field Diffie-Hellman. If no acceptable group can be selected
across all cipher suites, then the server MUST generate a fatal across all cipher suites, then the server MUST generate a fatal
"handshake_failure" alert. "handshake_failure" alert.
skipping to change at page 47, line 42 skipping to change at page 48, line 39
7.3.2.5.3. Early Data Extension 7.3.2.5.3. 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>;
} EarlyDataExtension; } EarlyDataExtension;
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
skipping to change at page 48, line 18 skipping to change at page 49, line 15
ServerHello, etc. However, because the ClientKeyShare 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 acknowledgment 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 "ClientKeyShare" extension. However, for attractive to just have a "ClientKeyShare" extension. However, 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.3.3. Server Key Share Message 7.3.3. Server Key Share
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 ClientKeyShare message which message if the client has provided a ClientKeyShare message which
is compatible with the selected cipher suite and group parameters. is compatible with the selected cipher suite and group 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 {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ServerKeyShare; } ServerKeyShare;
group The named group for the key share offer. This identifies the group
The named group for the key share offer. This identifies the
selected key exchange method from the ClientKeyShare message selected key exchange method from the ClientKeyShare message
(Section 7.3.2), identifying which value from the (Section 7.3.2), identifying which value from the
ClientKeyShareOffer the server has accepted as is responding to. ClientKeyShareOffer the server has accepted as is responding to.
key_exchange Key exchange information. The contents of this field key_exchange
are determined by the value of NamedGroup entry and its Key exchange information. The contents of this field are
corresponding definition. determined by the value of NamedGroup entry and its corresponding
definition.
7.3.4. Encrypted Extensions 7.3.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 ServerKeyShare. server's ServerKeyShare.
Meaning of this message: Meaning of this message:
skipping to change at page 50, line 40 skipping to change at page 51, line 42
send no certificates if it does not have an appropriate certificate send no certificates if it does not have an appropriate certificate
to send in response to the server's authentication request. to send in response to the server's authentication request.
Note: PKCS #7 [PKCS7] is not used as the format for the certificate Note: PKCS #7 [PKCS7] is not used as the format for the certificate
vector because PKCS #6 [PKCS6] extended certificates are not used. vector because PKCS #6 [PKCS6] extended certificates are not used.
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
of parsing the list more difficult. of parsing the list more difficult.
The following rules apply to the certificates sent by the server: The following rules apply to the certificates sent by the server:
- The certificate type MUST be X.509v3, unless explicitly negotiated - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
otherwise (e.g., [RFC5081]). negotiated otherwise (e.g., [RFC5081]).
- The end entity certificate's public key (and associated - The end entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange restrictions) MUST be compatible with the selected key exchange
algorithm. algorithm.
Key Exchange Alg. Certificate Key Type Key Exchange Alg. Certificate Key Type
DHE_RSA RSA public key; the certificate MUST allow the DHE_RSA RSA public key; the certificate MUST allow the
ECDHE_RSA key to be used for signing (the ECDHE_RSA key to be used for signing (the
digitalSignature bit MUST be set if the key digitalSignature bit MUST be set if the key
skipping to change at page 51, line 27 skipping to change at page 52, line 27
algorithm that will be employed in the server algorithm that will be employed in the server
key exchange message. key exchange message.
ECDHE_ECDSA ECDSA-capable public key; the certificate MUST ECDHE_ECDSA ECDSA-capable public key; the certificate MUST
allow the key to be used for signing with the allow the key to be used for signing with the
hash algorithm that will be employed in the hash algorithm that will be employed in the
server key exchange message. The public key server key exchange message. The public key
MUST use a curve and point format supported by MUST use a curve and point format supported by
the client, as described in [RFC4492]. the client, as described in [RFC4492].
- The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are - The "server_name" and "trusted_ca_keys" extensions [RFC6066] are
used to guide certificate selection. used to guide certificate selection.
If the client provided a "signature_algorithms" extension, then all If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a hash/ certificates provided by the server MUST be signed by a hash/
signature algorithm pair that appears in that extension. Note that signature algorithm pair that appears in that extension. Note that
this implies that a certificate containing a key for one signature this implies that a certificate containing a key for one signature
algorithm MAY be signed using a different signature algorithm (for algorithm MAY be signed using a different signature algorithm (for
instance, an RSA key signed with a DSA key). This is a departure instance, an RSA key signed with a DSA key).
from TLS 1.1, which required that the algorithms be the same.
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences, as transport layer endpoint, local configuration and preferences,
etc.). If the server has a single certificate, it SHOULD attempt to etc.). If the server has a single certificate, it SHOULD attempt to
validate that it meets these criteria. validate that it meets these criteria.
Note that there are certificates that use algorithms and/or algorithm Note that there are certificates that use algorithms and/or algorithm
combinations that cannot be currently used with TLS. For example, a combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
skipping to change at page 53, line 7 skipping to change at page 54, line 7
certificate_authorities, represented in DER-encoded format. These certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType, send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary. unless there is some external arrangement to the contrary.
The interaction of the certificate_types and The interaction of the certificate_types and
supported_signature_algorithms fields is somewhat complicated. supported_signature_algorithms fields is somewhat complicated.
certificate_types has been present in TLS since SSLv3, but was certificate_types has been present in TLS since SSL 3.0, but was
somewhat underspecified. Much of its functionality is superseded by somewhat underspecified. Much of its functionality is superseded by
supported_signature_algorithms. The following rules apply: supported_signature_algorithms. The following rules apply:
- Any certificates provided by the client MUST be signed using a - Any certificates provided by the client MUST be signed using a
hash/signature algorithm pair found in hash/signature algorithm pair found in
supported_signature_algorithms. supported_signature_algorithms.
- The end-entity certificate provided by the client MUST contain a - The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature signature key, it MUST be usable with some hash/signature
skipping to change at page 53, line 35 skipping to change at page 54, line 35
supported_signature_algorithms, and the certificate type no longer supported_signature_algorithms, and the certificate type no longer
restricts the algorithm used to sign the certificate. For restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and example, if the server sends dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA- with a certificate containing a static DH key, signed with RSA-
SHA1. SHA1.
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 12. Section 12.
Note: Values listed as RESERVED may not be used. They were used in Note: Values listed as RESERVED MUST NOT be used. They were used in
SSLv3. SSL 3.0.
Note: It is a fatal handshake_failure alert for an anonymous server Note: It is a fatal "handshake_failure" alert for an anonymous server
to request client authentication. to request client authentication.
7.3.7. Server Certificate Verify 7.3.7. Server Certificate Verify
When this message will be sent: When this message will be sent:
This message is used to provide explicit proof that the server This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate. possesses the private key corresponding to its certificate and
certificate and also provides integrity for the handshake up to also provides integrity for the handshake up to this point. This
this point. This message is only sent when the server is message is only sent when the server is authenticated via a
authenticated via a certificate. When sent, it MUST be the last certificate. When sent, it MUST be the last server handshake
server handshake message prior to the Finished. message prior to the Finished.
Structure of this message: Structure of this message:
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages_hash[hash_length]; opaque handshake_messages_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
Here handshake_messages_hash is a digest of all handshake messages Here handshake_messages_hash is a digest of all handshake messages
skipping to change at page 54, line 52 skipping to change at page 55, line 52
with the key in the server's end-entity certificate. RSA keys MAY with the key in the server's end-entity certificate. RSA keys MAY
be used with any permitted hash algorithm, subject to restrictions be used with any permitted hash algorithm, subject to restrictions
in the certificate, if any. in the certificate, if any.
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 [RFC5280] 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.3.8. Server Finished 7.3.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:
Recipients of Finished messages MUST verify that the contents are Recipients of Finished messages MUST verify that the contents are
correct. Once a side has sent its Finished message and received correct. Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to and validated the Finished message from its peer, it may begin to
send and receive application data over the connection. This data send and receive application data over the connection. This data
will be protected under keys derived from the hs_master_secret will be protected under keys derived from the hs_master_secret
(see Section 8. (see Section 8).
Structure of this message: Structure of this message:
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
verify_data verify_data
PRF(hs_master_secret, finished_label, Hash(handshake_messages)) PRF(hs_master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1]; [0..verify_data_length-1];
skipping to change at page 56, line 40 skipping to change at page 57, line 40
When this message will be sent: When this message will be sent:
This message is the first handshake message the client can send This message is the first handshake message the client can send
after receiving the server's Finished. This message is only sent after receiving the server's Finished. This message is only sent
if the server requests a certificate. If no suitable certificate if the server requests a certificate. If no suitable certificate
is available, the client MUST send a certificate message is available, the client MUST send a certificate message
containing no certificates. That is, the certificate_list containing no certificates. That is, the certificate_list
structure has a length of zero. If the client does not send any structure has a length of zero. If the client does not send any
certificates, the server MAY at its discretion either continue the certificates, the server MAY at its discretion either continue the
handshake without client authentication, or respond with a fatal handshake without client authentication, or respond with a fatal
handshake_failure alert. Also, if some aspect of the certificate "handshake_failure" alert. Also, if some aspect of the
chain was unacceptable (e.g., it was not signed by a known, certificate chain was unacceptable (e.g., it was not signed by a
trusted CA), the server MAY at its discretion either continue the known, trusted CA), the server MAY at its discretion either
handshake (considering the client unauthenticated) or send a fatal continue the handshake (considering the client unauthenticated) or
alert. send a fatal alert.
Client certificates are sent using the Certificate structure Client certificates are sent using the Certificate structure
defined in Section 7.3.5. defined in Section 7.3.5.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate chain to the server; This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing) or message (when the client authentication is based on signing) or
calculating the premaster secret (for non-ephemeral Diffie- calculating the premaster secret (for non-ephemeral Diffie-
Hellman). The certificate MUST be appropriate for the negotiated Hellman). The certificate MUST be appropriate for the negotiated
cipher suite's key exchange algorithm, and any negotiated cipher suite's key exchange algorithm, and any negotiated
extensions. extensions.
In particular: In particular:
- The certificate type MUST be X.509v3, unless explicitly negotiated - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
otherwise (e.g., [RFC5081]). negotiated otherwise (e.g., [RFC5081]).
- The end-entity certificate's public key (and associated - The end-entity certificate's public key (and associated
restrictions) has to be compatible with the certificate types restrictions) has to be compatible with the certificate types
listed in CertificateRequest: listed in CertificateRequest:
Client Cert. Type Certificate Key Type Client Cert. Type Certificate Key Type
rsa_sign RSA public key; the certificate MUST allow the rsa_sign RSA public key; the certificate MUST allow the
key to be used for signing with the signature key to be used for signing with the signature
scheme and hash algorithm that will be scheme and hash algorithm that will be
skipping to change at page 58, line 41 skipping to change at page 59, line 41
client's end-entity certificate. RSA keys MAY be used with any client's end-entity certificate. RSA keys MAY be used with any
permitted hash algorithm, subject to restrictions in the permitted hash algorithm, subject to restrictions in the
certificate, if any. certificate, if any.
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 [RFC5280] may specify
mechanisms for certificates to indicate which digest algorithms mechanisms for certificates to indicate which digest algorithms
are to be used with DSA. are to be used with DSA.
8. Cryptographic Computations 8. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, key the client and server random values. The authentication, key
agreement, and record protection algorithms are determined by the agreement, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello cipher_suite selected by the server and revealed in the ServerHello
skipping to change at page 60, line 14 skipping to change at page 61, line 14
remainder of the session. It is also used with TLS Exporters remainder of the session. It is also used with TLS Exporters
[RFC5705]. [RFC5705].
master_secret = PRF(hs_master_secret, "extended master secret", master_secret = PRF(hs_master_secret, "extended master secret",
session_hash) session_hash)
[0..47]; [0..47];
If the server does not request client authentication, the master If the server does not request client authentication, the master
secret can be computed at the time that the server sends its secret can be computed at the time that the server sends its
Finished, thus allowing the server to send traffic on its first Finished, thus allowing the server to send traffic on its first
flight (see [TODO] for security considerations on this practice.) If flight (See [TODO] for security considerations on this practice.) If
the server requests client authentication, this secret can be the server requests client authentication, this secret can be
computed after the client's Certificate and CertificateVerify have computed after the client's Certificate and CertificateVerify have
been sent, or, if the client refuses client authentication, after the been sent, or, if the client refuses client authentication, after the
client's empty Certificate message has been sent. client's empty Certificate message has been sent.
For full handshakes, each side also derives a new secret which will For full handshakes, each side also derives a new secret which will
be used as the premaster_secret for future resumptions of the newly be used as the premaster_secret for future resumptions of the newly
established session. This is computed as: established session. This is computed as:
resumption_premaster_secret = PRF(hs_master_secret, resumption_premaster_secret = PRF(hs_master_secret,
skipping to change at page 60, line 40 skipping to change at page 61, line 40
in Section 8.1.1. Thus, the hs_master_secret is generated using a in Section 8.1.1. Thus, the hs_master_secret is generated using a
different session_hash from the other two secrets. different session_hash from the other two secrets.
All master secrets are always exactly 48 bytes in length. The length All master secrets are always exactly 48 bytes in length. The length
of the premaster secret will vary depending on key exchange method. of the premaster secret will vary depending on key exchange method.
8.1.1. The Session Hash 8.1.1. The Session Hash
When a handshake takes place, we define When a handshake takes place, we define
session_hash = Hash(handshake_messages) session_hash = Hash(handshake_messages)
where "handshake_messages" refers to all handshake messages sent or where "handshake_messages" refers to all handshake messages sent or
received, starting at client hello up to the present time, with the received, starting at ClientHello up to the present time, with the
exception of the Finished message, including the type and length exception of the Finished message, including the type and length
fields of the handshake messages. This is the concatenation of all fields of the handshake messages. This is the concatenation of all
the exchanged Handshake structures. the exchanged Handshake structures.
For concreteness, at the point where the handshake master secret is For concreteness, at the point where the handshake master secret is
derived, the session hash includes the ClientHello, ClientKeyShare, derived, the session hash includes the ClientHello, ClientKeyShare,
ServerHello, and ServerKeyShare, and HelloRetryRequest (if any) ServerHello, and ServerKeyShare, and HelloRetryRequest (if any)
(though see [https://github.com/tlswg/tls13-spec/issues/104]). At (though see [https://github.com/tlswg/tls13-spec/issues/104]). At
the point where the master secret is derived, it includes every the point where the master secret is derived, it includes every
handshake message, with the exception of the Finished messages. Note handshake message, with the exception of the Finished messages. Note
that if client authentication is not used, then the session hash is that if client authentication is not used, then the session hash is
complete at the point when the server has sent its first flight. complete at the point when the server has sent its first flight.
Otherwise, it is only complete when the client has sent its first Otherwise, it is only complete when the client has sent its first
flight, as it covers the client's Certificate and CertificateVerify. flight, as it covers the client's Certificate and CertificateVerify.
8.1.2. Diffie-Hellman 8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The A conventional Diffie-Hellman computation is performed [DH]. 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.
8.1.3. Elliptic Curve Diffie-Hellman 8.1.3. Elliptic Curve Diffie-Hellman
All ECDH calculations (including parameter and key generation as well All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6] as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation using the ECKAS-DH1 scheme with the identity map as key derivation
skipping to change at page 61, line 41 skipping to change at page 62, line 41
(Note that this use of the identity KDF is a technicality. The (Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything because TLS does not directly use the premaster secret for anything
other than for computing the master secret.) 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.4 for the suite TODO:Needs to be selected [1]. (See Appendix A.4 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
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
11. Security Considerations 11. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices D, E, and F. Appendices C, D, and E.
12. IANA Considerations 12. IANA Considerations
[[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]] [[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]]
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA has updated these to reference this document. The [RFC4346]. IANA has updated these to reference this document. The
registries and their allocation policies (unchanged from [RFC4346]) registries and their allocation policies (unchanged from [RFC4346])
are listed below. are listed below.
skipping to change at page 63, line 40 skipping to change at page 64, line 40
Use [RFC2434]. Use [RFC2434].
13. References 13. References
13.1. Normative References 13.1. Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", NIST FIPS 197, November 2001. (AES)", NIST FIPS 197, November 2001.
[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", NIST Department of Commerce, "Digital Signature Standard", NIST
FIPS PUB 186-2, 2000. FIPS PUB 186-2, 2000.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[SCH] Schneier, B., "Applied Cryptography: Protocols, [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
Algorithms, and Source Code in C, 2nd ed.", 1996. 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008.
[SHS] National Institute of Standards and Technology, U.S. [SHS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", NIST FIPS Department of Commerce, "Secure Hash Standard", NIST FIPS
PUB 180-2, August 2002. PUB 180-2, August 2002.
[TRIPLEDES]
National Institute of Standards and Technology,
"Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May
2004.
[X680] ITU-T, "Information technology - Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ISO/IEC One (ASN.1): Specification of basic notation", ISO/IEC
8824-1:2002, 2002. 8824-1:2002, 2002.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
13.2. Informative References 13.2. Informative References
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", May 2004, Problems and Countermeasures", May 2004,
<http://www.openssl.org/~bodo/tls-cbc.txt>. <https://www.openssl.org/~bodo/tls-cbc.txt>.
[CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality", May 2004,
<http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf>.
[DES] "Data Encryption Standard (DES)", NIST FIPS PUB 46-3,
October 1999.
[DSS-3] National Institute of Standards and Technology, U.S., [DSS-3] National Institute of Standards and Technology, U.S.,
"Digital Signature Standard", NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", NIST FIPS PUB 186-3 Draft,
2006. 2006.
[ECDSA] American National Standards Institute, "Public Key [ECDSA] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry: The Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
ANS X9.62-2005, November 2005. ANS X9.62-2005, November 2005.
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)",
2001.
[FI06] "Bleichenbacher's RSA signature forgery based on [FI06] "Bleichenbacher's RSA signature forgery based on
implementation error", August 2006, <http://www.imc.org/ implementation error", August 2006, <http://www.imc.org/
ietf-openpgp/mail-archive/msg14307.html>. ietf-openpgp/mail-archive/msg14307.html>.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007. Special Publication 800-38D, November 2007.
[I-D.ietf-tls-negotiated-ff-dhe] [I-D.ietf-tls-negotiated-ff-dhe]
Gillmor, D., "Negotiated Finite Field Diffie-Hellman Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
ff-dhe-07 (work in progress), March 2015. ff-dhe-10 (work in progress), June 2015.
[I-D.ietf-tls-session-hash] [I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf- Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-03 (work in progress), November 2014. tls-session-hash-05 (work in progress), April 2015.
[I-D.ietf-tls-sslv3-diediedie] [I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley, Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft- "Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-02 (work in progress), March ietf-tls-sslv3-diediedie-03 (work in progress), April
2015. 2015.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/
MIME", RFC 2785, March 2000.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002. 3268, June 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and 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 Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
skipping to change at page 67, line 33 skipping to change at page 67, line 48
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081, November Layer Security (TLS) Authentication", RFC 5081, November
2007. 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011. (SSL) Version 2.0", RFC 6176, March 2011.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
February 2015.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM v. 21, n. 2, pp. Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
120-126., February 1978. 120-126., February 1978.
[SSL2] Netscape Communications Corp., "The SSL Protocol", [SSL2] Netscape Communications Corp., "The SSL Protocol",
February 1995. February 1995.
[SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0
Protocol", November 1996. Protocol", November 1996.
[TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are
practical", USENIX Security Symposium, 2003. practical", USENIX Security Symposium, 2003.
[TLSEXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", February 2008.
[X501] "Information Technology - Open Systems Interconnection - [X501] "Information Technology - Open Systems Interconnection -
The Directory: Models", ITU-T X.501, 1993. The Directory: Models", ITU-T X.501, 1993.
13.3. 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.
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/
enum { enum {
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
A.2. Alert Messages A.2. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), unexpected_message(10), /* fatal */
bad_record_mac(20), bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), record_overflow(22), /* fatal */
decompression_failure_RESERVED(30), decompression_failure_RESERVED(30), /* fatal */
handshake_failure(40), handshake_failure(40), /* fatal */
no_certificate_RESERVED(41), no_certificate_RESERVED(41), /* fatal */
bad_certificate(42), bad_certificate(42),
unsupported_certificate(43), unsupported_certificate(43),
certificate_revoked(44), certificate_revoked(44),
certificate_expired(45), certificate_expired(45),
certificate_unknown(46), certificate_unknown(46),
illegal_parameter(47), illegal_parameter(47), /* fatal */
unknown_ca(48), unknown_ca(48), /* fatal */
access_denied(49), access_denied(49), /* fatal */
decode_error(50), decode_error(50), /* fatal */
decrypt_error(51), decrypt_error(51), /* fatal */
export_restriction_RESERVED(60), export_restriction_RESERVED(60), /* fatal */
protocol_version(70), protocol_version(70), /* fatal */
insufficient_security(71), insufficient_security(71), /* fatal */
internal_error(80), internal_error(80), /* fatal */
user_canceled(90), user_canceled(90),
no_renegotiation(100), no_renegotiation(100), /* fatal */
unsupported_extension(110), unsupported_extension(110), /* fatal */
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.3. Handshake Protocol A.3. Handshake Protocol
enum { enum {
skipping to change at page 71, line 37 skipping to change at page 71, line 37
A.3.1. Hello Messages A.3.1. Hello Messages
opaque SessionID<0..32>; opaque SessionID<0..32>;
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
skipping to change at page 72, line 31 skipping to change at page 72, line 31
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)
} ExtensionType; } ExtensionType;
struct { struct {
TLSCipherText messages<5 .. 2^24-1>; TLSCipherText messages<5 .. 2^24-1>;
} EarlyDataExtension; } EarlyDataExtension;
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
A.3.1.1. Signature Algorithm Extension A.3.1.1. Signature Algorithm Extension
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 73, line 22 skipping to change at page 73, line 22
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.3.1.2. Named Group Extension A.3.1.2. Named Group Extension
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3), sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6), sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9), sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12), sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15), sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18), secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21), secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24), secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2048(256), ffdhe3072(257), ffdhe4096(258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe8192(259), ffdhe6144 (259), ffdhe8192 (260),
ffdhe_private_use (0x01FC..0x01FF),
// Reserved Code Points. // Reserved Code Points.
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
reserved(0xFF01), reserved(0xFF01),
reserved(0xFF02), reserved(0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1> NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
A.3.2. Key Exchange Messages A.3.2. Key Exchange Messages
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } ClientKeyShareOffer;
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
opaque dh_Y<1..2^16-1>; opaque dh_Y<1..2^16-1>;
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ServerKeyShare; } ServerKeyShare;
A.3.3. Authentication Messages A.3.3. Authentication Messages
opaque ASN1Cert<1..2^24-1>; opaque ASN1Cert<1..2^24-1>;
struct { struct {
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
skipping to change at page 75, line 14 skipping to change at page 75, line 14
A.3.4. Handshake Finalization Messages A.3.4. Handshake Finalization Messages
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.4. The Cipher Suite A.4. The Cipher Suite
The following values define the cipher suite codes used in the The following values define the cipher suite codes used in the
ClientHello and ServerHello messages. ClientHello and ServerHello messages. A cipher suite defines a
cipher specification supported in TLS.
A cipher suite defines a cipher specification supported in TLS
Version 1.2.
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. DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the
Diffie-Hellman parameters are signed by a signature-capable 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. certificate from the client for client authentication.
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 suite definitions, defined in {{RFC5289}, are The following cipher suite definitions, defined in [RFC5289], are
used for server-authenticated (and optionally client-authenticated) used for server-authenticated (and optionally client-authenticated)
Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie- Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie-
Hellman, where the Diffie-Hellman parameters are signed by a Hellman, where the Diffie-Hellman parameters are signed by a
signature-capable certificate, which has been signed by the CA. The signature-capable certificate, which has been signed by the CA. The
signing algorithm used by the server is specified after the DHE signing algorithm used by the server is specified after the DHE
component of the CipherSuite name. The server can request any component of the CipherSuite name. The server can request any
signature-capable certificate from the client for client signature-capable certificate from the client for client
authentication. authentication.
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2B}; 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_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_128_GCM_SHA256 = {0xC0,0x2F};
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30}; CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
The following ciphers, defined in [RFC5288], are used for completely The following ciphers, defined in [RFC5288], are used for completely
anonymous Diffie-Hellman communications in which neither party is anonymous Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the- authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks. Using this mode therefore is of limited use: These middle attacks. Using this mode therefore is of limited use: These
cipher suites MUST NOT be used by TLS 1.2 implementations unless the cipher suites MUST NOT be used by TLS implementations unless the
application layer has specifically requested to allow anonymous key application layer has specifically requested to allow anonymous key
exchange. (Anonymous key exchange may sometimes be acceptable, for exchange. (Anonymous key exchange may sometimes be acceptable, for
example, to support opportunistic encryption when no set-up for example, to support opportunistic encryption when no set-up for
authentication is in place, or when TLS is used as part of more authentication is in place, or when TLS is used as part of more
complex security protocols that have other means to ensure 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.
skipping to change at page 76, line 48 skipping to change at page 76, line 43
SHA-256 as the hash function. SHA-256 as the hash function.
o For cipher suites ending with _SHA384, the PRF is the TLS PRF with o For cipher suites ending with _SHA384, the PRF is the TLS PRF with
SHA-384 as the hash function. SHA-384 as the hash function.
New cipher suite values are been assigned by IANA as described in 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.0.
A.5. The Security Parameters A.5. 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
to initialize a connection state. SecurityParameters includes: to initialize a connection state. SecurityParameters includes:
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_prf_sha256 } PRFAlgorithm;
skipping to change at page 77, line 25 skipping to change at page 77, line 19
enum { aes_gcm } RecordProtAlgorithm; enum { aes_gcm } RecordProtAlgorithm;
/* The algorithms specified in PRFAlgorithm and /* The algorithms specified in PRFAlgorithm and
RecordProtAlgorithm may be added to. */ RecordProtAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; PRFAlgorithm prf_algorithm;
RecordProtAlgorithm record_prot_algorithm; RecordProtAlgorithm record_prot_algorithm;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 iv_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
opaque hs_master_secret[48]; opaque hs_master_secret[48];
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
A.6. Changes to RFC 4492 A.6. Changes to RFC 4492
RFC 4492 [RFC4492] adds Elliptic Curve cipher suites to TLS. This RFC 4492 [RFC4492] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section. RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally- This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to algorithms used to create a signature. This change applies to
digital signatures formed using ECDSA as well, thus allowing ECDSA digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1, signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [RFC3280]. restrictions imposed by future revisions of [RFC5280].
As described in Section 7.3.5 and Section 7.3.9, the restrictions on As described in Section 7.3.5 and Section 7.3.9, the restrictions on
the signature algorithms used to sign certificates are no longer tied the signature algorithms used to sign certificates are no longer tied
to the cipher suite (when used by the server) or the to the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
the restrictions on the keys in the end-entity certificate remain. the restrictions on the keys in the end-entity certificate remain.
Appendix B. Glossary Appendix B. Cipher Suite Definitions
Advanced Encryption Standard (AES)
AES [AES] is a widely used symmetric encryption algorithm. AES is
a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte
block size. TLS currently only supports the 128- and 256-bit key
sizes.
application protocol
An application protocol is a protocol that normally layers
directly on top of the transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher
See public key cryptography.
authenticated encryption with additional data (AEAD)
A symmetric encryption algorithm that simultaneously provides
confidentiality and message integrity.
authentication
Authentication is the ability of one entity to determine the
identity of another entity.
certificate
As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key.
client
The application entity that initiates a TLS connection to a
server. This may or may not imply that the client initiated the
underlying transport connection. The primary operational
difference between the server and client is that the server is
generally authenticated, while the client is only optionally
authenticated.
client write key
The key used to protect data written by the client.
connection
A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such
connections are peer-to-peer relationships. The connections are
transient. Every connection is associated with one session.
Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and
Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
Standard", published January 2000 by the U.S. Department of
Commerce [DSS]. A significant update [DSS-3] has been drafted and
was published in March 2006.
digital signatures
Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate.
handshake
An initial negotiation between client and server that establishes
the parameters of their transactions.
Initialization Vector (IV)
Some AEAD ciphers require an initialization vector to allow the
cipher to safely protect multiple chunks of data with the same
keying material. The size of the IV depends on the cipher suite.
Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if the message
has been altered.
master secret
Secure secret data used for generating keys and IVs.
MD5
MD5 [RFC1321] is a hashing function that converts an arbitrarily
long data stream into a hash of fixed size (16 bytes). Due to
significant progress in cryptanalysis, at the time of publication
of this document, MD5 no longer can be considered a 'secure'
hashing function.
public key cryptography
A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be decrypted with
the associated private key. Conversely, messages signed with the
private key can be verified with the public key.
one-way hash function
A one-way transformation that converts an arbitrary amount of data
into a fixed-length hash. It is computationally hard to reverse
the transformation or to find collisions. MD5 and SHA are
examples of one-way hash functions.
RSA
A very widely used public key algorithm that can be used for
either encryption or digital signing. [RSA]
server
The server is the application entity that responds to requests for
connections from clients. See also "client".
session
A TLS session is an association between a client and a server.
Sessions are created by the handshake protocol. Sessions define a
set of cryptographic security parameters that can be shared among
multiple connections. Sessions are used to avoid the expensive
negotiation of new security parameters for each connection.
session identifier
A session identifier is a value generated by a server that
identifies a particular session.
server write key
The key used to protect data written by the server.
SHA
The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
(without a numerical suffix) actually use the modified SHA-1
algorithm.
SHA-256
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2.
It produces a 32-byte output.
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0.
Transport Layer Security (TLS)
This protocol; also, the Transport Layer Security working group of
the Internet Engineering Task Force (IETF). See "Working Group
Information" at the end of this document (see page 99).
Appendix C. Cipher Suite Definitions
Cipher Suite Key Record Cipher Suite Key Record
Exchange Protection PRF Exchange Protection PRF
TLS_NULL_WITH_NULL_NULL NULL NULL_NULL N/A TLS_NULL_WITH_NULL_NULL NULL NULL_NULL N/A
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA AES_128_GCM SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA AES_128_GCM SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE_RSA AES_256_GCM SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE_RSA AES_256_GCM SHA384
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE_DSS AES_128_GCM SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE_DSS AES_128_GCM SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE_DSS AES_256_GCM SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE_DSS AES_256_GCM SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256 DH_anon AES_128_GCM SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 DH_anon AES_128_GCM SHA256
TLS_DH_anon_WITH_AES_256_GCM_SHA384 DH_anon AES_128_GCM SHA384 TLS_DH_anon_WITH_AES_256_GCM_SHA384 DH_anon AES_128_GCM SHA384
Key Implicit IV Explicit IV Appendix C. Implementation Notes
Cipher Material Size Size
------------ -------- ---------- -----------
NULL 0 0 0
AES_128_GCM 16 4 8
AES_256_GCM 32 4 8
Key Material
The number of bytes from the key_block that are used for
generating the write keys.
Implicit IV Size
The amount of data to be generated for the per-connection part of
the initialization vector. This is equal to
SecurityParameters.fixed_iv_length).
Explicit IV Size
The amount of data needed to be generated for the per-record part
of the initialization vector. This is equal to
SecurityParameters.record_iv_length).
Appendix D. Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This The TLS protocol cannot prevent many common security mistakes. This
section provides several recommendations to assist implementors. section provides several recommendations to assist implementors.
D.1. Random Number Generation and Seeding C.1. Random Number Generation and Seeding
TLS requires a cryptographically secure pseudorandom number generator TLS requires a cryptographically secure pseudorandom number generator
(PRNG). Care must be taken in designing and seeding PRNGs. PRNGs (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
based on secure hash operations, most notably SHA-1, are acceptable, based on secure hash operations, most notably SHA-1, are acceptable,
but cannot provide more security than the size of the random number but cannot provide more security than the size of the random number
generator state. generator state.
To estimate the amount of seed material being produced, add the To estimate the amount of seed material being produced, add the
number of bits of unpredictable information in each seed byte. For number of bits of unpredictable information in each seed byte. For
example, keystroke timing values taken from a PC compatible's 18.2 Hz example, keystroke timing values taken from a PC compatible 18.2 Hz
timer provide 1 or 2 secure bits each, even though the total size of timer provide 1 or 2 secure bits each, even though the total size of
the counter value is 16 bits or more. Seeding a 128-bit PRNG would the counter value is 16 bits or more. Seeding a 128-bit PRNG would
thus require approximately 100 such timer values. thus require approximately 100 such timer values.
[RFC4086] provides guidance on the generation of random values. [RFC4086] provides guidance on the generation of random values.
D.2. Certificates and Authentication C.2. Certificates and Authentication
Implementations are responsible for verifying the integrity of Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation certificates and should generally support certificate revocation
messages. Certificates should always be verified to ensure proper messages. Certificates should always be verified to ensure proper
signing by a trusted Certificate Authority (CA). The selection and signing by a trusted Certificate Authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should addition of trusted CAs should be done very carefully. Users should
be able to view information about the certificate and root CA. be able to view information about the certificate and root CA.
D.3. Cipher Suites C.3. Cipher Suites
TLS supports a range of key sizes and security levels, including some TLS supports a range of key sizes and security levels, including some
that provide no or minimal security. A proper implementation will that provide no or minimal security. A proper implementation will
probably not support many cipher suites. For instance, anonymous probably not support many cipher suites. For instance, anonymous
Diffie-Hellman is strongly discouraged because it cannot prevent man- Diffie-Hellman is strongly discouraged because it cannot prevent man-
in-the-middle attacks. Applications should also enforce minimum and in-the-middle attacks. Applications should also enforce minimum and
maximum key sizes. For example, certificate chains containing 512- maximum key sizes. For example, certificate chains containing keys
bit RSA keys or signatures are not appropriate for high-security or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not
applications. appropriate for secure applications.
D.4. Implementation Pitfalls C.4. Implementation Pitfalls
Implementation experience has shown that certain parts of earlier TLS Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand, and have been a source of specifications are not easy to understand, and have been a source of
interoperability and security problems. Many of these areas have interoperability and security problems. Many of these areas have
been clarified in this document, but this appendix contains a short been clarified in this document, but this appendix contains a short
list of the most important things that require special attention from list of the most important things that require special attention from
implementors. implementors.
TLS protocol issues: TLS protocol issues:
- Do you correctly handle handshake messages that are fragmented to - Do you correctly handle handshake messages that are fragmented to
multiple TLS records (see Section 6.2.1)? Including corner cases multiple TLS records (see Section 6.2.1)? Including corner cases
like a ClientHello that is split to several small fragments? Do like a ClientHello that is split to several small fragments? Do
you fragment handshake messages that exceed the maximum fragment you fragment handshake messages that exceed the maximum fragment
size? In particular, the certificate and certificate request size? In particular, the certificate and certificate request
handshake messages can be large enough to require fragmentation. handshake messages can be large enough to require fragmentation.
- Do you ignore the TLS record layer version number in all TLS - Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)? records? (see Appendix D)
- Have you ensured that all support for SSL, RC4, and EXPORT ciphers
is completely removed from all possible configurations that
support TLS 1.3 or later, and that attempts to use these obsolete
capabilities fail correctly? (see Appendix D)
- Do you handle TLS extensions in ClientHello correctly, including - Do you handle TLS extensions in ClientHello correctly, including
omitting the extensions field completely? omitting the extensions field completely?
- When the server has requested a client certificate, but no - When the server has requested a client certificate, but no
suitable certificate is available, do you correctly send an empty suitable certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see Certificate message, instead of omitting the whole message (see
Section 7.3.9)? Section 7.3.9)?
Cryptographic details: Cryptographic details:
skipping to change at page 83, line 29 skipping to change at page 80, line 16
RSA signing operations [TIMING]. RSA signing operations [TIMING].
- When verifying RSA signatures, do you accept both NULL and missing - When verifying RSA signatures, do you accept both NULL and missing
parameters (see Section 4.7)? Do you verify that the RSA padding parameters (see Section 4.7)? Do you verify that the RSA padding
doesn't have additional data after the hash value? [FI06] doesn't have additional data after the hash value? [FI06]
- When using Diffie-Hellman key exchange, do you correctly strip - When using Diffie-Hellman key exchange, do you correctly strip
leading zero bytes from the negotiated key (see Section 8.1.2)? leading zero bytes from the negotiated key (see Section 8.1.2)?
- Does your TLS client check that the Diffie-Hellman parameters sent - Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable (see Appendix F.1.1.2)? by the server are acceptable (see Appendix E.1.1.2)?
- Do you use a strong and, most importantly, properly seeded random - Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix D.1) Diffie-Hellman private values, number generator (see Appendix C.1) Diffie-Hellman private values,
the DSA "k" parameter, and other security-critical values? the DSA "k" parameter, and other security-critical values?
Appendix E. Backward Compatibility Appendix D. Backward Compatibility
E.1. Compatibility with prior versions The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different
versions of TLS.
[[TODO: Revise backward compatibility section for TLS 1.3. TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
https://github.com/tlswg/tls13-spec/issues/54]] Since there are also handle clients trying to use future versions of TLS as long as
various versions of TLS (1.0, 1.1, 1.2, 1.3, and any future versions) the ClientHello format remains compatible and the client supports the
and SSL (2.0 and 3.0), means are needed to negotiate the specific highest protocol version available in the server.
protocol version to use. The TLS protocol provides a built-in
mechanism for version negotiation so as not to bother other protocol
components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use Prior versions of TLS used the record layer version number for
compatible ClientHello messages; thus, supporting all of them is various purposes. (TLSPlaintext.record_version &
relatively easy. Similarly, servers can easily handle clients trying TLSCiphertext.record_version) As of TLS 1.3, this field is deprecated
to use future versions of TLS as long as the ClientHello format and its value MUST be ignored by all implementations. Version
remains compatible, and the client supports the highest protocol negotiation is performed using only the handshake versions.
version available in the server. (ClientHello.client_version & ServerHello.server_version) In order to
maximize interoperability with older endpoints, implementations that
negotiate the usage of TLS 1.0-1.2 SHOULD set the record layer
version number to the negotiated version for the ServerHello and all
records thereafter.
D.1. Negotiating with an older server
A TLS 1.3 client who wishes to negotiate with such older servers will A TLS 1.3 client who wishes to negotiate with such older servers will
send a normal TLS 1.3 ClientHello, containing { 3, 4 } (TLS 1.3) in send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in
ClientHello.client_version. If the server does not support this ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older version it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol. negotiation will proceed as appropriate for the negotiated protocol.
A client resuming a session SHOULD initiate the connection using the
version that was previously negotiated.
If the version chosen by the server is not supported by the client If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert (or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection. message and close the connection.
If a TLS server receives a ClientHello containing a version number If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server. reply according to the highest version supported by the server.
Some legacy server implementations are known to not implement the TLS
specification properly and might abort connections upon encountering
TLS extensions or versions which it is not aware of.
Interoperability with buggy servers is a complex topic beyond the
scope of this document. Multiple connection attempts may be required
in order to negotiate a backwards compatible connection, however this
practice is vulnerable to downgrade attacks and is NOT RECOMMENDED.
D.2. Negotiating with an older client
A TLS server can also receive a ClientHello containing a version A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is proceed with a TLS 1.0 ServerHello. If the server only supports
willing to use) only versions greater than client_version, it MUST versions greater than client_version, it MUST send a
send a "protocol_version" alert message and close the connection. "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol version known to Note that earlier versions of TLS did not clearly specify the record
a server (for example, when resuming a session), it SHOULD initiate layer version number value in all cases
the connection in that native protocol. (TLSPlaintext.record_version). Servers will receive various TLS 1.x
versions in this field, however its value MUST always be ignored.
Note: some server implementations are known to implement version D.3. Backwards Compatibility Security Restrictions
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
Earlier versions of the TLS specification were not fully clear on If an implementation negotiates usage of TLS 1.2, then negotiation of
what the record layer version number (TLSPlaintext.version) should cipher suites also supported by TLS 1.3 SHOULD be preferred, if
contain when sending ClientHello (i.e., before it is known which available.
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any The security of RC4 cipher suites is considered insufficient for the
value {03,XX} as the record layer version number. Typical values reasons cited in [RFC7465]. Implementations MUST NOT offer or
would be {03,00}, the lowest version number supported by the client, negotiate RC4 cipher suites for any version of TLS for any reason.
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
E.2. Compatibility with SSL Old versions of TLS permitted the usage of very low strength ciphers.
Ciphers with a strength less than 112 bits MUST NOT be offered or
negotiated for any version of TLS for any reason.
The security of SSL 2.0 [SSL2] is considered insufficient for the The security of SSL 2.0 [SSL2] is considered insufficient for the
reasons enumerated in [RFC6176], and MUST NOT be negotiated for any reasons enumerated in [RFC6176], and MUST NOT be negotiated for any
reason. reason.
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS. order to negotiate older versions of TLS.
Implementations MUST NOT send or accept any records with a version Implementations MUST NOT send or accept any records with a version
less than { 3, 0 }. less than { 3, 0 }.
The security of SSL 3.0 [SSL3] is considered insufficient for the The security of SSL 3.0 [SSL3] is considered insufficient for the
reasons enumerated in [I-D.ietf-tls-sslv3-diediedie], and MUST NOT be reasons enumerated in [I-D.ietf-tls-sslv3-diediedie], and MUST NOT be
negotiated for any reason. negotiated for any reason.
Implementations MUST NOT send a ClientHello.version or Implementations MUST NOT send a ClientHello.client_version or
ServerHello.version set to { 3, 0 } or less. Any endpoint receiving ServerHello.server_version set to { 3, 0 } or less. Any endpoint
a Hello message with ClientHello.version or ServerHello.version set receiving a Hello message with ClientHello.client_version or
to { 3, 0 } MUST respond with a "protocol_version" alert message and ServerHello.server_version set to { 3, 0 } MUST respond with a
close the connection. "protocol_version" alert message and close the connection.
Appendix F. Security Analysis Appendix E. Security Analysis
The TLS protocol is designed to establish a secure connection between The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel. otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety This appendix outlines how TLS has been designed to resist a variety
of attacks. of attacks.
F.1. Handshake Protocol E.1. Handshake Protocol
The handshake protocol is responsible for selecting a cipher spec and The handshake protocol is responsible for selecting a cipher spec and
generating a master secret, which together comprise the primary generating a master secret, which together comprise the primary
cryptographic parameters associated with a secure session. The cryptographic parameters associated with a secure session. The
handshake protocol can also optionally authenticate parties who have handshake protocol can also optionally authenticate parties who have
certificates signed by a trusted certificate authority. certificates signed by a trusted certificate authority.
F.1.1. Authentication and Key Exchange E.1.1. Authentication and Key Exchange
TLS supports three authentication modes: authentication of both TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the server is authenticated, the channel total anonymity. Whenever the server is authenticated, the channel
is secure against man-in-the-middle attacks, but completely anonymous is secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated, servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain its certificate message must provide a valid certificate chain
leading to an acceptable certificate authority. Similarly, leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the authenticated clients must supply an acceptable certificate to the
skipping to change at page 86, line 28 skipping to change at page 83, line 28
The general goal of the key exchange process is to create a The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the attackers. The pre_master_secret will be used to generate the
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.3.8 and Section 6.3). By sending a correct Finished Section 7.3.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 E.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 share message, and the client's are sent in the client the server key share message, and the client's are sent in the client
key share message. Eavesdroppers who do not know the private values key share message. Eavesdroppers who do not know the private values
should not be able to find the Diffie-Hellman result (i.e., the should not be able to find the Diffie-Hellman result (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 E.1.1.2. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the client and server use When Diffie-Hellman key exchange is used, the client and server use
the client key exchange and server key exchange messages to send the client key exchange and server key exchange messages to send
temporary Diffie-Hellman parameters. The signature in the temporary Diffie-Hellman parameters. The signature in the
certificate verify message (if present) covers the entire handshake certificate verify message (if present) covers the entire handshake
up to that point and thus attests the certificate holder's desire to up to that point and thus attests the certificate holder's desire to
use the the ephemeral DHE keys. use the the ephemeral DHE keys.
Peers SHOULD validate each other's public key Y (dh_Ys offered by the Peers SHOULD validate each other's public key Y (dh_Ys offered by the
server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
This simple check ensures that the remote peer is properly behaved This simple check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup. and isn't forcing the local system into a small subgroup.
Additionally, using a fresh key for each handshake provides Perfect Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE cipher suites. handshake when using DHE cipher suites.
F.1.2. Version Rollback Attacks E.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
3.0 servers to detect the attack. This solution is not secure 3.0 servers to detect the attack. This solution is not secure
against attackers who can brute-force the key and substitute a new against attackers who can brute-force the key and substitute a new
ENCRYPTED-KEY-DATA message containing the same key (but with normal ENCRYPTED-KEY-DATA message containing the same key (but with normal
padding) before the application-specified wait threshold has expired. padding) before the application-specified wait threshold has expired.
Altering the padding of the least-significant 8 bytes of the PKCS Altering the padding of the least-significant 8 bytes of the PKCS
padding does not impact security for the size of the signed hashes padding does not impact security for the size of the signed hashes
and RSA key lengths used in the protocol, since this is essentially and RSA key lengths used in the protocol, since this is essentially
equivalent to increasing the input block size by 8 bytes. equivalent to increasing the input block size by 8 bytes.
F.1.3. Detecting Attacks Against the Handshake Protocol E.1.3. Detecting Attacks Against the Handshake Protocol
An attacker might try to influence the handshake exchange to make the An attacker might try to influence the handshake exchange to make the
parties select different encryption algorithms than they would parties select different encryption algorithms than they would
normally choose. normally choose.
For this attack, an attacker must actively change one or more For this attack, an attacker must actively change one or more
handshake messages. If this occurs, the client and server will handshake messages. If this occurs, the client and server will
compute different values for the handshake message hashes. As a compute different values for the handshake message hashes. As a
result, the parties will not accept each others' Finished messages. result, the parties will not accept each others' Finished messages.
Without the master_secret, the attacker cannot repair the Finished Without the master_secret, the attacker cannot repair the Finished
messages, so the attack will be discovered. messages, so the attack will be discovered.
F.1.4. Resuming Sessions E.1.4. Resuming Sessions
When a connection is established by resuming a session, new When a connection is established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the ClientHello.random and ServerHello.random values are hashed with the
session's master_secret. Provided that the master_secret has not session's master_secret. Provided that the master_secret has not
been compromised and that the secure hash operations used to produce been compromised and that the secure hash operations used to produce
the record protection kayes are secure, the connection should be the record protection keys are secure, the connection should be
secure and effectively independent from previous connections. secure and effectively independent from previous connections.
Attackers cannot use known keys to compromise the master_secret Attackers cannot use known keys to compromise the master_secret
without breaking the secure hash operations. without breaking the secure hash operations.
Sessions cannot be resumed unless both the client and server agree. Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised, If either party suspects that the session may have been compromised,
or that certificates may have expired or been revoked, it should or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is suggested for force a full handshake. An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the may be able to impersonate the compromised party until the
corresponding session ID is retired. Applications that may be run in corresponding session ID is retired. Applications that may be run in
relatively insecure environments should not write session IDs to relatively insecure environments should not write session IDs to
stable storage. stable storage.
F.2. Protecting Application Data E.2. Protecting Application Data
The master_secret is hashed with the ClientHello.random and The master_secret is hashed with the ClientHello.random and
ServerHello.random to produce unique record protection secrets for ServerHello.random to produce unique record protection secrets for
each connection. each connection.
Outgoing data is protected using an AEAD algorithm before Outgoing data is protected using an AEAD algorithm before
transmission. The authentication data includes the sequence number, transmission. The authentication data includes the sequence number,
message type, message length, and the message contents. The message message type, message length, and the message contents. The message
type field is necessary to ensure that messages intended for one TLS type field is necessary to ensure that messages intended for one TLS
record layer client are not redirected to another. The sequence record layer client are not redirected to another. The sequence
number ensures that attempts to delete or reorder messages will be number ensures that attempts to delete or reorder messages will be
detected. Since sequence numbers are 64 bits long, they should never detected. Since sequence numbers are 64 bits long, they should never
overflow. Messages from one party cannot be inserted into the overflow. Messages from one party cannot be inserted into the
other's output, since they use independent keys. other's output, since they use independent keys.
F.3. Denial of Service E.3. Denial of Service
TLS is susceptible to a number of denial-of-service (DoS) attacks. TLS is susceptible to a number of denial-of-service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing connections can cause a server to consume large amounts of CPU doing
asymmetric crypto operations. However, because TLS is generally used asymmetric crypto operations. However, because TLS is generally used
over TCP, it is difficult for the attacker to hide his point of over TCP, it is difficult for the attacker to hide his point of
origin if proper TCP SYN randomization is used [RFC1948] by the TCP origin if proper TCP SYN randomization is used [RFC1948] by the TCP
stack. stack.
Because TLS runs over TCP, it is also susceptible to a number of DoS Because TLS runs over TCP, it is also susceptible to a number of DoS
attacks on individual connections. In particular, attackers can attacks on individual connections. In particular, attackers can
forge RSTs, thereby terminating connections, or forge partial TLS forge RSTs, thereby terminating connections, or forge partial TLS
records, thereby causing the connection to stall. These attacks records, thereby causing the connection to stall. These attacks
cannot in general be defended against by a TCP-using protocol. cannot in general be defended against by a TCP-using protocol.
Implementors or users who are concerned with this class of attack Implementors or users who are concerned with this class of attack
should use IPsec AH [RFC4302] or ESP [RFC4303]. should use IPsec AH [RFC4302] or ESP [RFC4303].
F.4. Final Notes E.4. Final Notes
For TLS to be able to provide a secure connection, both the client For TLS to be able to provide a secure connection, both the client
and server systems, keys, and applications must be secure. In and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors. addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and and users must be careful when deciding which certificates and
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 F. 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: http://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/tls/current/index.html archive/web/tls/current/index.html
Appendix H. Contributors Appendix G. Contributors
Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures
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
Karthikeyan Bhargavan (co-author of [I-D.ietf-tls-session-hash]) Christopher Allen (co-editor of TLS 1.0)
INRIA Alacrity Ventures
karthikeyan.bhargavan@inria.fr ChristopherA@AlacrityManagement.com
Steven M. Bellovin Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Benjamin Beurdouche
Karthikeyan Bhargavan (co-author of [I-D.ietf-tls-session-hash])
INRIA
karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson (co-author of RFC4492) Simon Blake-Wilson (co-author of RFC4492)
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
Nelson Bolyard Nelson Bolyard
Sun Microsystems, Inc. Sun Microsystems, Inc.
nelson@bolyard.com (co-author of RFC4492) 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
skipping to change at page 90, line 24 skipping to change at page 87, line 25
Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash]) Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash])
INRIA INRIA
antoine.delignat-lavaud@inria.fr antoine.delignat-lavaud@inria.fr
Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
Independent Independent
tim@dierks.org tim@dierks.org
Taher Elgamal Taher Elgamal
taher@securify.com
Securify Securify
taher@securify.com
Pasi Eronen Pasi Eronen
pasi.eronen@nokia.com
Nokia Nokia
pasi.eronen@nokia.com
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
David M. Garrett
Vipul Gupta (co-author of RFC4492) Vipul Gupta (co-author of RFC4492)
Sun Microsystems Laboratories Sun Microsystems Laboratories
vipul.gupta@sun.com vipul.gupta@sun.com
Kipp Hickman
Chris Hawk (co-author of RFC4492) Chris Hawk (co-author of RFC4492)
Corriente Networks LLC Corriente Networks LLC
chris@corriente.net chris@corriente.net
Kipp Hickman
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 Daniel Kahn Gillmor
ACLU ACLU
dkg@fifthhorseman.net dkg@fifthhorseman.net
Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3) Phil Karlton (co-author of SSL 3.0)
Paul Kocher (co-author of SSL 3.0)
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
Adam Langley (co-author of [I-D.ietf-tls-session-hash]) Adam Langley (co-author of [I-D.ietf-tls-session-hash])
Google Google
agl@google.com agl@google.com
 End of changes. 215 change blocks. 
665 lines changed or deleted 522 lines changed or added

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