draft-ietf-tls-tls13-08.txt   draft-ietf-tls-tls13-09.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246, 5746 (if August 28, 2015 Obsoletes: 5077, 5246, 5746 (if October 05, 2015
approved) approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 29, 2016 Expires: April 7, 2016
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-08 draft-ietf-tls-tls13-09
Abstract Abstract
This document specifies Version 1.3 of the Transport Layer Security This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol. The TLS protocol allows client/server applications (TLS) protocol. The TLS protocol allows client/server applications
to communicate over the Internet in a way that is designed to prevent to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery. eavesdropping, tampering, and message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 29, 2016. This Internet-Draft will expire on April 7, 2016.
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 25 skipping to change at page 2, line 25
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 9
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 9 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 9
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 9
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 12 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 14 4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 14
4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 14 4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 15
4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 14 4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 15
4.9.2. Authenticated Encryption with Additional Data (AEAD) 16 4.9.2. Authenticated Encryption with Additional Data (AEAD) 16
5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16 5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16
5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17
5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19
5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21 5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21
6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23 5.2.3. Record Padding . . . . . . . . . . . . . . . . . . . 23
6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23 6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 24
6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25 6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26 6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 26
6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 30 6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 33 6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 31
6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 34 6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 34
6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 36 6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 35
6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 37
6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 38 6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 39
6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 38 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 40
6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 43 6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 44
6.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 56 6.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 57
6.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 56 6.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 58
6.3.5. Server Certificate . . . . . . . . . . . . . . . . . 57 6.3.5. Server Certificate . . . . . . . . . . . . . . . . . 58
6.3.6. Certificate Request . . . . . . . . . . . . . . . . . 60 6.3.6. Certificate Request . . . . . . . . . . . . . . . . . 61
6.3.7. Server Configuration . . . . . . . . . . . . . . . . 61 6.3.7. Server Configuration . . . . . . . . . . . . . . . . 62
6.3.8. Server Certificate Verify . . . . . . . . . . . . . . 63 6.3.8. Server Certificate Verify . . . . . . . . . . . . . . 64
6.3.9. Server Finished . . . . . . . . . . . . . . . . . . . 64 6.3.9. Server Finished . . . . . . . . . . . . . . . . . . . 65
6.3.10. Client Certificate . . . . . . . . . . . . . . . . . 65 6.3.10. Client Certificate . . . . . . . . . . . . . . . . . 66
6.3.11. Client Certificate Verify . . . . . . . . . . . . . . 67 6.3.11. Client Certificate Verify . . . . . . . . . . . . . . 67
6.3.12. New Session Ticket Message . . . . . . . . . . . . . 68 6.3.12. New Session Ticket Message . . . . . . . . . . . . . 68
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 68 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 69
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 69 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 69
7.2. Traffic Key Calculation . . . . . . . . . . . . . . . . . 70 7.2. Traffic Key Calculation . . . . . . . . . . . . . . . . . 71
7.2.1. The Handshake Hash . . . . . . . . . . . . . . . . . 71 7.2.1. The Handshake Hash . . . . . . . . . . . . . . . . . 72
7.2.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 72 7.2.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 73
7.2.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 72 7.2.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 73
8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 72 8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 73
8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 73 8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 73
8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 73 8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 74
9. Application Data Protocol . . . . . . . . . . . . . . . . . . 74 9. Application Data Protocol . . . . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 75
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.1. Normative References . . . . . . . . . . . . . . . . . . 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 76
12.2. Informative References . . . . . . . . . . . . . . . . . 77 12.2. Informative References . . . . . . . . . . . . . . . . . 79
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Appendix A. Protocol Data Structures and Constant Values . . . . 83
Appendix A. Protocol Data Structures and Constant Values . . . . 81 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 83
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 81 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 83
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 81 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 84
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 82 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 85
A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 83 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 89
A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 86 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 89
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 87 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 90
A.3.4. Handshake Finalization Messages . . . . . . . . . . . 88 A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 90
A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 88 A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 91
A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 88 A.4.1. Unauthenticated Operation . . . . . . . . . . . . . . 92
A.5. The Security Parameters . . . . . . . . . . . . . . . . . 91 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 93
A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 91 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 94
Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 92 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 94
B.1. Random Number Generation and Seeding . . . . . . . . . . 92 B.1. Random Number Generation and Seeding . . . . . . . . . . 94
B.2. Certificates and Authentication . . . . . . . . . . . . . 92 B.2. Certificates and Authentication . . . . . . . . . . . . . 95
B.3. Cipher Suite Support . . . . . . . . . . . . . . . . . . 93 B.3. Cipher Suite Support . . . . . . . . . . . . . . . . . . 95
B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 93 B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 95
Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 94 Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 96
C.1. Negotiating with an older server . . . . . . . . . . . . 95 C.1. Negotiating with an older server . . . . . . . . . . . . 97
C.2. Negotiating with an older client . . . . . . . . . . . . 95 C.2. Negotiating with an older client . . . . . . . . . . . . 97
C.3. Backwards Compatibility Security Restrictions . . . . . . 96 C.3. Backwards Compatibility Security Restrictions . . . . . . 98
Appendix D. Security Analysis . . . . . . . . . . . . . . . . . 96 Appendix D. Security Analysis . . . . . . . . . . . . . . . . . 99
D.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 97 D.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 99
D.1.1. Authentication and Key Exchange . . . . . . . . . . . 97 D.1.1. Authentication and Key Exchange . . . . . . . . . . . 99
D.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 98 D.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 100
D.1.3. Detecting Attacks Against the Handshake Protocol . . 98 D.1.3. Detecting Attacks Against the Handshake Protocol . . 100
D.2. Protecting Application Data . . . . . . . . . . . . . . . 99 D.2. Protecting Application Data . . . . . . . . . . . . . . . 101
D.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 99 D.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 101
D.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 99 D.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 101
Appendix E. Working Group Information . . . . . . . . . . . . . 100 Appendix E. Working Group Information . . . . . . . . . . . . . 102
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 100 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 102
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 14 skipping to change at page 5, line 14
The TLS Record Protocol is used for encapsulation of various higher- The TLS Record Protocol is used for encapsulation of various higher-
level protocols. One such encapsulated protocol, the TLS Handshake level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of the application protocol transmits or receives its first byte of
data. The TLS Handshake Protocol provides connection security that data. The TLS Handshake Protocol provides connection security that
has three basic properties: has three basic properties:
- The peer's identity can be authenticated using asymmetric, or - The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This public key, cryptography (e.g., RSA [RSA], ECDSA [ECDSA], etc.).
authentication can be made optional, but is generally required for This authentication can be made optional, but is generally
at least one of the peers. required for at least one of the peers.
- The negotiation of a shared secret is secure: the negotiated - The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection. can place himself in the middle of the connection.
- The negotiation is reliable: no attacker can modify the - The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties to negotiation communication without being detected by the parties to
the communication. the communication.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
sender: An endpoint that is transmitting records. sender: An endpoint that is transmitting records.
session: An association between a client and a server resulting from session: An association between a client and a server resulting from
a handshake. a handshake.
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-09
- Change to RSA-PSS signatures for handshake messages.
- Remove support for DSA.
- Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern
Tackmann.
- Add support for per-record padding.
- Switch to encrypted record ContentType.
- Change HKDF labeling to include protocol version and value
lengths.
- Shift the final decision to abort a handshake due to incompatible
certificates to the client rather than having servers abort early.
- Deprecate SHA-1 with signatures.
- Add MTI algorithms.
draft-08 draft-08
- Remove support for weak and lesser used named curves. - Remove support for weak and lesser used named curves.
- Remove support for MD5 and SHA-224 hashes with signatures. - Remove support for MD5 and SHA-224 hashes with signatures.
- Update lists of available AEAD cipher suites and error alerts. - Update lists of available AEAD cipher suites and error alerts.
- Reduce maximum permitted record expansion for AEAD from 2048 to - Reduce maximum permitted record expansion for AEAD from 2048 to
256 octets. 256 octets.
skipping to change at page 7, line 5 skipping to change at page 7, line 28
- Integration of semi-ephemeral DH proposal. - Integration of semi-ephemeral DH proposal.
- Add initial 0-RTT support. - Add initial 0-RTT support.
- Remove resumption and replace with PSK + tickets. - Remove resumption and replace with PSK + tickets.
- Move ClientKeyShare into an extension. - Move ClientKeyShare into an extension.
- Move to HKDF. - Move to HKDF.
draft-06
- Prohibit RC4 negotiation for backwards compatibility. - Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field. - Freeze & deprecate record layer version field.
- Update format of signatures with context. - Update format of signatures with context.
- Remove explicit IV. - Remove explicit IV.
draft-05 draft-05
skipping to change at page 15, line 14 skipping to change at page 15, line 47
Following that padding is a NUL-terminated context string in order to Following that padding is a NUL-terminated context string in order to
disambiguate signatures for different purposes. The context string disambiguate signatures for different purposes. The context string
will be specified whenever a digitally-signed element is used. will be specified whenever a digitally-signed element is used.
Finally, the specified contents of the digitally-signed structure Finally, the specified contents of the digitally-signed structure
follow the NUL at the end of the context string. (See the example at follow the NUL at the end of the context string. (See the example at
the end of this section.) the end of this section.)
In RSA signing, the opaque vector contains the signature generated In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447]. using the RSASSA-PSS signature scheme defined in [RFC3447] with MGF1.
As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680] The digest used in the mask generation function MUST be the same as
[X690]. For hash algorithms without parameters (which includes SHA- the digest which is being signed (i.e., what appears in
1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL, algorithm.signature). Note that previous versions of TLS used
but implementations MUST accept both without parameters and with NULL RSASSA-PKCS1-v1_5, not RSASSA-PSS.
parameters. Note that earlier versions of TLS used a different RSA
signature scheme that did not include a DigestInfo encoding.
In DSA, the 20 bytes of the SHA-1 hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces
two values, r and s. The DSA signature is an opaque vector, as
above, the contents of which are the DER encoding of:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Note: In current terminology, DSA refers to the Digital Signature
Algorithm and DSS refers to the NIST standard. In the original SSL
and TLS specs, "DSS" was used universally. This document uses "DSA"
to refer to the algorithm, "DSS" to refer to the standard, and it
uses "DSS" in the code point definitions for historical continuity.
All ECDSA computations MUST be performed according to ANSI X9.62 All ECDSA computations MUST be performed according to ANSI X9.62
[X962] or its successors. Data to be signed/verified is hashed, and [X962] or its successors. Data to be signed/verified is hashed, and
the result run directly through the ECDSA algorithm with no the result run directly through the ECDSA algorithm with no
additional hashing. The default hash function is SHA-1 [SHS]. additional hashing. The SignatureAndHashAlgorithm parameter in the
However, an alternative hash function, such as one of the new SHA DigitallySigned object indicates the digest algorithm which was used
hash functions specified in FIPS 180-2 may be used instead if the in the signature.
certificate containing the EC public key explicitly requires use of
another hash function. (The mechanism for specifying the required
hash function has not been standardized, but this provision
anticipates such standardization and obviates the need to update this
document in response. Future PKIX RFCs may choose, for example, to
specify the hash function to be used with a public key in the
parameters field of subjectPublicKeyInfo.) [[OPEN ISSUE: This needs
updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]
4.9.2. Authenticated Encryption with Additional Data (AEAD)
In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length, and aead-
ciphered output is generally larger than the input in order to
accommodate the integrity check value.
In the following example In the following example
struct { struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
digitally-signed opaque { digitally-signed opaque {
uint8 field3<0..255>; uint8 field3<0..255>;
uint8 field4; uint8 field4;
}; };
skipping to change at page 16, line 39 skipping to change at page 16, line 39
followed by the encoding of the inner struct (field3 and field4). followed by the encoding of the inner struct (field3 and field4).
The length of the structure, in bytes, would be equal to two bytes The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature and hash for field1 and field2, plus two bytes for the signature and hash
algorithm, plus two bytes for the length of the signature, plus the algorithm, plus two bytes for the length of the signature, plus the
length of the output of the signing algorithm. The length of the length of the output of the signing algorithm. The length of the
signature is known because the algorithm and key used for the signing signature is known because the algorithm and key used for the signing
are known prior to encoding or decoding this structure. are known prior to encoding or decoding this structure.
4.9.2. Authenticated Encryption with Additional Data (AEAD)
In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length, and aead-
ciphered output is generally larger than the input in order to
accommodate the integrity check value.
5. The TLS Record Protocol 5. The TLS Record Protocol
The TLS Record Protocol is a layered protocol. At each layer, The TLS Record Protocol is a layered protocol. At each layer,
messages may include fields for length, description, and content. messages may include fields for length, description, and content.
The TLS Record Protocol takes messages to be transmitted, fragments The TLS Record Protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits
the result. Received data is decrypted and verified, reassembled, the result. Received data is decrypted and verified, reassembled,
and then delivered to higher-level clients. and then delivered to higher-level clients.
Three protocols that use the TLS Record Protocol are described in Three protocols that use the TLS Record Protocol are described in
skipping to change at page 17, line 18 skipping to change at page 17, line 25
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 the length of a record or absence of traffic
by encryption. If this information is itself sensitive, application itself is not protected by encryption unless the sender uses the
designers may wish to take steps (e.g., padding, cover traffic) to supplied padding mechanism - see Section 5.2.3 for more details.
minimize information leakage.
5.1. Connection States 5.1. Connection States
[[TODO: I plan to totally rewrite or remove this. IT seems like just [[TODO: I plan to totally rewrite or remove this. IT seems like just
cruft.]] cruft.]]
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a record protection algorithm and its Protocol. It specifies a record protection algorithm and its
parameters as well as the record protection keys and IVs for the parameters as well as the record protection keys and IVs for the
connection in both the read and the write directions. The security connection in both the read and the write directions. The security
skipping to change at page 19, line 44 skipping to change at page 20, line 4
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.
5.2.1. Fragmentation 5.2.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Client records carrying data in chunks of 2^14 bytes or less. Client
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). Alert messages Section 6.1 MUST
NOT be fragmented across records.
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(0),
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), early_handshake(25), application_data(23), early_handshake(25),
(255) (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
skipping to change at page 20, line 49 skipping to change at page 21, line 6
This document describes TLS Version 1.3, which uses the version { 3, 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 { 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 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 backwards compatibility, the record layer version identifies as
simply TLS 1.0. Endpoints supporting other versions negotiate the simply TLS 1.0. Endpoints supporting other versions negotiate the
version to use by following the procedure and requirements in version to use by following the procedure and requirements in
Appendix C. Appendix C.
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, even if those fragments contain padding. Zero-length
as they are potentially useful as a traffic analysis countermeasure. fragments of Application data MAY be sent as they are potentially
useful as a traffic analysis countermeasure.
When record protection has not yet been engaged, TLSPlaintext
structures are written directly onto the wire. Once record
protection has started, TLSPlaintext records are protected and sent
as described in the following section.
5.2.2. Record Payload Protection 5.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 modeled 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 opaque_type = application_data(23); /* see fragment.type */
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length;
aead-ciphered struct {
opaque content[TLSPlaintext.length];
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint8 zeros[length_of_padding];
uint16 length; } fragment;
aead-ciphered struct { } TLSCiphertext;
opaque content[TLSPlaintext.length];
} fragment;
} TLSCiphertext;
type opaque_type
The type field is identical to TLSPlaintext.type. The outer opaque_type field of a TLSCiphertext record is always
set to the value 23 (application_data) for outward compatibility
with middleboxes used to parsing previous versions of TLS. The
actual content type of the record is found in fragment.type after
decryption.
record_version record_version
The record_version field is identical to The record_version field is identical to
TLSPlaintext.record_version and is always { 3, 1 }. Note that the TLSPlaintext.record_version and is always { 3, 1 }. Note that the
handshake protocol including the ClientHello and ServerHello handshake protocol including the ClientHello and ServerHello
messages authenticates the protocol version, so this value is messages authenticates the protocol version, so this value is
redundant. redundant.
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 + 256. An endpoint that receives The length MUST NOT exceed 2^14 + 256. An endpoint that receives
a record that exceeds this length MUST generate a fatal a record that exceeds this length MUST generate a fatal
"record_overflow" alert. "record_overflow" alert.
fragment.content
The cleartext of TLSPlaintext.fragment.
fragment.type
The actual content type of the record.
fragment.zeros
An arbitrary-length run of zero-valued bytes may appear in the
cleartext after the type field. This provides an opportunity for
senders to pad any TLS record by a chosen amount as long as the
total stays within record size limits. See Section 5.2.3 for more
details.
fragment fragment
The AEAD encrypted form of TLSPlaintext.fragment. The AEAD encrypted form of TLSPlaintext.fragment +
TLSPlaintext.type + zeros, where "+" denotes concatenation.
The length of the per-record nonce (iv_length) is set to max(8 bytes, The length of the per-record nonce (iv_length) is set to max(8 bytes,
N_MIN) for the AEAD algorithm (see [RFC5116] Section 4). An AEAD N_MIN) for the AEAD algorithm (see [RFC5116] Section 4). An AEAD
algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS. algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS.
The per-record nonce for the AEAD construction is formed as follows: The per-record nonce for the AEAD construction is formed as follows:
1. The 64-bit record sequence number is padded to the left with 1. The 64-bit record sequence number is padded to the left with
zeroes to iv_length. zeroes to iv_length.
2. The padded sequence number is XORed with the static 2. The padded sequence number is XORed with the static
client_write_iv or server_write_iv, depending on the role. client_write_iv or server_write_iv, depending on the role.
The resulting quantity (of length iv_length) is used as the per- The resulting quantity (of length iv_length) is used as the per-
record nonce. record nonce.
Note: This is a different construction from that in TLS 1.2, which Note: This is a different construction from that in TLS 1.2, which
specified a partially explicit nonce. specified a partially explicit nonce.
The plaintext is the TLSPlaintext.fragment. The plaintext is the concatenation of TLSPlaintext.fragment and
TLSPlaintext.type.
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.record_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
encryption operation. The length will generally be larger than encryption operation. The length of the plaintext is greater than
TLSPlaintext.length, but by an amount that varies with the AEAD TLSPlaintext.length due to the inclusion of TLSPlaintext.type and
cipher. Since the ciphers might incorporate padding, the amount of however much padding is supplied by the sender. The length of
overhead could vary with different TLSPlaintext.length values. aead_output will generally be larger than the plaintext, but by an
Symbolically, amount that varies with the AEAD cipher. Since the ciphers might
incorporate padding, the amount of overhead could vary with different
lengths of plaintext. Symbolically,
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext of fragment,
additional_data) additional_data)
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, plaintext of 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.
An AEAD cipher MUST NOT produce an expansion of greater than 256 An AEAD cipher MUST NOT produce an expansion of greater than 255
bytes. An endpoint that receives a record that is larger than 2^14 + bytes. An endpoint that receives a record from its peer with
256 octets MUST generate a fatal "record_overflow" alert. TLSCipherText.length larger than 2^14 + 256 octets MUST generate a
fatal "record_overflow" alert. This limit is derived from the
maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType
+ the maximum AEAD expansion of 255 octets.
As a special case, we define the NULL_NULL AEAD cipher which is 5.2.3. Record Padding
simply the identity operation and thus provides no security. This
cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL All encrypted TLS records can be padded to inflate the size of the
cipher suite. TLSCipherText. This allows the sender to hide the size of the
traffic from an observer.
When generating a TLSCiphertext record, implementations MAY choose to
pad. An unpadded record is just a record with a padding length of
zero. Padding is a string of zero-valued bytes appended to the
ContentType field before encryption. Implementations MUST set the
padding octets to all zeros before encrypting.
Application Data records may contain a zero-length fragment.content
if the sender desires. This permits generation of plausibly-sized
cover traffic in contexts where the presence or absence of activity
may be sensitive. Implementations MUST NOT send Handshake or Alert
records that have a zero-length fragment.content.
The padding sent is automatically verified by the record protection
mechanism: Upon successful decryption of a TLSCiphertext.fragment,
the receiving implementation scans the field from the end toward the
beginning until it finds a non-zero octet. This non-zero octet is
the content type of the message.
Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption. If a receiving implementation does not
find a non-zero octet in the cleartext, it should treat the record as
having an unexpected ContentType, sending an "unexpected_message"
alert.
The presence of padding does not change the overall record size
limitations - the full fragment plaintext may not exceed 2^14 octets.
Versions of TLS prior to 1.3 had limited support for padding. This
padding scheme was selected because it allows padding of any
encrypted TLS record by an arbitrary size (from zero up to TLS record
size limits) without introducing new content types. The design also
enforces all-zero padding octets, which allows for quick detection of
padding errors.
Selecting a padding policy that suggests when and how much to pad is
a complex topic, and is beyond the scope of this specification. If
the application layer protocol atop TLS permits padding, it may be
preferable to pad application_data TLS records within the application
layer. Padding for encrypted handshake and alert TLS records must
still be handled at the TLS layer, though. Later documents may
define padding selection algorithms, or define a padding policy
request mechanism through TLS extensions or some other means.
6. The TLS Handshaking Protocols 6. 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 TLS Handshake Protocol is responsible for negotiating a session, The TLS Handshake Protocol is responsible for negotiating a session,
which consists of the following items: which consists of the following items:
skipping to change at page 24, line 14 skipping to change at page 26, line 11
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), /* fatal */ unexpected_message(10), /* fatal */
bad_record_mac(20), /* fatal */ bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), /* fatal */ record_overflow(22), /* fatal */
decompression_failure_RESERVED(30), /* fatal */
handshake_failure(40), /* fatal */ handshake_failure(40), /* fatal */
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), /* fatal */ illegal_parameter(47), /* fatal */
unknown_ca(48), /* fatal */ unknown_ca(48), /* fatal */
access_denied(49), /* fatal */ access_denied(49), /* fatal */
decode_error(50), /* fatal */ decode_error(50), /* fatal */
decrypt_error(51), /* fatal */ decrypt_error(51), /* fatal */
export_restriction_RESERVED(60), /* fatal */
protocol_version(70), /* fatal */ protocol_version(70), /* fatal */
insufficient_security(71), /* fatal */ insufficient_security(71), /* fatal */
internal_error(80), /* fatal */ internal_error(80), /* fatal */
inappropriate_fallback(86), /* fatal */ inappropriate_fallback(86), /* fatal */
user_canceled(90), user_canceled(90),
no_renegotiation_RESERVED(100), /* fatal */
missing_extension(109), /* fatal */ missing_extension(109), /* fatal */
unsupported_extension(110), /* fatal */ unsupported_extension(110), /* fatal */
certificate_unobtainable(111), certificate_unobtainable(111),
unrecognized_name(112), unrecognized_name(112),
bad_certificate_status_response(113), /* fatal */ bad_certificate_status_response(113), /* fatal */
bad_certificate_hash_value(114), /* fatal */ bad_certificate_hash_value(114), /* fatal */
unknown_psk_identity(115), unknown_psk_identity(115),
(255) (255)
} AlertDescription; } AlertDescription;
skipping to change at page 26, line 52 skipping to change at page 28, line 39
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 alert is used for all deprotection failures. verification, this alert is used for all deprotection failures.
This alert is always fatal and should never be observed in This alert 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
This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode [CBCATT]. It MUST
NOT be sent by compliant implementations. This alert 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 + 256 bytes, or a record decrypted to a TLSPlaintext record 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes. This alert is always fatal and should with more than 2^14 bytes. This alert is always fatal and should
never be observed in communication between proper implementations never be observed in communication between proper implementations
(except when messages were corrupted in the network). (except when messages were corrupted in the network).
decompression_failure_RESERVED
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
alert when in TLS 1.3 mode. This alert is always fatal.
handshake_failure handshake_failure
Reception of a "handshake_failure" alert message indicates that Reception of a "handshake_failure" alert message indicates that
the 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 alert is always parameters given the options available. This alert is always
fatal. fatal.
no_certificate_RESERVED
This alert was used in SSL 3.0 but not any version of TLS. It
MUST NOT be sent by compliant implementations. This alert 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 28 skipping to change at page 29, line 49
specified range or the length of the message was incorrect. This specified range or the length of the message was incorrect. This
alert is always fatal and should never be observed in alert 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).
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 alert is always fatal. This alert is always fatal.
export_restriction_RESERVED
This alert was used in some earlier versions of TLS. It MUST NOT
be sent by compliant implementations. This alert is always fatal.
protocol_version protocol_version
The protocol version the peer 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 alert is always might be avoided for security reasons.) This alert 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 alert is always secure than those supported by the client. This alert is always
skipping to change at page 29, line 5 skipping to change at page 30, line 22
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 alert is always fatal. to continue. This alert is always fatal.
inappropriate_fallback inappropriate_fallback
Sent by a server in response to an invalid connection retry Sent by a server in response to an invalid connection retry
attempt from a client. (see [RFC7507]) This alert is always fatal. attempt from a client. (see [RFC7507]) This alert is always fatal.
no_renegotiation_RESERVED
This alert was used in previous versions of TLS. TLS 1.3 does not
include renegotiation and TLS 1.3 implementations MUST NOT send
this alert when in TLS 1.3 mode. This alert is always fatal.
missing_extension missing_extension
Sent by endpoints that receive a hello message not containing an Sent by endpoints that receive a hello message not containing an
extension that is mandatory to send for the offered TLS version. extension that is mandatory to send for the offered TLS version.
This message is always fatal. [[TODO: IANA Considerations.]] This message is always fatal. [[TODO: IANA Considerations.]]
unsupported_extension unsupported_extension
Sent by endpoints receiving any hello message containing an Sent by endpoints receiving any hello message containing an
extension known to be prohibited for inclusion in the given hello extension known to be prohibited for inclusion in the given hello
message, including any extensions in a ServerHello not first message, including any extensions in a ServerHello not first
offered in the corresponding ClientHello. This alert is always offered in the corresponding ClientHello. This alert is always
skipping to change at page 37, line 38 skipping to change at page 38, line 38
ServerHello ServerHello
+PreSharedKeyExtension +PreSharedKeyExtension
{EncryptedExtensions} {EncryptedExtensions}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 4: Message flow for resumption and PSK Figure 4: Message flow for resumption and PSK
Note that the client supplies a ClientKeyShare to the server as well, As the server is authenticating via a PSK, it does not send a
which allows the server to decline resumption and fall back to a full Certificate or a CertificateVerify. PSK-based resumption cannot be
handshake. However, because the server is authenticating via a PSK, used to provide a new ServerConfiguration. Note that the client
it does not send a Certificate or a CertificateVerify. PSK-based supplies a ClientKeyShare to the server as well, which allows the
resumption cannot be used to provide a new ServerConfiguration. server to decline resumption and fall back to a full handshake.
The contents and significance of each message will be presented in The contents and significance of each message will be presented in
detail in the following sections. detail in the following sections.
6.3. Handshake Protocol 6.3. Handshake Protocol
The TLS Handshake Protocol is one of the defined higher-level clients The TLS Handshake Protocol is one of the defined higher-level clients
of the TLS Record Protocol. This protocol is used to negotiate the of the TLS Record Protocol. This protocol is used to negotiate the
secure attributes of a session. Handshake messages are supplied to secure attributes of a session. Handshake messages are supplied to
the TLS record layer, where they are encapsulated within one or more the TLS record layer, where they are encapsulated within one or more
TLSPlaintext or TLSCiphertext structures, which are processed and TLSPlaintext or TLSCiphertext structures, which are processed and
transmitted as specified by the current active session state. transmitted as specified by the current active session state.
enum { enum {
reserved(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
session_ticket(4), hello_retry_request(6), session_ticket(4), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12), server_key_share(7), encrypted_extensions(8),
certificate_request(13), server_configuration(17), certificate(11), reserved(12), certificate_request(13),
certificate_verify(15), reserved(16), finished(20), (255) reserved(14), certificate_verify(15), reserved(16),
server_configuration(17), finished(20), (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case encrypted_extensions: EncryptedExtensions;
case server_configuration:ServerConfiguration; case server_configuration:ServerConfiguration;
case certificate: Certificate; case certificate: Certificate;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case session_ticket: NewSessionTicket; case session_ticket: NewSessionTicket;
} body; } body;
} Handshake; } Handshake;
The TLS Handshake Protocol messages are presented below in the order The TLS Handshake Protocol messages are presented below in the order
skipping to change at page 40, line 15 skipping to change at page 41, line 17
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 = { 3, 4 }; /* TLS v1.3 */ 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) { Extension extensions<0..2^16-1>;
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello; } ClientHello;
TLS allows extensions to follow the compression_methods field in an TLS allows extensions to follow the compression_methods field in an
extensions block. The presence of extensions can be detected by extensions block. The presence of extensions can be detected by
determining whether there are bytes following the compression_methods determining whether there are bytes following the compression_methods
at the end of the ClientHello. Note that this method of detecting at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS variable-length field, but it is used for compatibility with TLS
before extensions were defined. before extensions were defined.
skipping to change at page 46, line 30 skipping to change at page 47, line 30
Servers MUST NOT send this extension. TLS servers MUST support Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the respond with an "unsupported_extension" alert and close the
connection. connection.
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"supported_signature_algorithms" value: "supported_signature_algorithms" value:
enum { enum {
none(0), none(0),
md5_RESERVED(1), sha1,
sha1(2),
sha224_RESERVED(3),
sha256(4), sha384(5), sha512(6), sha256(4), sha384(5), sha512(6),
(255) (255)
} HashAlgorithm; } HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } enum {
SignatureAlgorithm; rsa(1),
dsa(2),
ecdsa(3),
rsapss(4),
(255)
} SignatureAlgorithm;
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>;
[[TODO: IANA considerations for new SignatureAlgorithm value]]
Each SignatureAndHashAlgorithm value lists a single hash/signature Each SignatureAndHashAlgorithm value lists a single hash/signature
pair that the client is willing to verify. The values are indicated pair that the client is willing to verify. The values are indicated
in descending order of preference. in descending order of preference.
Note: Because not all signature algorithms and hash algorithms may be Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not SHA- accepted by an implementation (e.g., ECDSA with SHA-256, but not SHA-
256), algorithms here are listed in pairs. 384), algorithms here are listed in pairs.
hash hash
This field indicates the hash algorithms which may be used. The This field indicates the hash algorithms which may be used. The
values indicate support for unhashed data, MD5 [RFC1321], SHA-1, values indicate support for unhashed data, SHA-1, SHA-256, SHA-
SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The 384, and SHA-512 [SHS], respectively. The "none" value is
"none" value is provided for future extensibility, in case of a provided for future extensibility, in case of a signature
signature algorithm which does not require hashing before signing. algorithm which does not require hashing before signing. Previous
The use of MD5 and SHA-224 are deprecated. The md5_RESERVED and versions of TLS supported MD5 and SHA-1. These algorithms are now
sha224_RESERVED values MUST NOT be offered or negotiated by any deprecated and MUST NOT be offered by TLS 1.3 implementations.
implementation. SHA-1 SHOULD NOT be offered, however clients willing to negotiate
use of TLS 1.2 MAY offer support for SHA-1 for backwards
compatibility with old servers.
signature signature
This field indicates the signature algorithm that may be used. This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 The values indicate RSASSA-PKCS1-v1_5 [RFC3447], DSA [DSS], ECDSA
[RFC3447], DSA [DSS], and ECDSA [ECDSA], respectively. The [ECDSA], and RSASSA-PSS [RFC3447] respectively. Because all RSA
"anonymous" value is meaningless in this context but used in signatures used in signed TLS handshake messages (see
Section 6.3.3. It MUST NOT appear in this extension. Section 4.9.1), as opposed to those in certificates, are RSASSA-
PSS, the "rsa" value refers solely to signatures which appear in
certificates. The use of DSA and anonymous is deprecated.
Previous versions of TLS supported DSA. DSA is deprecated as of
TLS 1.3 and SHOULD NOT be offered or negotiated by any
implementation.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite indicates permissible signature algorithms but not hash
algorithms. Section 6.3.5 and Section 6.3.3 describe the appropriate algorithms. Section 6.3.5 and Section 6.3.3 describe the appropriate
rules. rules.
Clients offering support for SHA-1 for TLS 1.2 servers MUST do so by
listing those hash/signature pairs as the lowest priority (listed
after all other pairs in the supported_signature_algorithms vector).
TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no
valid certificate chain can be produced without it (see
Section 6.3.5).
Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not
contain this extension. If those servers are willing to negotiate contain this extension. If those servers are willing to negotiate
TLS 1.2, they MUST behave in accordance with the requirements of TLS 1.2, they MUST behave in accordance with the requirements of
[RFC5246]. [RFC5246].
6.3.2.2. Negotiated Groups 6.3.2.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most the named groups which the client supports, ordered from most
preferred to least preferred. preferred to least preferred.
skipping to change at page 48, line 22 skipping to change at page 50, line 7
Servers MUST NOT send this extension. TLS servers MUST support Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the respond with an "unsupported_extension" alert and close the
connection. connection.
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"NamedGroupList" value: "NamedGroupList" value:
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
obsolete_RESERVED (1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25), secp256r1 (23), secp384r1 (24), secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe6144 (259), ffdhe8192 (260), ffdhe6144 (259), ffdhe8192 (260),
ffdhe_private_use (0x01FC..0x01FF), ffdhe_private_use (0x01FC..0x01FF),
// Reserved Code Points. // Reserved Code Points.
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
obsolete_RESERVED (0xFF01..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;
secp256r1, etc. secp256r1, etc.
Indicates support of the corresponding named curve. Note that Indicates support of the corresponding named curve. Note that
some curves are also recommended in ANSI X9.62 [X962] and FIPS some curves are also recommended in ANSI X9.62 [X962] and FIPS
186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for 186-4 [DSS]. Values 0xFE00 through 0xFEFF are reserved for
private use. private use.
ffdhe2048, etc. ffdhe2048, etc.
Indicates support of the corresponding finite field group, defined Indicates support of the corresponding finite field group, defined
in [I-D.ietf-tls-negotiated-ff-dhe]. Values 0x01FC through 0x01FF in [I-D.ietf-tls-negotiated-ff-dhe]. Values 0x01FC through 0x01FF
are reserved for private use. are reserved for private use.
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations. The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues. They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
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 (most preferred choice first). preferences (most preferred choice first).
As an example, a client that only supports secp256r1 (aka NIST P-256; As an example, a client that only supports secp256r1 (aka NIST P-256;
value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018)
and prefers to use secp256r1 would include a TLS extension consisting and prefers to use secp256r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type (Supported Group Extension): extension type (Supported Group Extension):
00 0A 00 06 00 04 00 17 00 18 00 0A 00 06 00 04 00 17 00 18
skipping to change at page 50, line 33 skipping to change at page 52, line 8
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
offers offers
A list of ClientKeyShareOffer values in descending order of client A list of ClientKeyShareOffer values in descending order of client
preference. preference.
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 exchange parameters; for
instance a client might offer shares for several elliptic curves or instance a client might offer shares for several elliptic curves or
multiple integer DH groups. The shares for each ClientKeyShareOffer multiple integer DH groups. The shares for each ClientKeyShareOffer
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 "client_key_share" extension as this is permitted to send an empty "client_key_share" extension as this is
used to elicit the server's parameters if the client has no useful used to elicit the server's parameters if the client has no useful
information. information.
[[TODO: Recommendation about what the client offers. Presumably [[TODO: Recommendation about what the client offers. Presumably
which integer DH groups and which curves.]] which integer DH groups and which curves.]]
skipping to change at page 57, line 28 skipping to change at page 58, line 42
extensions extensions
A list of extensions. A list of extensions.
6.3.5. Server Certificate 6.3.5. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a Certificate message whenever the agreed- The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document (this includes all key exchange methods defined in this document
except DH_anon and PSK). This message will always immediately except PSK). This message will always immediately follow the
follow the EncryptedExtensions message. EncryptedExtensions message.
Meaning of this message: Meaning of this message:
This message conveys the server's certificate chain to the client. This message conveys the server's certificate chain to the client.
The certificate MUST be appropriate for the negotiated cipher The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm and any negotiated extensions. suite's key exchange algorithm and any negotiated extensions.
Structure of this message: Structure of this message:
skipping to change at page 57, line 51 skipping to change at page 59, line 16
struct { struct {
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_list certificate_list
This is a sequence (chain) of certificates. The sender's This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate MUST come first in the list. Each following
certificate SHOULD directly certify one preceding it. Because certificate SHOULD directly certify one preceding it. Because
certificate validation requires that trust anchors be distributed certificate validation requires that trust anchors be distributed
independently, a self-signed certificate that specifies a trust independently, a certificate that specifies a trust anchor MAY be
anchor MAY be omitted from the chain, provided that supported omitted from the chain, provided that supported peers are known to
peers are known to possess any omitted certificates they may possess any omitted certificates.
require.
Note: Prior to TLS 1.3, "certificate_list" ordering was required to Note: Prior to TLS 1.3, "certificate_list" ordering required each
be strict, however some implementations already allowed for some certificate to certify the one immediately preceding it, however some
flexibility. For maximum compatibility, all implementations SHOULD implementations allowed some flexibility. Servers sometimes send
be prepared to handle potentially extraneous certificates and both a current and deprecated intermediate for transitional purposes,
arbitrary orderings from any TLS version (with the exception of the and others are simply configured incorrectly, but these cases can
sender's certificate). Some servers are configured to send both a nonetheless be validated properly. For maximum compatibility, all
current and deprecated intermediate for transitional purposes, and implementations SHOULD be prepared to handle potentially extraneous
others are simply configured incorrectly, but these cases can certificates and arbitrary orderings from any TLS version, with the
nonetheless be validated properly by clients capable of doing so. exception of the end-entity certificate which MUST be first.
Although the chain MAY be ordered in a variety of ways, the peer's
end-entity certificate MUST be the first element in the vector.
The same message type and structure will be used for the client's The same message type and structure will be used for the client's
response to a certificate request message. Note that a client MAY response to a certificate request message. Note that a client MAY
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.
skipping to change at page 59, line 15 skipping to change at page 60, line 15
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 (i.e., the ECDHE_RSA key to be used for signing (i.e., the
digitalSignature bit MUST be set if the key digitalSignature bit MUST be set if the key
usage extension is present) with the signature usage extension is present) with the signature
scheme and hash algorithm that will be employed scheme and hash algorithm that will be employed
in the ServerKeyShare message. in the ServerKeyShare message.
Note: ECDHE_RSA is defined in [RFC4492]. Note: ECDHE_RSA is defined in [RFC4492].
DHE_DSS DSA public key; the certificate MUST allow the
key to be used for signing with the hash
algorithm that will be employed in the server
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
ServerKeyShare message. The public key ServerKeyShare 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 [RFC6066] are - The "server_name" and "trusted_ca_keys" extensions [RFC6066] are
used to guide certificate selection. As servers MAY require the used to guide certificate selection. As servers MAY require the
presence of the server_name extension, clients SHOULD send this presence of the server_name extension, clients SHOULD send this
extension. extension.
All certificates provided by the server MUST be signed by a hash/ All certificates provided by the server MUST be signed by a hash/
signature algorithm pair that appears in the "signature_algorithms" signature algorithm pair that appears in the "signature_algorithms"
extension provided by the client (see Section 6.3.2.1). [[OPEN extension provided by the client, if they are able to provide such a
ISSUE: changing this is under consideration]] Note that this implies chain (see Section 6.3.2.1). If the server cannot produce a
that a certificate containing a key for one signature algorithm MAY certificate chain that is signed only via the indicated supported
be signed using a different signature algorithm (for instance, an RSA pairs, then it SHOULD continue the handshake by sending the client a
key signed with a ECDSA key). certificate chain of its choice that may include algorithms that are
not known to be supported by the client. This fallback chain MAY use
the deprecated SHA-1 hash algorithm. If the client cannot construct
an acceptable chain using the provided certificates and decides to
abort the handshake, then it MUST send an "unsupported_certificate"
alert message and close the connection.
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST send a "bad_certificate" alert
message and close the connection.
As SHA-1 and SHA-224 are deprecated, support for them is NOT
RECOMMENDED. Endpoints that reject chains due to use of a deprecated
hash MUST send a fatal "bad_certificate" alert message before closing
the connection. All servers are RECOMMENDED to transition to SHA-256
or better as soon as possible to maintain interoperability with
implementations currently in the process of phasing out SHA-1
support.
Note that a certificate containing a key for one signature algorithm
MAY be signed using a different signature algorithm (for instance, an
RSA key signed with a ECDSA key).
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
combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
SubjectPublicKeyInfo) cannot be used because TLS defines no
corresponding signature algorithm.
As cipher suites that specify new key exchange methods are specified As cipher suites that specify new key exchange methods are specified
for the TLS protocol, they will imply the certificate format and the for the TLS protocol, they will imply the certificate format and the
required encoded keying information. required encoded keying information.
6.3.6. Certificate Request 6.3.6. Certificate Request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the server's Certificate message, if sent, will immediately follow the server's Certificate
message. message.
Structure of this message: Structure of this message:
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), ecdsa_sign(64),
fortezza_dms_RESERVED(20), (255) (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_types certificate_types
A list of the types of certificate types that the client may A list of the types of certificate types that the client may
offer. offer.
rsa_sign a certificate containing an RSA key rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSA key
rsa_fixed_dh a certificate containing a static DH key. rsa_fixed_dh a certificate containing a static DH key.
dss_fixed_dh a certificate containing a static DH key
supported_signature_algorithms supported_signature_algorithms
A list of the hash/signature algorithm pairs that the server is A list of the hash/signature algorithm pairs that the server is
able to verify, listed in descending order of preference. able to verify, listed in descending order of preference.
certificate_authorities certificate_authorities
A list of the distinguished names [X501] of acceptable A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded 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
skipping to change at page 61, line 24 skipping to change at page 62, line 32
- 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
algorithm pair in supported_signature_algorithms. algorithm pair in supported_signature_algorithms.
- For historical reasons, the names of some client certificate types
include the algorithm used to sign the certificate. For example,
in earlier versions of TLS, rsa_fixed_dh meant a certificate
signed with RSA and containing a static DH key. In TLS 1.2, this
functionality has been obsoleted by the
supported_signature_algorithms, and the certificate type no longer
restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA-
SHA1.
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 11. Section 11.
Note: Values listed as RESERVED MUST NOT be used. They were used in
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.
6.3.7. Server Configuration 6.3.7. Server Configuration
When this message will be sent: When this message will be sent:
This message is used to provide a server configuration which the This message is used to provide a server configuration which the
client can use in future to skip handshake negotiation and client can use in future to skip handshake negotiation and
(optionally) to allow 0-RTT handshakes. The ServerConfiguration (optionally) to allow 0-RTT handshakes. The ServerConfiguration
skipping to change at page 63, line 20 skipping to change at page 64, line 14
The semantics of this message are to establish a shared state between The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration" the client and server for use with the "known_configuration"
extension with the key specified in key and with the handshake extension with the key specified in key and with the handshake
parameters negotiated by this handshake. parameters negotiated by this handshake.
When the ServerConfiguration message is sent, the server MUST also When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus the "known_configuration" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by requiring a signature over the configuration before it can be used by
the client. the client. Clients MUST not rely on the ServerConfiguration message
until successfully receiving and processing the server's Certificate,
CertificateVerify, and Finished. If there is a failure in processing
those messages, the client MUST discard the ServerConfiguration.
6.3.8. Server Certificate Verify 6.3.8. 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 and possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point. This also provides integrity for the handshake up to this point. This
message is sent when the server is authenticated via a message is sent when the server is authenticated via a
certificate. When sent, it MUST be the last server handshake certificate. When sent, it MUST be the last 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_hash[hash_length]; opaque handshake_hash[hash_length];
} };
} CertificateVerify; } CertificateVerify;
Where session_hash is as described in Section 7.2.1 and includes Where session_hash is as described in Section 7.2.1 and includes
the messages sent or received, starting at ClientHello and up to, the messages sent or received, starting at ClientHello and up to,
but not including, this message, including the type and length but not including, this message, including the type and length
fields of the handshake messages. This is a digest of the fields of the handshake messages. This is a digest of the
concatenation of all the Handshake structures (as defined in concatenation of all the Handshake structures (as defined in
Section 6.3) exchanged thus far. The digest MUST be the Hash used Section 6.3) exchanged thus far. The digest MUST be the Hash used
as the basis for HKDF. as the basis for HKDF.
The context string for the signature is "TLS 1.3, server The context string for the signature is "TLS 1.3, server
CertificateVerify". A hash of the handshake messages is signed CertificateVerify". A hash of the handshake messages is signed
rather than the messages themselves because the digitally-signed rather than the messages themselves because the digitally-signed
format requires padding and context bytes at the beginning of the format requires padding and context bytes at the beginning of the
input. Thus, by signing a digest of the messages, an input. Thus, by signing a digest of the messages, an
implementation need only maintain one running hash per hash type implementation need only maintain one running hash per hash type
for CertificateVerify, Finished and other messages. for CertificateVerify, Finished and other messages.
The signature algorithm and hash algorithm MUST be a pair offered The signature algorithm and hash algorithm MUST be a pair offered
in the "signature_algorithms" extension (see Section 6.3.2.1). in the client's "signature_algorithms" extension unless no valid
Note that there is a possibility for inconsistencies here. For certificate chain can be produced without unsupported algorithms
instance, the client might offer DHE_DSS key exchange but omit any (see Section 6.3.2.1). Note that there is a possibility for
DSA pairs from its "signature_algorithms" extension. In order to inconsistencies here. For instance, the client might offer
negotiate correctly, the server MUST check any candidate cipher ECDHE_ECDSA key exchange but omit any ECDSA pairs from its
suites against the "signature_algorithms" extension before "signature_algorithms" extension. In order to negotiate
selecting them. This is somewhat inelegant but is a compromise correctly, the server MUST check any candidate cipher suites
designed to minimize changes to the original cipher suite design. against the "signature_algorithms" extension before selecting
them. This is somewhat inelegant but is a compromise designed to
minimize changes to the original cipher suite design.
In addition, the hash and signature algorithms MUST be compatible In addition, the hash and signature algorithms MUST be compatible
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. RSA signatures MUST be based on
RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in
Because DSA signatures do not contain any secure indication of "signature_algorithms". SHA-1 MUST NOT be used in any signatures
hash algorithm, there is a risk of hash substitution if multiple in CertificateVerify, regardless of whether SHA-1 appears in
hashes may be used with any key. Currently, DSA [DSS] may only be "signature_algorithms".
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
guidance as to which digest algorithms should be used with each
key size. In addition, future revisions of [RFC5280] may specify
mechanisms for certificates to indicate which digest algorithms
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]]
6.3.9. Server Finished 6.3.9. 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 is essential for providing authentication of the server server and is essential for providing authentication of the server
side of the handshake and computed keys. side of the handshake and computed keys.
Meaning of this message: Meaning of this message:
skipping to change at page 65, line 30 skipping to change at page 66, line 20
finished". For Finished messages sent by the server, the string finished". For Finished messages sent by the server, the string
"server finished". "server finished".
In previous versions of TLS, the verify_data was always 12 octets In previous versions of TLS, the verify_data was always 12 octets
long. In the current version of TLS, it is the size of the HMAC long. In the current version of TLS, it is the size of the HMAC
output for the Hash used for the handshake. output for the Hash used for the handshake.
Note: Alerts and any other record types are not handshake messages Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations. Also, HelloRequest and are not included in the hash computations. Also, HelloRequest
messages and the Finished message are omitted from handshake hashes. messages and the Finished message are omitted from handshake hashes.
The input to the client and server Finished messages may not be the
same because the server's Finished does not include the client's
Certificate and CertificateVerify message.
6.3.10. Client Certificate 6.3.10. Client Certificate
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
skipping to change at page 66, line 32 skipping to change at page 67, line 19
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
employed in the CertificateVerify message. employed in the CertificateVerify message.
dss_sign DSA public key; the certificate MUST allow the
key to be used for signing with the hash
algorithm that will be employed in the
CertificateVerify message.
ecdsa_sign ECDSA-capable public key; the certificate MUST ecdsa_sign 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
CertificateVerify message; the public key CertificateVerify message; the public key
MUST use a curve and point format supported by MUST use a curve and point format supported by
the server. the server.
rsa_fixed_dh Diffie-Hellman public key; MUST use the same rsa_fixed_dh Diffie-Hellman public key; MUST use the same
dss_fixed_dh parameters as server's key. parameters as server's key.
rsa_fixed_ecdh ECDH-capable public key; MUST use the rsa_fixed_ecdh ECDH-capable public key; MUST use the
ecdsa_fixed_ecdh same curve as the server's key, and MUST use a ecdsa_fixed_ecdh same curve as the server's key, and MUST use a
point format supported by the server. point format supported by the server.
- If the certificate_authorities list in the certificate request - If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs. chain SHOULD be issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable hash/ - The certificates MUST be signed using an acceptable hash/
skipping to change at page 67, line 37 skipping to change at page 68, line 20
The contents of the message are computed as described in The contents of the message are computed as described in
Section 6.3.8, except that the context string is "TLS 1.3, client Section 6.3.8, except that the context string is "TLS 1.3, client
CertificateVerify". CertificateVerify".
The hash and signature algorithms used in the signature MUST be The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field one of those present in the supported_signature_algorithms field
of the CertificateRequest message. In addition, the hash and of the CertificateRequest message. In addition, the hash and
signature algorithms MUST be compatible with the key in the signature algorithms MUST be compatible with the key in the
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. RSA signatures MUST be based on RSASSA-PSS,
regardless of whether RSASSA-PKCS-v1_5 appears in
Because DSA signatures do not contain any secure indication of "signature_algorithms". SHA-1 MUST NOT be used in any signatures
hash algorithm, there is a risk of hash substitution if multiple in CertificateVerify, regardless of whether SHA-1 appears in
hashes may be used with any key. Currently, DSA [DSS] may only be "signature_algorithms".
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
guidance as to which digest algorithms should be used with each
key size. In addition, future revisions of [RFC5280] may specify
mechanisms for certificates to indicate which digest algorithms
are to be used with DSA.
6.3.12. New Session Ticket Message 6.3.12. New Session Ticket Message
After the server has received the client Finished message, it MAY After the server has received the client Finished message, it MAY
send a NewSessionTicket message. This message MUST be sent before send a NewSessionTicket message. This message MUST be sent before
the server sends any application data traffic, and is encrypted under the server sends any application data traffic, and is encrypted under
the application traffic key. This message creates a pre-shared key the application traffic key. This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket (PSK) binding between the resumption master secret and the ticket
label. The client MAY use this PSK for future handshakes by label. The client MAY use this PSK for future handshakes by
including it in the "pre_shared_key" extension in its ClientHello including it in the "pre_shared_key" extension in its ClientHello
(Section 6.3.2.4) and supplying a suitable PSK cipher suite. (Section 6.3.2.4) and supplying a suitable PSK cipher suite.
struct { struct {
uint32 ticket_lifetime_hint; uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} NewSessionTicket; } NewSessionTicket;
ticket_lifetime_hint ticket_lifetime_hint
Indicates the lifetime in seconds as a 32-bit unsigned integer in Indicates the lifetime in seconds as a 32-bit unsigned integer in
network byte order. A value of zero is reserved to indicate that network byte order from the time of ticket issuance. A value of
the lifetime of the ticket is unspecified. zero is reserved to indicate that the lifetime of the ticket is
unspecified.
ticket ticket
The value of the ticket to be used as the PSK identifier. The value of the ticket to be used as the PSK identifier.
The ticket lifetime hint is informative only. A client SHOULD delete The ticket lifetime hint is informative only. A client SHOULD delete
the ticket and associated state when the time expires. It MAY delete the ticket and associated state when the time expires. It MAY delete
the ticket earlier based on local policy. A server MAY treat a the ticket earlier based on local policy. A server MAY treat a
ticket as valid for a shorter or longer period of time than what is ticket as valid for a shorter or longer period of time than what is
stated in the ticket_lifetime_hint. stated in the ticket_lifetime_hint.
skipping to change at page 68, line 49 skipping to change at page 69, line 22
[[TODO: Should we require that tickets be bound to the existing [[TODO: Should we require that tickets be bound to the existing
symmetric cipher suite. See the TODO above about early_data and symmetric cipher suite. See the TODO above about early_data and
PSK.??] PSK.??]
7. Cryptographic Computations 7. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, key the client and server random values. The authentication, key
agreement, and record protection algorithms are determined by the exchange, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello cipher_suite selected by the server and revealed in the ServerHello
message. The random values are exchanged in the hello messages. All message. The random values are exchanged in the hello messages. All
that remains is to calculate the key schedule. that remains is to calculate the key schedule.
7.1. Key Schedule 7.1. Key Schedule
The TLS handshake establishes secret keying material which is then The TLS handshake establishes secret keying material which is then
used to protect traffic. This keying material is derived from the used to protect traffic. This keying material is derived from the
two input secret values: Static Secret (SS) and Ephemeral Secret two input secret values: Static Secret (SS) and Ephemeral Secret
(ES). (ES).
skipping to change at page 70, line 6 skipping to change at page 70, line 11
These shared secret values are used to generate cryptographic keys as These shared secret values are used to generate cryptographic keys as
shown below. shown below.
The derivation process is as follows, where L denotes the length of The derivation process is as follows, where L denotes the length of
the underlying hash function for HKDF [RFC5869]. SS and ES denote the underlying hash function for HKDF [RFC5869]. SS and ES denote
the sources from the table above. Whilst SS and ES may be the same the sources from the table above. Whilst SS and ES may be the same
in some cases, the extracted xSS and xES will not. in some cases, the extracted xSS and xES will not.
HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand-Label(Secret, Label, HashValue, Length) =
HKDF-Expand(Secret, Label + '\0' + HashValue, Length) HKDF-Expand(Secret, HkdfLabel, Length)
1. xSS = HKDF(0, SS, "extractedSS", L) Where HkdfLabel is specified as:
2. xES = HKDF(0, ES, "extractedES", L) struct HkdfLabel {
uint16 length;
opaque hash_value<0..255>;
opaque label<9..255>;
};
3. master_secret = HKDF(xSS, xES, "master secret", L) Where:
- HkdfLabel.length is Length
- HkdfLabel.hash_value is HashValue.
- HkdfLabel.label is "TLS 1.3, " + Label
4. finished_secret = HKDF-Expand-Label(xSS, 1. xSS = HKDF-Extract(0, SS). Note that HKDF-Extract always
produces a value the same length as the underlying hash
function.
2. xES = HKDF-Extract(0, ES)
3. mSS = HKDF-Expand-Label(xSS, "expanded static secret",
handshake_hash, L)
4. mES = HKDF-Expand-Label(xES, "expanded ephemeral secret",
handshake_hash, L)
5. master_secret = HKDF-Extract(mSS, mES)
6. finished_secret = HKDF-Expand-Label(xSS,
"finished secret", "finished secret",
handshake_hash, L) handshake_hash, L)
Where handshake_hash includes all the messages in the Where handshake_hash includes all the messages in the
client's first flight and the server's flight, excluding client's first flight and the server's flight, excluding
the Finished messages (which are never included in the the Finished messages (which are never included in the
hashes). hashes).
5. resumption_secret = HKDF-Expand-Label(master_secret, 5. resumption_secret = HKDF-Expand-Label(master_secret,
"resumption master secret" "resumption master secret"
skipping to change at page 70, line 40 skipping to change at page 71, line 18
"exporter master secret", "exporter master secret",
session_hash, L) session_hash, L)
Where session_hash is the session hash as defined in Where session_hash is the session hash as defined in
{{the-handshake-hash}} (i.e., the entire handshake except {{the-handshake-hash}} (i.e., the entire handshake except
for Finished). for Finished).
The traffic keys are computed from xSS, xES, and the master_secret as The traffic keys are computed from xSS, xES, and the master_secret as
described in Section 7.2 below. described in Section 7.2 below.
Note: although the steps above are phrased as individual HKDF-Extract
and HKDF-Expand operations, because each HKDF-Expand operation is
paired with an HKDF-Extract, it is possible to implement this key
schedule with a black-box HKDF API, albeit at some loss of efficiency
as some HKDF-Extract operations will be repeated.
7.2. Traffic Key Calculation 7.2. Traffic Key Calculation
[[OPEN ISSUE: This needs to be revised. Most likely we'll extract [[OPEN ISSUE: This needs to be revised. Most likely we'll extract
each key component separately. See https://github.com/tlswg/tls13- each key component separately. See https://github.com/tlswg/tls13-
spec/issues/5]] spec/issues/5]]
The Record Protocol requires an algorithm to generate keys required The Record Protocol requires an algorithm to generate keys required
by the current connection state (see Appendix A.5) from the security by the current connection state (see Appendix A.5) from the security
parameters provided by the handshake protocol. parameters provided by the handshake protocol.
skipping to change at page 73, line 4 skipping to change at page 73, line 32
output by FE2OSP, the Field Element to Octet String Conversion output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated. found in this octet string MUST NOT be truncated.
(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 this secret for anything other than because TLS does not directly use this secret for anything other than
for computing other secrets.) for computing other secrets.)
8. Mandatory Algorithms 8. Mandatory Algorithms
8.1. MTI Cipher Suites 8.1. MTI Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher otherwise, a TLS-compliant application MUST implement the following
suite TODO:Needs to be selected [1]. (See Appendix A.4 for the cipher suites:
definition.)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key exchange
with X25519 [I-D.irtf-cfrg-curves].
A TLS-compliant application SHOULD implement the following cipher
suites:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
8.2. MTI Extensions 8.2. MTI Extensions
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
- Signature Algorithms ("signature_algorithms"; Section 6.3.2.1) - Signature Algorithms ("signature_algorithms"; Section 6.3.2.1)
- Negotiated Groups ("supported_groups"; Section 6.3.2.2) - Negotiated Groups ("supported_groups"; Section 6.3.2.2)
skipping to change at page 74, line 19 skipping to change at page 75, line 19
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices B, C, and D. Appendices B, C, and D.
11. IANA Considerations 11. IANA Considerations
[[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]] [[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]]
[[TODO: Rename "RSA" in TLS SignatureAlgorithm Registry to RSASSA-
PKCS1-v1_5 ]]
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA has updated these to reference this document. The [RFC4346]. IANA has updated these to reference this document. The
registries and their allocation policies (unchanged from [RFC4346]) registries and their allocation policies (unchanged from [RFC4346])
are listed below. are listed below.
- TLS ClientCertificateType Identifiers Registry: Future values in - TLS ClientCertificateType Identifiers Registry: Future values in
the range 0-63 (decimal) inclusive are assigned via Standards the range 0-63 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values in the range 64-223 (decimal) inclusive Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
are assigned via Specification Required [RFC2434]. Values from are assigned via Specification Required [RFC2434]. Values from
skipping to change at page 76, line 5 skipping to change at page 77, line 5
12.1. Normative References 12.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 [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977. V.IT-22 n.6 , June 1977.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", NIST
FIPS PUB 186-2, 2000.
[I-D.ietf-tls-chacha20-poly1305] [I-D.ietf-tls-chacha20-poly1305]
Langley, A., Chang, W., Mavrogiannopoulos, N., Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "The ChaCha20-Poly1305 Strombergson, J., and S. Josefsson, "The ChaCha20-Poly1305
AEAD Cipher for Transport Layer Security", draft-ietf-tls- AEAD Cipher for Transport Layer Security", draft-ietf-tls-
chacha20-poly1305-00 (work in progress), June 2015. chacha20-poly1305-00 (work in progress), June 2015.
[I-D.irtf-cfrg-curves]
Langley, A. and M. Hamburg, "Elliptic Curves for
Security", draft-irtf-cfrg-curves-08 (work in progress),
September 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, DOI
1997. 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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", RFC 2434, DOI
October 1998. 10.17487/RFC2434, October 1998,
<http://www.rfc-editor.org/info/rfc2434>.
[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, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI
August 2008. 10.17487/RFC5288, August 2008,
<http://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI
August 2008. 10.17487/RFC5289, August 2008,
<http://www.rfc-editor.org/info/rfc5289>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010. Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/
RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, DOI
10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6209] Kim, W., Lee, J., Park, J., and D. Kwon, "Addition of the [RFC6209] Kim, W., Lee, J., Park, J., and D. Kwon, "Addition of the
ARIA Cipher Suites to Transport Layer Security (TLS)", RFC ARIA Cipher Suites to Transport Layer Security (TLS)", RFC
6209, April 2011. 6209, DOI 10.17487/RFC6209, April 2011,
<http://www.rfc-editor.org/info/rfc6209>.
[RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher
Suites to Transport Layer Security (TLS)", RFC 6367, Suites to Transport Layer Security (TLS)", RFC 6367, DOI
September 2011. 10.17487/RFC6367, September 2011,
<http://www.rfc-editor.org/info/rfc6367>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012. Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/
RFC6655, July 2012,
<http://www.rfc-editor.org/info/rfc6655>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, June 2014. TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<http://www.rfc-editor.org/info/rfc7251>.
[SHS] National Institute of Standards and Technology, U.S. [SHS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", NIST FIPS Department of Commerce, "Secure Hash Standard", NIST FIPS
PUB 180-4, March 2012. PUB 180-4, March 2012.
[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:
skipping to change at page 77, line 35 skipping to change at page 79, line 11
[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.
12.2. Informative References 12.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,
<https://www.openssl.org/~bodo/tls-cbc.txt>. <https://www.openssl.org/~bodo/tls-cbc.txt>.
[DSS-3] National Institute of Standards and Technology, U.S., [DSS] National Institute of Standards and Technology, U.S.
"Digital Signature Standard", NIST FIPS PUB 186-3 Draft, Department of Commerce, "Digital Signature Standard,
2006. version 4", NIST FIPS PUB 186-4, 2013.
[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.
[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-10 (work in progress), June 2015. ff-dhe-10 (work in progress), June 2015.
[I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-05 (work in progress), April 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, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, DOI 10.17487/RFC1948, May 1996,
<http://www.rfc-editor.org/info/rfc1948>.
[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, DOI 10.17487/RFC2246, January 1999,
<http://www.rfc-editor.org/info/rfc2246>.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
for Transport Layer Security (TLS)", RFC 4279, December Ciphersuites for Transport Layer Security (TLS)", RFC
2005. 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
2005. 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[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, DOI 10.17487/
RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>.
[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, DOI 10.17487/RFC4366, April 2006,
<http://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, DOI
10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
STD 67, RFC 4506, May 2006. Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[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, DOI
2007. 10.17487/RFC5081, November 2007,
<http://www.rfc-editor.org/info/rfc5081>.
[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, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
Extension Definitions", RFC 6066, January 2011. for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>.
[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, DOI 10.17487/RFC6176, March
2011, <http://www.rfc-editor.org/info/rfc6176>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
February 2015. Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI
10.17487/RFC7465, February 2015,
<http://www.rfc-editor.org/info/rfc7465>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, April 2015. Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<http://www.rfc-editor.org/info/rfc7507>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
June 2015. DOI 10.17487/RFC7568, June 2015,
<http://www.rfc-editor.org/info/rfc7568>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", RFC
7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>.
[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.
[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.
12.3. URIs 12.3. URIs
[1] https://github.com/tlswg/tls13-spec/issues/32 [1] 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. Values listed
as _RESERVED were used in previous versions of TLS and are listed
here for completeness. TLS 1.3 implementations MUST NOT send them
but may receive them from older TLS implementations.
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(20), alert(21), handshake(22), reserved(0),
application_data(23), early_handshake(25), reserved(20), alert(21), handshake(22),
(255) application_data(23), early_handshake(25),
} ContentType; (255)
} ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ 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 opaque_type = application_data(23); /* see fragment.type */
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length;
aead-ciphered struct {
opaque content[TLSPlaintext.length];
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint8 zeros[length_of_padding];
uint16 length; } fragment;
aead-ciphered struct { } TLSCiphertext;
opaque content[TLSPlaintext.length];
} fragment;
} 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), /* fatal */ unexpected_message(10), /* fatal */
bad_record_mac(20), /* fatal */ bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), /* fatal */ decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), /* fatal */ record_overflow(22), /* fatal */
skipping to change at page 83, line 7 skipping to change at page 85, line 7
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.3. Handshake Protocol A.3. Handshake Protocol
enum { enum {
reserved(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
session_ticket(4), hello_retry_request(6), session_ticket(4), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12), server_key_share(7), encrypted_extensions(8),
certificate_request(13), server_configuration(17), certificate(11), reserved(12), certificate_request(13),
certificate_verify(15), reserved(16), finished(20), (255) reserved(14), certificate_verify(15), reserved(16),
server_configuration(17), finished(20), (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case encrypted_extensions: EncryptedExtensions;
case server_configuration:ServerConfiguration; case server_configuration:ServerConfiguration;
case certificate: Certificate; case certificate: Certificate;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case session_ticket: NewSessionTicket; case session_ticket: NewSessionTicket;
} body; } body;
} Handshake; } Handshake;
A.3.1. Hello Messages A.3.1. Hello Messages
skipping to change at page 83, line 41 skipping to change at page 85, line 43
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 = { 3, 4 }; /* TLS v1.3 */ 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) { Extension extensions<0..2^16-1>;
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { 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>;
}; };
} ServerHello; } ServerHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
skipping to change at page 86, line 7 skipping to change at page 88, line 7
NamedGroup group; NamedGroup group;
opaque server_key<1..2^16-1>; opaque server_key<1..2^16-1>;
EarlyDataType early_data_type; EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>; ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration; } ServerConfiguration;
A.3.1.1. Signature Algorithm Extension A.3.1.1. Signature Algorithm Extension
enum { enum {
none(0), none(0),
md5_RESERVED(1), md5_RESERVED(1),
sha1(2), sha1,
sha224_RESERVED(3), sha224_RESERVED(3),
sha256(4), sha384(5), sha512(6), sha256(4), sha384(5), sha512(6),
(255) (255)
} HashAlgorithm; } HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } enum {
SignatureAlgorithm; anonymous_RESERVED(0),
rsa(1),
dsa(2),
ecdsa(3),
rsapss(4),
(255)
} SignatureAlgorithm;
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
skipping to change at page 86, line 46 skipping to change at page 89, line 5
// Reserved Code Points. // Reserved Code Points.
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
obsolete_RESERVED (0xFF01..0xFF02), obsolete_RESERVED (0xFF01..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;
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations. The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues. They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
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>;
skipping to change at page 87, line 23 skipping to change at page 90, line 4
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;
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), dss_sign_RESERVED(2),
fortezza_dms_RESERVED(20), (255) rsa_fixed_dh_RESERVED(3),
dss_fixed_dh_RESERVED(4),
rsa_ephemeral_dh_RESERVED(5),
dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
ecdsa_sign(64),
(255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_hash[hash_length]; opaque handshake_hash[hash_length];
} };
} CertificateVerify; } CertificateVerify;
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.3.5. Ticket Establishment A.3.5. Ticket Establishment
skipping to change at page 89, line 5 skipping to change at page 91, line 39
The primary key exchange algorithm used in TLS is Ephemeral Diffie- The primary key exchange algorithm used in TLS is Ephemeral Diffie-
Hellman [DH]. The finite field based version is denoted "DHE" and Hellman [DH]. The finite field based version is denoted "DHE" and
the elliptic curve based version is denoted "ECDHE". Prior versions the elliptic curve based version is denoted "ECDHE". Prior versions
of TLS supported non-ephemeral key exchanges, however these are not of TLS supported non-ephemeral key exchanges, however these are not
supported by TLS 1.3. supported by TLS 1.3.
See the definitions of each cipher suite in its specification See the definitions of each cipher suite in its specification
document for the full details of each combination of algorithms that document for the full details of each combination of algorithms that
is specified. is specified.
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
NOT be negotiated, as it provides no more protection than an
unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = {0x00,0x00};
The following is a list of standards track server-authenticated (and The following is a list of standards track server-authenticated (and
optionally client-authenticated) cipher suites which are currently optionally client-authenticated) cipher suites which are currently
available in TLS 1.3: available in TLS 1.3:
Cipher Suite Name Value Specification Cipher Suite Name Value Specification
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 {0x00,0x9E} [RFC5288] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 {0x00,0x9E} [RFC5288]
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 {0x00,0x9F} [RFC5288] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 {0x00,0x9F} [RFC5288]
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 {0x00,0xA2} [RFC5288]
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 {0x00,0xA3} [RFC5288]
TLS_DHE_RSA_WITH_AES_128_CCM {0xC0,0x9E} [RFC6655] TLS_DHE_RSA_WITH_AES_128_CCM {0xC0,0x9E} [RFC6655]
TLS_DHE_RSA_WITH_AES_256_CCM {0xC0,0x9F} [RFC6655] TLS_DHE_RSA_WITH_AES_256_CCM {0xC0,0x9F} [RFC6655]
TLS_DHE_RSA_WITH_AES_128_CCM_8 {0xC0,0xA2} [RFC6655] TLS_DHE_RSA_WITH_AES_128_CCM_8 {0xC0,0xA2} [RFC6655]
TLS_DHE_RSA_WITH_AES_256_CCM_8 {0xC0,0xA3} [RFC6655] TLS_DHE_RSA_WITH_AES_256_CCM_8 {0xC0,0xA3} [RFC6655]
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305] TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305] TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
TLS_DHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305] TLS_DHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
[[TODO: CHACHA20_POLY1305 cipher suite IDs are TBD.]] [[TODO: CHACHA20_POLY1305 cipher suite IDs are TBD.]]
skipping to change at page 90, line 16 skipping to change at page 92, line 22
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2B} [RFC5289] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2B} [RFC5289]
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {0xC0,0x2C} [RFC5289] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {0xC0,0x2C} [RFC5289]
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2F} [RFC5289] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2F} [RFC5289]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 {0xC0,0x30} [RFC5289] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 {0xC0,0x30} [RFC5289]
TLS_ECDHE_ECDSA_WITH_AES_128_CCM {0xC0,0xAC} [RFC7251] TLS_ECDHE_ECDSA_WITH_AES_128_CCM {0xC0,0xAC} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_256_CCM {0xC0,0xAD} [RFC7251] TLS_ECDHE_ECDSA_WITH_AES_256_CCM {0xC0,0xAD} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 {0xC0,0xAE} [RFC7251] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 {0xC0,0xAE} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 {0xC0,0xAF} [RFC7251] TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 {0xC0,0xAF} [RFC7251]
TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x52} [RFC6209] TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x52} [RFC6209]
TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x53} [RFC6209] TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x53} [RFC6209]
TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256 {0xC0,0x56} [RFC6209]
TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384 {0xC0,0x57} [RFC6209]
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x5C} [RFC6209] TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x5C} [RFC6209]
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x5D} [RFC6209] TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x5D} [RFC6209]
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x60} [RFC6209] TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x60} [RFC6209]
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x61} [RFC6209] TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x61} [RFC6209]
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x7C} [RFC6367] TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x7C} [RFC6367]
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x7D} [RFC6367] TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x7D} [RFC6367]
TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x80} [RFC6367]
TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x81} [RFC6367]
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x86} [RFC6367] TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x86} [RFC6367]
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x87} [RFC6367] TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x87} [RFC6367]
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x8A} [RFC6367] TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x8A} [RFC6367]
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x8B} [RFC6367] TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x8B} [RFC6367]
ECDHE AES GCM is not yet standards track, however it is already ECDHE AES GCM is not yet standards track, however it is already
widely deployed. widely deployed.
Note: In the case of the CCM mode of AES, two variations exist: Note: In the case of the CCM mode of AES, two variations exist:
"CCM_8" which uses an 8-bit authentication tag and "CCM" which uses a "CCM_8" which uses an 8-bit authentication tag and "CCM" which uses a
16-bit authentication tag. Both use the default hash, SHA-256. 16-bit authentication tag. Both use the default hash, SHA-256.
In addition to authenticated cipher suites, completely anonymous
Diffie-Hellman cipher suites exist to provide communications in which
neither party is authenticated. This mode is vulnerable to man-in-
the-middle attacks and is therefore unsafe for general use. These
cipher suites MUST NOT be used by TLS implementations unless the
application layer has specifically requested to allow anonymous key
exchange. Anonymous key exchange may sometimes be acceptable, for
example, to support opportunistic encryption when no set-up for
authentication is in place, or when TLS is used as part of more
complex security protocols that have other means to ensure
authentication. The following specifications provide "DH_anon" key
exchange cipher suites: AES-GCM [RFC5288], ARIA-GCM [RFC6209], and
CAMELLIA-GCM [RFC6367].
All cipher suites in this section are specified for use with both TLS All cipher suites in this section are specified for use with both TLS
1.2 and TLS 1.3, as well as the corresponding versions of DTLS. (see 1.2 and TLS 1.3, as well as the corresponding versions of DTLS. (see
Appendix C) Appendix C)
Note that using non-anonymous key exchange without actually verifying
the key exchange is essentially equivalent to anonymous key exchange,
and the same precautions apply. While non-anonymous key exchange
will generally involve a higher computational and communicational
cost than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange.
New cipher suite values are assigned by IANA as described in New cipher suite values are assigned by IANA as described in
Section 11. Section 11.
A.4.1. Unauthenticated Operation
Previous versions of TLS offered explicitly unauthenticated cipher
suites base on anonymous Diffie-Hellman. These cipher suites have
been deprecated in TLS 1.3. However, it is still possible to
negotiate cipher suites that do not provide verifiable server
authentication by serveral methods, including:
- Raw public keys [RFC7250].
- Using a public key contained in a certificate but without
validation of the certificate chain or any of its contents.
Either technique used alone is are vulnerable to man-in-the-middle
attacks and therefore unsafe for general use. However, it is also
possible to bind such connections to an external authentication
mechanism via out-of-band validation of the server's public key,
trust on first use, or channel bindings [RFC5929]. [[NOTE: TLS 1.3
needs a new channel binding definition that has not yet been
defined.]] If no such mechanism is used, then the connection has no
protection against active man-in-the-middle attack; applications MUST
NOT use TLS in such a way absent explicit configuration or a specific
application profile.
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_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm; enum { tls_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm;
skipping to change at page 92, line 32 skipping to change at page 94, line 38
Appendix B. Implementation Notes Appendix B. 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.
B.1. Random Number Generation and Seeding B.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-256, are
but cannot provide more security than the size of the random number acceptable, but cannot provide more security than the size of the
generator state. random number 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 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.
skipping to change at page 93, line 11 skipping to change at page 95, line 18
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.
B.3. Cipher Suite Support B.3. Cipher Suite Support
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. Applications SHOULD also
Diffie-Hellman is strongly discouraged because it cannot prevent man- enforce minimum and maximum key sizes. For example, certificate
in-the-middle attacks. Applications should also enforce minimum and chains containing keys or signatures weaker than 2048-bit RSA or
maximum key sizes. For example, certificate chains containing keys 224-bit ECDSA are not appropriate for secure applications. See also
or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not Appendix C.3.
appropriate for secure applications. See also Appendix C.3.
B.4. Implementation Pitfalls B.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.
skipping to change at page 93, line 39 skipping to change at page 95, line 45
- 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 5.2.1)? Including corner cases multiple TLS records (see Section 5.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? (see Appendix C) records? (see Appendix C)
- Have you ensured that all support for SSL, RC4, and EXPORT ciphers - Have you ensured that all support for SSL, RC4, EXPORT ciphers,
is completely removed from all possible configurations that and MD5 (via the Signature Algorithms extension) is completely
support TLS 1.3 or later, and that attempts to use these obsolete removed from all possible configurations that support TLS 1.3 or
capabilities fail correctly? (see Appendix C) later, and that attempts to use these obsolete capabilities fail
correctly? (see Appendix C)
- 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 6.3.10)? Section 6.3.10)?
- When processing the plaintext fragment produced by AEAD-Decrypt
and scanning from the end for the ContentType, do you avoid
scanning past the start of the cleartext in the event that the
peer has sent a malformed plaintext of all-zeros?
Cryptographic details: Cryptographic details:
- What countermeasures do you use to prevent timing attacks against - What countermeasures do you use to prevent timing attacks against
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.9)? Do you verify that the RSA padding parameters (see Section 4.9)? 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 7.2.2)? leading zero bytes from the negotiated key (see Section 7.2.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 D.1.1.2)? by the server are acceptable (see Appendix D.1.1.1)?
- 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 B.1) Diffie-Hellman private values, number generator (see Appendix B.1) Diffie-Hellman private values,
the DSA "k" parameter, and other security-critical values? the ECDSA "k" parameter, and other security-critical values?
Appendix C. Backward Compatibility Appendix C. Backward Compatibility
The TLS protocol provides a built-in mechanism for version The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different negotiation between endpoints potentially supporting different
versions of TLS. versions of TLS.
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and the client supports the the ClientHello format remains compatible and the client supports the
skipping to change at page 97, line 41 skipping to change at page 100, line 5
certificate is valid and has not expired or been revoked. certificate is valid and has not expired or been revoked.
[[TODO: Rewrite this because the master_secret is not used this way [[TODO: Rewrite this because the master_secret is not used this way
any more after Hugo's changes.]] The general goal of the key exchange any more after Hugo's changes.]] The general goal of the key exchange
process is to create a master_secret known to the communicating process is to create a master_secret known to the communicating
parties and not to attackers (see Section 7.1). The master_secret is parties and not to attackers (see Section 7.1). The master_secret is
required to generate the Finished messages and record protection keys required to generate the Finished messages and record protection keys
(see Section 6.3.9 and Section 7.2). By sending a correct Finished (see Section 6.3.9 and Section 7.2). By sending a correct Finished
message, parties thus prove that they know the correct master_secret. message, parties thus prove that they know the correct master_secret.
D.1.1.1. Anonymous Key Exchange D.1.1.1. Diffie-Hellman Key Exchange with Authentication
Completely anonymous sessions can be established using Diffie-Hellman
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
key share message. Eavesdroppers who do not know the private values
should not be able to find the Diffie-Hellman result.
Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-proof
channel is used to verify that the Finished messages were not
replaced by an attacker, server authentication is required in
environments where active man-in-the-middle attacks are a concern.
D.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.
skipping to change at page 100, line 10 skipping to change at page 102, line 8
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 E. Working Group Information Appendix E. 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 [1]. 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: https://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 F. Contributors Appendix F. Contributors
Martin Abadi Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
skipping to change at page 100, line 33 skipping to change at page 102, line 31
Christopher Allen (co-editor of TLS 1.0) Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
Steven M. Bellovin Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Benjamin Beurdouche Benjamin Beurdouche
Karthikeyan Bhargavan (co-author of [I-D.ietf-tls-session-hash]) Karthikeyan Bhargavan (co-author of [RFC7627])
INRIA INRIA
karthikeyan.bhargavan@inria.fr karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson (co-author of RFC4492) Simon Blake-Wilson (co-author of [RFC4492])
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
Nelson Bolyard 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
Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash])
Antoine Delignat-Lavaud (co-author of [RFC7627])
INRIA INRIA
antoine.delignat-lavaud@inria.fr antoine.delignat-lavaud@inria.fr
Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
Independent Independent
tim@dierks.org tim@dierks.org
Taher Elgamal Taher Elgamal
Securify Securify
taher@securify.com taher@securify.com
Pasi Eronen Pasi Eronen
Nokia Nokia
pasi.eronen@nokia.com pasi.eronen@nokia.com
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
David M. Garrett 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
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 Kipp Hickman
Alfred Hoenes Alfred Hoenes
David Hopwood David Hopwood
Independent Consultant Independent Consultant
david.hopwood@blueyonder.co.uk david.hopwood@blueyonder.co.uk
skipping to change at page 102, line 6 skipping to change at page 104, line 4
Phil Karlton (co-author of SSL 3.0) Phil Karlton (co-author of SSL 3.0)
Paul Kocher (co-author of SSL 3.0) Paul Kocher (co-author of SSL 3.0)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
Hugo Krawczyk Hugo Krawczyk
IBM IBM
hugo@ee.technion.ac.il hugo@ee.technion.ac.il
Adam Langley (co-author of [RFC7627])
Adam Langley (co-author of [I-D.ietf-tls-session-hash])
Google Google
agl@google.com agl@google.com
Ilari Liusvaara Ilari Liusvaara
ilari.liusvaara@elisanet.fi ilari.liusvaara@elisanet.fi
Jan Mikkelsen Jan Mikkelsen
Transactionware Transactionware
janm@transactionware.com janm@transactionware.com
Bodo Moeller (co-author of RFC4492) Bodo Moeller (co-author of [RFC4492])
Google Google
bodo@openssl.org bodo@openssl.org
Erik Nygren Erik Nygren
Akamai Technologies Akamai Technologies
erik+ietf@nygren.org erik+ietf@nygren.org
Magnus Nystrom Magnus Nystrom
RSA Security RSA Security
magnus@rsasecurity.com magnus@rsasecurity.com
Alfredo Pironti (co-author of [I-D.ietf-tls-session-hash]) Alfredo Pironti (co-author of [RFC7627])
INRIA INRIA
alfredo.pironti@inria.fr alfredo.pironti@inria.fr
Marsh Ray (co-author of [I-D.ietf-tls-session-hash]) Marsh Ray (co-author of [RFC7627])
Microsoft Microsoft
maray@microsoft.com maray@microsoft.com
Robert Relyea Robert Relyea
Netscape Communications Netscape Communications
relyea@netscape.com relyea@netscape.com
Jim Roskind Jim Roskind
Netscape Communications Netscape Communications
jar@netscape.com jar@netscape.com
Michael Sabin Michael Sabin
Dan Simon Dan Simon
Microsoft, Inc. Microsoft, Inc.
dansimon@microsoft.com dansimon@microsoft.com
Bjoern Tackmann
University of California, San Diego
btackmann@eng.ucsd.edu
Martin Thomson Martin Thomson
Mozilla Mozilla
mt@mozilla.com mt@mozilla.com
Tom Weinstein Tom Weinstein
Hoeteck Wee
Ecole Normale Superieure, Paris
hoeteck@alum.mit.edu
Tim Wright Tim Wright
Vodafone Vodafone
timothy.wright@vodafone.com timothy.wright@vodafone.com
Author's Address Author's Address
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
 End of changes. 174 change blocks. 
519 lines changed or deleted 652 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/