draft-ietf-tls-tls13-09.txt   draft-ietf-tls-tls13-10.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246, 5746 (if October 05, 2015 Obsoletes: 5077, 5246, 5746 (if October 19, 2015
approved) approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 7, 2016 Expires: April 21, 2016
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-09 draft-ietf-tls-tls13-10
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 April 7, 2016. This Internet-Draft will expire on April 21, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 10
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 14 4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 14
4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 15 4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 15
4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 15 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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21 5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21
5.2.3. Record Padding . . . . . . . . . . . . . . . . . . . 23 5.2.3. Record Padding . . . . . . . . . . . . . . . . . . . 23
6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 24 6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 24
6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 25 6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 26 6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 26
6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 27 6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 27
6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 31 6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 31
6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 34 6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 34
6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 35 6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 35
6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 37 6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 37
6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 39 6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 38
6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 40 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 39
6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 44 6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 44
6.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 57 6.3.3. Encrypted Extensions . . . . . . . . . . . . . . . . 57
6.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 58 6.3.4. Server Certificate . . . . . . . . . . . . . . . . . 57
6.3.5. Server Certificate . . . . . . . . . . . . . . . . . 58 6.3.5. Certificate Request . . . . . . . . . . . . . . . . . 60
6.3.6. Certificate Request . . . . . . . . . . . . . . . . . 61 6.3.6. Server Configuration . . . . . . . . . . . . . . . . 62
6.3.7. Server Configuration . . . . . . . . . . . . . . . . 62 6.3.7. Server Certificate Verify . . . . . . . . . . . . . . 63
6.3.8. Server Certificate Verify . . . . . . . . . . . . . . 64 6.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 64
6.3.9. Server Finished . . . . . . . . . . . . . . . . . . . 65 6.3.9. Client Certificate . . . . . . . . . . . . . . . . . 65
6.3.10. Client Certificate . . . . . . . . . . . . . . . . . 66 6.3.10. Client Certificate Verify . . . . . . . . . . . . . . 66
6.3.11. Client Certificate Verify . . . . . . . . . . . . . . 67 6.3.11. New Session Ticket Message . . . . . . . . . . . . . 67
6.3.12. New Session Ticket Message . . . . . . . . . . . . . 68 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 68
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 69 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 68
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 . . . . . . . . . . . . . . . . . . . 71
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 . . . . . . . . . . . . . . . . . . . . 72
8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 73 8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 72
8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 74 9. Application Data Protocol . . . . . . . . . . . . . . . . . . 73
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 Appendix A. Protocol Data Structures and Constant Values . . . . 81
Appendix A. Protocol Data Structures and Constant Values . . . . 83 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 81
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 83 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 81
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 83 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 82
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 84 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 83
A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 85 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 87
A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 89 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 87
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 89 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 88
A.3.4. Handshake Finalization Messages . . . . . . . . . . . 90 A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 88
A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 90 A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 88
A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 91 A.4.1. Unauthenticated Operation . . . . . . . . . . . . . . 90
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 . . . . . . . . . . . . . . . 98
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 . . . . . . . . . . . . . 99
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 4, line 39 skipping to change at page 4, line 38
The primary goal of the TLS protocol is to provide privacy and data The primary goal of the TLS protocol is to provide privacy and data
integrity between two communicating peers. The TLS protocol is integrity between two communicating peers. The TLS protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP [RFC0793]), is the TLS Record Protocol. transport protocol (e.g., TCP [RFC0793]), is the TLS Record Protocol.
The TLS Record Protocol provides connection security that has two The TLS Record Protocol provides connection security that has two
basic properties: basic properties:
- The connection is private. Symmetric cryptography is used for - The connection is private. Symmetric cryptography is used for
data encryption (e.g., AES [AES], etc.). The keys for this data encryption (e.g., AES [AES]). The keys for this symmetric
symmetric encryption are generated uniquely for each connection encryption are generated uniquely for each connection and are
and are based on a secret negotiated by another protocol (such as based on a secret negotiated by another protocol (such as the TLS
the TLS Handshake Protocol). Handshake Protocol).
- The connection is reliable. Messages include an authentication - The connection is reliable. Messages include an authentication
tag which protects them against modification. tag which protects them against modification.
Note: The TLS Record Protocol can operate in an insecure mode but is Note: The TLS Record Protocol can operate in an insecure mode but is
generally only used in this mode while another protocol is using the generally only used in this mode while another protocol is using the
TLS Record Protocol as a transport for negotiating security TLS Record Protocol as a transport for negotiating security
parameters. parameters.
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], ECDSA [ECDSA], etc.). public key, cryptography (e.g., RSA [RSA], ECDSA [ECDSA]). This
This authentication can be made optional, but is generally authentication can be made optional, but is generally required for
required for at least one of the peers. 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-10
- Remove ClientCertificateTypes field from CertificateRequest and
add extensions.
- Merge client and server key shares into a single extension.
draft-09 draft-09
- Change to RSA-PSS signatures for handshake messages. - Change to RSA-PSS signatures for handshake messages.
- Remove support for DSA. - Remove support for DSA.
- Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern - Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern
Tackmann. Tackmann.
- Add support for per-record padding. - Add support for per-record padding.
skipping to change at page 15, line 50 skipping to change at page 15, line 50
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-PSS signature scheme defined in [RFC3447] with MGF1. using the RSASSA-PSS signature scheme defined in [RFC3447] with MGF1.
The digest used in the mask generation function MUST be the same as The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in the digest which is being signed (i.e., what appears in
algorithm.signature). Note that previous versions of TLS used algorithm.signature). The length of the salt MUST be equal to the
RSASSA-PKCS1-v1_5, not RSASSA-PSS. octet length of the digest output. Note that previous versions of
TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS.
All ECDSA computations MUST be performed according to ANSI X9.62 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 SignatureAndHashAlgorithm parameter in the additional hashing. The SignatureAndHashAlgorithm parameter in the
DigitallySigned object indicates the digest algorithm which was used DigitallySigned object indicates the digest algorithm which was used
in the signature. in the signature.
In the following example In the following example
skipping to change at page 18, line 10 skipping to change at page 18, line 10
Whether this entity is considered the "client" or the "server" in Whether this entity is considered the "client" or the "server" in
this connection. this connection.
Hash algorithm Hash algorithm
An algorithm used to generate keys from the appropriate secret An algorithm used to generate keys from the appropriate secret
(see Section 7.1 and Section 7.2). (see Section 7.1 and Section 7.2).
record protection algorithm record protection algorithm
The algorithm to be used for record protection. This algorithm The algorithm to be used for record protection. This algorithm
must be of the AEAD type and thus provides integrity and must be of the AEAD type and thus provides integrity and
confidentiality as a single primitive. It is possible to have confidentiality as a single primitive. This specification
AEAD algorithms which do not provide any confidentiality and includes the key size of this algorithm and of the nonce for the
Section 5.2.2 defines a special NULL_NULL AEAD algorithm for use AEAD algorithm.
only in the initial handshake. This specification includes the
key size of this algorithm and of the nonce for the AEAD
algorithm.
master secret master secret
A 48-byte secret shared between the two peers in the connection A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting data. and used to generate keys for protecting data.
client random client random
A 32-byte value provided by the client. A 32-byte value provided by the client.
server random server random
A 32-byte value provided by the server. A 32-byte value provided by the server.
skipping to change at page 20, line 13 skipping to change at page 20, line 11
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). Alert messages Section 6.1 MUST fragmented across several records). Alert messages Section 6.1 MUST
NOT be fragmented across records. NOT be fragmented across records.
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(0), alert(21),
reserved(20), alert(21), handshake(22), 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];
} TLSPlaintext; } TLSPlaintext;
skipping to change at page 32, line 8 skipping to change at page 32, line 8
In some cases, as with the DH handshake shown in Figure 1, these In some cases, as with the DH handshake shown in Figure 1, these
secrets are the same, but having both allows for a uniform key secrets are the same, but having both allows for a uniform key
derivation scheme for all cipher modes. derivation scheme for all cipher modes.
The basic TLS Handshake for DH is shown in Figure 1: The basic TLS Handshake for DH is shown in Figure 1:
Client Server Client Server
ClientHello ClientHello
+ ClientKeyShare --------> + KeyShare -------->
ServerHello ServerHello
ServerKeyShare* + KeyShare
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
+ Indicates extensions sent in the
previously noted message.
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages that are not always sent. messages that are not always sent.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from the ephemeral secret. derived from the ephemeral secret.
[] Indicates messages protected using keys [] Indicates messages protected using keys
derived from the master secret. derived from the master secret.
Figure 1: Message flow for full TLS Handshake Figure 1: Message flow for full TLS Handshake
The first message sent by the client is the ClientHello The first message sent by the client is the ClientHello
Section 6.3.1.1 which contains a random nonce (ClientHello.random), Section 6.3.1.1 which contains a random nonce (ClientHello.random),
its offered protocol version, cipher suite, and extensions, and one its offered protocol version, cipher suite, and extensions, and one
or more Diffie-Hellman key shares in the ClientKeyShare extension or more Diffie-Hellman key shares in the KeyShare extension
Section 6.3.2.3. Section 6.3.2.3.
The server processes the ClientHello and determines the appropriate The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection. It then responds with cryptographic parameters for the connection. It then responds with
the following messages: the following messages:
ServerHello ServerHello
indicates the negotiated connection parameters. [Section 6.3.1.2] indicates the negotiated connection parameters. [Section 6.3.1.2]
If DH is in use, this will contain a KeyShare extension with the
ServerKeyShare server's ephemeral Diffie-Hellman share which MUST be in the same
the server's ephemeral Diffie-Hellman Share which must be in the group as one of the shares offered by the client. The server's
same group as one of the shares offered by the client. This KeyShare and the client's KeyShare corresponding to the negotiated
message will be omitted if DH is not in use (i.e., a pure PSK key exchange are used together to derive the Static Secret and
cipher suite is selected). The ClientKeyShare and ServerKeyShare Ephemeral Secret (in this mode they are the same).
are used together to derive the Static Secret and Ephemeral Secret [Section 6.3.2.3]
(in this mode they are the same). [Section 6.3.3]
ServerConfiguration ServerConfiguration
supplies a configuration for 0-RTT handshakes (see Section 6.2.2). supplies a configuration for 0-RTT handshakes (see Section 6.2.2).
[Section 6.3.7] [Section 6.3.6]
EncryptedExtensions EncryptedExtensions
responses to any extensions which are not required in order to responses to any extensions which are not required in order to
determine the cryptographic parameters. [Section 6.3.4] determine the cryptographic parameters. [Section 6.3.3]
Certificate Certificate
the server certificate. This message will be omitted if the the server certificate. This message will be omitted if the
server is not authenticating via a certificates. [Section 6.3.5] server is not authenticating via a certificates. [Section 6.3.4]
CertificateRequest CertificateRequest
if certificate-based client authentication is desired, the desired if certificate-based client authentication is desired, the desired
parameters for that certificate. This message will be omitted if parameters for that certificate. This message will be omitted if
client authentication is not desired. [[OPEN ISSUE: See client authentication is not desired. [[OPEN ISSUE: See
https://github.com/tlswg/tls13-spec/issues/184]]. [Section 6.3.6] https://github.com/tlswg/tls13-spec/issues/184]]. [Section 6.3.5]
CertificateVerify CertificateVerify
a signature over the entire handshake using the public key in the a signature over the entire handshake using the public key in the
Certificate message. This message will be omitted if the server Certificate message. This message will be omitted if the server
is not authenticating via a certificate. [Section 6.3.8] is not authenticating via a certificate. [Section 6.3.7]
Finished Finished
a MAC over the entire handshake computed using the Static Secret. a MAC over the entire handshake computed using the Static Secret.
This message provides key confirmation and In some modes (see This message provides key confirmation and In some modes (see
Section 6.2.2) it also authenticates the handshake using the the Section 6.2.2) it also authenticates the handshake using the the
Static Secret. [Section 6.3.9] Static Secret. [Section 6.3.8]
Upon receiving the server's messages, the client responds with his Upon receiving the server's messages, the client responds with his
final flight of messages: final flight of messages:
Certificate Certificate
the client's certificate. This message will be omitted if the the client's certificate. This message will be omitted if the
client is not authenticating via a certificates. [Section 6.3.10] client is not authenticating via a certificates. [Section 6.3.9]
CertificateVerify CertificateVerify
a signature over the entire handshake using the private key a signature over the entire handshake using the private key
corresponding to the public key in the Certificate message. This corresponding to the public key in the Certificate message. This
message will be omitted if the client is not authenticating via a message will be omitted if the client is not authenticating via a
certificate. [Section 6.3.11] certificate. [Section 6.3.10]
Finished Finished
a MAC over the entire handshake computed using the Static Secret a MAC over the entire handshake computed using the Static Secret
and providing key confirmation. [Section 6.3.9] and providing key confirmation. [Section 6.3.8]
At this point, the handshake is complete, and the client and server At this point, the handshake is complete, and the client and server
may exchange application layer data. Application data MUST NOT be may exchange application layer data. Application data MUST NOT be
sent prior to sending the Finished message. If client authentication sent prior to sending the Finished message. If client authentication
is requested, the server MUST NOT send application data before it is requested, the server MUST NOT send application data before it
receives the client's Finished. receives the client's Finished.
[[TODO: Move this elsewhere? Note that higher layers should not be [[TODO: Move this elsewhere? Note that higher layers should not be
overly reliant on whether TLS always negotiates the strongest overly reliant on whether TLS always negotiates the strongest
possible connection between two endpoints. There are a number of possible connection between two endpoints. There are a number of
skipping to change at page 34, line 28 skipping to change at page 34, line 31
cognizant of what their security requirements are and never transmit cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require. The information over a channel less secure than what they require. The
TLS protocol is secure in that any cipher suite offers its promised TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate AES-GCM [GCM] with a 255-bit level of security: if you negotiate AES-GCM [GCM] with a 255-bit
ECDHE key exchange with a host whose certificate chain you have ECDHE key exchange with a host whose certificate chain you have
verified, you can expect that to be reasonably "secure" against verified, you can expect that to be reasonably "secure" against
algorithmic attacks, at least in the year 2015.]] algorithmic attacks, at least in the year 2015.]]
6.2.1. Incorrect DHE Share 6.2.1. Incorrect DHE Share
If the client has not provided an appropriate ClientKeyShare (e.g. it If the client has not provided an appropriate KeyShare extension
includes only DHE or ECDHE groups unacceptable or unsupported by the (e.g. it includes only DHE or ECDHE groups unacceptable or
server), the server corrects the mismatch with a HelloRetryRequest unsupported by the server), the server corrects the mismatch with a
and the client will need to restart the handshake with an appropriate HelloRetryRequest and the client will need to restart the handshake
ClientKeyShare, as shown in Figure 2: with an appropriate KeyShare extension, as shown in Figure 2:
Client Server Client Server
ClientHello ClientHello
+ ClientKeyShare --------> + KeyShare -------->
<-------- HelloRetryRequest <-------- HelloRetryRequest
ClientHello ClientHello
+ ClientKeyShare --------> + KeyShare -------->
ServerHello ServerHello
ServerKeyShare + KeyShare
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
skipping to change at page 36, line 10 skipping to change at page 36, line 10
application data as well as its Certificate and CertificateVerify (if application data as well as its Certificate and CertificateVerify (if
client authentication is requested) on its first flight, thus client authentication is requested) on its first flight, thus
reducing handshake latency. In order to enable this functionality, reducing handshake latency. In order to enable this functionality,
the server provides a ServerConfiguration message containing a long- the server provides a ServerConfiguration message containing a long-
term (EC)DH share. On future connections to the same server, the term (EC)DH share. On future connections to the same server, the
client can use that share to encrypt the first-flight data. client can use that share to encrypt the first-flight data.
Client Server Client Server
ClientHello ClientHello
+ ClientKeyShare + KeyShare
+ EarlyDataIndication + EarlyDataIndication
(EncryptedExtensions) (EncryptedExtensions)
(Certificate*) (Certificate*)
(CertificateVerify*) (CertificateVerify*)
(Application Data) --------> (Application Data) -------->
ServerHello ServerHello
+ KeyShare
+ EarlyDataIndication + EarlyDataIndication
ServerKeyShare
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
skipping to change at page 36, line 41 skipping to change at page 36, line 41
Figure 3: Message flow for a zero round trip handshake Figure 3: Message flow for a zero round trip handshake
Note: because sequence numbers continue to increment between the Note: because sequence numbers continue to increment between the
initial (early) application data and the application data sent after initial (early) application data and the application data sent after
the handshake has completed, an attacker cannot remove early the handshake has completed, an attacker cannot remove early
application data messages. application data messages.
IMPORTANT NOTE: The security properties for 0-RTT data (regardless of IMPORTANT NOTE: The security properties for 0-RTT data (regardless of
the cipher suite) are weaker than those for other kinds of TLS data. the cipher suite) are weaker than those for other kinds of TLS data.
Specifically. Specifically:
1. This data is not forward secure, because it is encrypted solely 1. This data is not forward secure, because it is encrypted solely
with the server's semi-static (EC)DH share. with the server's semi-static (EC)DH share.
2. There are no guarantees of non-replay between connections. 2. There are no guarantees of non-replay between connections.
Unless the server takes special measures outside those provided Unless the server takes special measures outside those provided
by TLS (See Section 6.3.2.5.2), the server has no guarantee that by TLS (See Section 6.3.2.5.2), the server has no guarantee that
the same 0-RTT data was not transmitted on multiple 0-RTT the same 0-RTT data was not transmitted on multiple 0-RTT
connections. This is especially relevant if the data is connections. This is especially relevant if the data is
authenticated either with TLS client authentication or inside the authenticated either with TLS client authentication or inside the
skipping to change at page 37, line 21 skipping to change at page 37, line 21
(as it knows the traffic key). (as it knows the traffic key).
6.2.3. Resumption and PSK 6.2.3. Resumption and PSK
Finally, TLS provides a pre-shared key (PSK) mode which allows a Finally, TLS provides a pre-shared key (PSK) mode which allows a
client and server who share an existing secret (e.g., a key client and server who share an existing secret (e.g., a key
established out of band) to establish a connection authenticated by established out of band) to establish a connection authenticated by
that key. PSKs can also be established in a previous session and that key. PSKs can also be established in a previous session and
then reused ("session resumption"). Once a handshake has completed, then reused ("session resumption"). Once a handshake has completed,
the server can send the client a PSK identity which corresponds to a the server can send the client a PSK identity which corresponds to a
key derived from the initial handshake (See Section 6.3.12). The key derived from the initial handshake (See Section 6.3.11). The
client can then use that PSK identity in future handshakes to client can then use that PSK identity in future handshakes to
negotiate use of the PSK; if the server accepts it, then the security negotiate use of the PSK; if the server accepts it, then the security
context of the original connection is tied to the new connection. In context of the original connection is tied to the new connection. In
TLS 1.2 and below, this functionality was provided by "session TLS 1.2 and below, this functionality was provided by "session
resumption" and "session tickets" [RFC5077]. Both mechanisms are resumption" and "session tickets" [RFC5077]. Both mechanisms are
obsoleted in TLS 1.3. obsoleted in TLS 1.3.
PSK cipher suites can either use PSK in combination with an (EC)DHE PSK cipher suites can either use PSK in combination with an (EC)DHE
exchange in order to provide forward secrecy in combination with exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward shared keys, or can use PSKs alone, at the cost of losing forward
secrecy. secrecy.
Figure 4 shows a pair of handshakes in which the first establishes a Figure 4 shows a pair of handshakes in which the first establishes a
PSK and the second uses it: PSK and the second uses it:
Client Server Client Server
Initial Handshake: Initial Handshake:
ClientHello ClientHello
+ ClientKeyShare --------> + KeyShare -------->
ServerHello ServerHello
ServerKeyShare + KeyShare
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
<-------- [NewSessionTicket] <-------- [NewSessionTicket]
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Subsequent Handshake: Subsequent Handshake:
ClientHello ClientHello
+ ClientKeyShare, + KeyShare
PreSharedKeyExtension --------> + PreSharedKeyExtension -------->
ServerHello ServerHello
+PreSharedKeyExtension + PreSharedKeyExtension
{EncryptedExtensions} {EncryptedExtensions}
<-------- {Finished} <-------- {Finished}
{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
As the server is authenticating via a PSK, it does not send a As the server is authenticating via a PSK, it does not send a
Certificate or a CertificateVerify. PSK-based resumption cannot be Certificate or a CertificateVerify. PSK-based resumption cannot be
used to provide a new ServerConfiguration. Note that the client used to provide a new ServerConfiguration. Note that the client
supplies a ClientKeyShare to the server as well, which allows the supplies a KeyShare to the server as well, which allows the server to
server to decline resumption and fall back to a full handshake. 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), client_hello(1),
session_ticket(4), hello_retry_request(6), server_hello(2),
server_key_share(7), encrypted_extensions(8), session_ticket(4),
certificate(11), reserved(12), certificate_request(13), hello_retry_request(6),
reserved(14), certificate_verify(15), reserved(16), encrypted_extensions(8),
server_configuration(17), finished(20), (255) certificate(11),
certificate_request(13),
certificate_verify(15),
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 encrypted_extensions: EncryptedExtensions; 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;
skipping to change at page 40, line 20 skipping to change at page 40, line 15
initialized to NULL_NULL. initialized to NULL_NULL.
6.3.1.1. Client Hello 6.3.1.1. Client Hello
When this message will be sent: When this message will be sent:
When a client first connects to a server, it is required to send When a client first connects to a server, it is required to send
the ClientHello as its first message. The client will also send a the ClientHello as its first message. The client will also send a
ClientHello when the server has responded to its ClientHello with ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare. In that case, the client MUST match the client's KeyShare extension. In that case, the client
send the same ClientHello (without modification) except including MUST send the same ClientHello (without modification) except
a new ClientKeyShare. [[OPEN ISSUE: New random values? See: including a new KeyShareEntry as the lowest priority share (i.e.,
https://github.com/tlswg/tls13-spec/issues/185]] If a server appended to the list of shares in the KeyShare message). [[OPEN
receives a ClientHello at any other time, it MUST send a fatal ISSUE: New random values? See: https://github.com/tlswg/tls13-
"unexpected_message" alert and close the connection. spec/issues/185]] If a server receives a ClientHello at any other
time, it MUST send a fatal "unexpected_message" alert and close
the connection.
Structure of this message: Structure of this message:
The ClientHello message includes a random structure, which is used The ClientHello message includes a random structure, which is used
later in the protocol. later in the protocol.
struct { struct {
opaque random_bytes[32]; opaque random_bytes[32];
} Random; } Random;
skipping to change at page 42, line 36 skipping to change at page 42, line 33
After sending the ClientHello message, the client waits for a After sending the ClientHello message, the client waits for a
ServerHello or HelloRetryRequest message. ServerHello or HelloRetryRequest message.
6.3.1.2. Server Hello 6.3.1.2. Server Hello
When this message will be sent: When this message will be sent:
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare extension was acceptable. If the and the client's KeyShare extension was acceptable. If the client
client proposed groups are not acceptable by the server, it will proposed groups are not acceptable by the server, it will respond
respond with a "handshake_failure" fatal alert. with a "handshake_failure" fatal alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
skipping to change at page 43, line 41 skipping to change at page 43, line 29
cipher_suite cipher_suite
The single cipher suite selected by the server from the list in The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed. [[TODO: the value from the state of the session being resumed. [[TODO:
interaction with PSK.]] interaction with PSK.]]
extensions extensions
A list of extensions. Note that only extensions offered by the A list of extensions. Note that only extensions offered by the
client can appear in the server's list. In TLS 1.3 as opposed to client can appear in the server's list. In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions Section 6.3.4 between the ServerHello and the EncryptedExtensions Section 6.3.3
message. The ServerHello MUST only include extensions which are message. The ServerHello MUST only include extensions which are
required to establish the cryptographic context. required to establish the cryptographic context.
6.3.1.3. Hello Retry Request 6.3.1.3. Hello Retry Request
When this message will be sent: When this message will be sent:
Servers send this message in response to a ClientHello message Servers send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and when it was able to find an acceptable set of algorithms and
groups that are mutually supported, but the client's groups that are mutually supported, but the client's KeyShare did
ClientKeyShare did not contain an acceptable offer. If it cannot not contain an acceptable offer. If it cannot find such a match,
find such a match, it will respond with a "handshake_failure" it will respond with a "handshake_failure" alert.
alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
skipping to change at page 44, line 17 skipping to change at page 44, line 4
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
[[OPEN ISSUE: Merge in DTLS Cookies?]] [[OPEN ISSUE: Merge in DTLS Cookies?]]
selected_group selected_group
The group which the client MUST use for its new ClientHello. The group which the client MUST use for its new ClientHello.
The "server_version", "cipher_suite" and "extensions" fields have the The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello. The same meanings as their corresponding values in the ServerHello. The
server SHOULD send only the extensions necessary for the client to server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair. generate a correct ClientHello pair.
Upon receipt of a HelloRetryRequest, the client MUST first verify Upon receipt of a HelloRetryRequest, the client MUST first verify
that the "selected_group" field does not identify a group which was that the "selected_group" field corresponds to a group which was
not in the original ClientHello. If it was present, then the client provided in the "supported_groups" extension in the original
MUST abort the handshake with a fatal "handshake_failure" alert. ClientHello. It MUST then verify that the "selected_group" field
Clients SHOULD also abort with "handshake_failure" in response to any does not correspond to a group which was provided in the "key_share"
second HelloRetryRequest which was sent in the same connection (i.e., extension in the original ClientHello. If either of these checks
where the ClientHello was itself in response to a HelloRetryRequest). fails, then the client MUST abort the handshake with a fatal
"handshake_failure" alert. Clients SHOULD also abort with
"handshake_failure" in response to any second HelloRetryRequest which
was sent in the same connection (i.e., where the ClientHello was
itself in response to a HelloRetryRequest).
Otherwise, the client MUST send a ClientHello with a new Otherwise, the client MUST send a ClientHello with a new KeyShare
ClientKeyShare extension to the server. The ClientKeyShare MUST extension to the server. The client MUST append a new KeyShareEntry
append a new ClientKeyShareOffer which is consistent with the list which is consistent with the "selected_group" field to the
"selected_group" field to the groups in the original ClientKeyShare. groups in its original KeyShare.
Upon re-sending the ClientHello and receiving the server's Upon re-sending the ClientHello and receiving the server's
ServerHello/ServerKeyShare, the client MUST verify that the selected ServerHello/KeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest. HelloRetryRequest.
[[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]
6.3.2. Hello Extensions 6.3.2. Hello Extensions
The extension format is: The extension format is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
supported_groups(10), supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), early_data(TBD),
pre_shared_key(TBD), pre_shared_key(TBD),
client_key_shares(TBD), key_share(TBD),
(65535) (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
skipping to change at page 47, line 11 skipping to change at page 47, line 11
version rollback attacks based on the version number, and the version rollback attacks based on the version number, and the
possibility of version rollback should be a significant possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
6.3.2.1. Signature Algorithms 6.3.2.1. Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in the server which signature/hash algorithm pairs may be used in
digital signatures. digital signatures.
All clients MUST send a valid "signature_algorithms" extension Clients which offer one or more cipher suites which use certificate
containing at least one supported SignatureAndHashAlgorithm when authentication (i.e., any non-PSK cipher suite) MUST send the
offering any certificate authenticated cipher suites. Servers MUST "signature_algorithms" extension. If this extension is not provided
NOT negotiate use of a certificate authenticated cipher suite unless and no alternative cipher suite is available, the server MUST close
the client supplies a supported SignatureAndHashAlgorithm. If the the connection with a fatal "missing_extension" alert. (see
extension is not provided and no alternative cipher suite is Section 8.2)
available, the server MUST close the connection with a fatal
"missing_extension" alert. (see Section 8.2)
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the
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),
sha1, sha1(2),
sha256(4), sha384(5), sha512(6), sha256(4), sha384(5), sha512(6),
(255) (255)
} HashAlgorithm; } HashAlgorithm;
enum { enum {
rsa(1), rsa(1),
dsa(2), dsa(2),
ecdsa(3), ecdsa(3),
rsapss(4), rsapss(4),
(255) (255)
skipping to change at page 48, line 38 skipping to change at page 48, line 31
signatures used in signed TLS handshake messages (see signatures used in signed TLS handshake messages (see
Section 4.9.1), as opposed to those in certificates, are RSASSA- Section 4.9.1), as opposed to those in certificates, are RSASSA-
PSS, the "rsa" value refers solely to signatures which appear in PSS, the "rsa" value refers solely to signatures which appear in
certificates. The use of DSA and anonymous is deprecated. certificates. The use of DSA and anonymous is deprecated.
Previous versions of TLS supported DSA. DSA is deprecated as of Previous versions of TLS supported DSA. DSA is deprecated as of
TLS 1.3 and SHOULD NOT be offered or negotiated by any TLS 1.3 and SHOULD NOT be offered or negotiated by any
implementation. 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.4 and Section 6.3.2.3 describe the
rules. appropriate rules.
Clients offering support for SHA-1 for TLS 1.2 servers MUST do so by 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 listing those hash/signature pairs as the lowest priority (listed
after all other pairs in the supported_signature_algorithms vector). after all other pairs in the supported_signature_algorithms vector).
TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no
valid certificate chain can be produced without it (see valid certificate chain can be produced without it (see
Section 6.3.5). Section 6.3.4).
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] when negotiating that version.
6.3.2.2. Negotiated Groups 6.3.2.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most the named groups which the client supports, ordered from most
preferred to least preferred. preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups. See "elliptic_curves" and only contained elliptic curve groups. See
[RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. [RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe].
All clients MUST send a valid "supported_groups" extension containing Clients which offer one or more (EC)DHE cipher suites MUST send at
at least one group for each ephemeral key exchange algorithm least one supported NamedGroup value and servers MUST NOT negotiate
(currently DHE and ECDHE) for which it offers a cipher suite. any of these cipher suites unless a supported value was provided. If
Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless this extension is not provided and no alternative cipher suite is
the client supplies a supported NamedGroup. If the extension is not available, the server MUST close the connection with a fatal
provided and no alternative cipher suite is available, the server "missing_extension" alert. (see Section 8.2) If the extension is
MUST close the connection with a fatal "missing_extension" alert. provided, but no compatible group is offered, the server MUST NOT
(see Section 8.2) If the extension is provided, but no compatible negotiate a cipher suite of the relevant type. For instance, if a
group is offered, the server MUST NOT negotiate a cipher suite of the client supplies only ECDHE groups, the server MUST NOT negotiate
relevant type. For instance, if a client supplies only ECDHE groups, finite field Diffie-Hellman. If no acceptable group can be selected
the server MUST NOT negotiate finite field Diffie-Hellman. If no across all cipher suites, then the server MUST generate a fatal
acceptable group can be selected across all cipher suites, then the "handshake_failure" alert.
server MUST generate a fatal "handshake_failure" alert.
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the
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.
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),
// Reserved Code Points. // Reserved Code Points.
ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1>; NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
secp256r1, etc. secp256r1, etc.
Indicates support of the corresponding named curve. Note that Indicates support of the corresponding named curve. Note that
skipping to change at page 50, line 47 skipping to change at page 50, line 18
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
NOTE: A server participating in an ECDHE-ECDSA key exchange may use NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii) different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyShare message. The server the ephemeral ECDH key in its KeyShare extension. The server must
must consider the supported groups in both cases. consider the supported groups in both cases.
[[TODO: IANA Considerations.]] [[TODO: IANA Considerations.]]
6.3.2.3. Client Key Share 6.3.2.3. Key Share
The "client_key_share" extension contains the client's cryptographic
parameters for zero or more non-PSK key establishment methods
(currently DHE or ECDHE).
All clients MUST send a valid "client_key_share" extension when
offering any DHE or ECDHE cipher suites. Servers MUST NOT negotiate
use of a DHE or ECDHE cipher suites unless the client supplies a
(possibly empty) "client_key_share" extension. If the extension is
not provided and no alternative cipher suite is available, the server
MUST close the connection with a fatal "missing_extension" alert.
(see Section 8.2)
Servers MUST NOT send this extension. TLS servers MUST support The "key_share" extension contains the endpoint's cryptographic
receiving this extension. Clients receiving this extension MUST parameters for non-PSK key establishment methods (currently DHE or
respond with an "unsupported_extension" alert and close the ECDHE).
connection.
[[OPEN ISSUE: Would it be better to omit it if it's empty?. Clients which offer one or more (EC)DHE cipher suites MUST send at
https://github.com/tlswg/tls13-spec/issues/190]] least one supported KeyShare value and servers MUST NOT negotiate any
of these cipher suites unless a supported value was provided. If
this extension is not provided in a ServerHello or retried
ClientHello, and the peer is offering (EC)DHE cipher suites, then the
endpoint MUST close the connection with a fatal "missing_extension"
alert. (see Section 8.2)
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } KeyShareEntry;
group group
The named group for the key share offer. This identifies the The named group for the key being exchanged. Finite Field Diffie-
specific key exchange method that the ClientKeyShareOffer Hellman [DH] parameters are described in Section 6.3.2.3.1;
describes. Finite Field Diffie-Hellman [DH] parameters are Elliptic Curve Diffie-Hellman parameters are described in
described in Section 6.3.2.3.1; Elliptic Curve Diffie-Hellman Section 6.3.2.3.2.
parameters are described in Section 6.3.2.3.2.
key_exchange key_exchange
Key exchange information. The contents of this field are Key exchange information. The contents of this field are
determined by the value of NamedGroup entry and its corresponding determined by the specified group and its corresponding
definition. definition. Endpoints MUST NOT send empty or otherwise invalid
key_exchange values for any reason.
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a "KeyShare"
"ClientKeyShare" value: value:
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; select (role) {
} ClientKeyShare; case client:
KeyShareEntry client_shares<4..2^16-1>;
offers case server:
A list of ClientKeyShareOffer values in descending order of client KeyShareEntry server_share;
preference. }
} KeyShare;
Clients may offer an arbitrary number of ClientKeyShareOffer values, client_shares
each representing a single set of key exchange parameters; for A list of offered KeyShareEntry values in descending order of
instance a client might offer shares for several elliptic curves or client preference. This vector MUST NOT be empty. Clients not
multiple integer DH groups. The shares for each ClientKeyShareOffer providing a KeyShare MUST instead omit this extension from the
ClientHello.
server_shares
A single KeyShareEntry value for the negotiated cipher suite.
Servers MUST NOT send a KeyShareEntry value for a group not
offered by the client.
Servers offer exactly one KeyShareEntry value, which corresponds to
the key exchange used for the negotiated cipher suite.
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters. For instance,
a client might offer shares for several elliptic curves or multiple
integer DH groups. The key_exchange values for each KeyShareEntry
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 KeyShareEntry values for the same parameters. Clients MAY omit this
permitted to send an empty "client_key_share" extension as this is extension from the ClientHello, and in response to this, servers MUST
used to elicit the server's parameters if the client has no useful send a HelloRetryRequest requesting use of one of the groups the
information. client offered support for in its "supported_groups" extension. If
no common supported group is available, the server MUST produce a
fatal "handshake_failure" alert. (see Section 6.3.1.3)
[[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.]]
6.3.2.3.1. Diffie-Hellman Parameters 6.3.2.3.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of the ClientKeyShareOffer encoded in the opaque key_exchange field of a KeyShareEntry in a
or ServerKeyShare structures. The opaque value contains the Diffie- KeyShare structure. The opaque value contains the Diffie-Hellman
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian public value (dh_Y = g^X mod p), encoded as a big-endian integer.
integer.
opaque dh_Y<1..2^16-1>; opaque dh_Y<1..2^16-1>;
6.3.2.3.2. ECDHE Parameters 6.3.2.3.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the ECDHE parameters for both clients and servers are encoded in the the
opaque key_exchange field of the ClientKeyShareOffer or opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
ServerKeyShare structures. The opaque value conveys the Elliptic The opaque value conveys the Elliptic Curve Diffie-Hellman public
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte value (ecdh_Y) represented as a byte string ECPoint.point.
string ECPoint.point.
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
point point
This is the byte string representation of an elliptic curve point This is the byte string representation of an elliptic curve point
following the conversion routine in Section 4.3.6 of ANSI X9.62 following the conversion routine in Section 4.3.6 of ANSI X9.62
[X962]. [X962].
Although X9.62 supports multiple point formats, any given curve MUST Although X9.62 supports multiple point formats, any given curve MUST
specify only a single point format. All curves currently specified specify only a single point format. All curves currently specified
skipping to change at page 53, line 22 skipping to change at page 52, line 43
future curves will come with defined point formats and that existing future curves will come with defined point formats and that existing
curves conform to X9.62.]] curves conform to X9.62.]]
6.3.2.4. Pre-Shared Key Extension 6.3.2.4. Pre-Shared Key Extension
The "pre_shared_key" extension is used to indicate the identity of The "pre_shared_key" extension is used to indicate the identity of
the pre-shared key to be used with a given handshake in association the pre-shared key to be used with a given handshake in association
with a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for with a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for
background). background).
All clients MUST send a valid "pre_shared_key" extension when Clients which offer one or more PSK cipher suites MUST send at least
offering any PSK cipher suites. Servers MUST NOT negotiate use of a one supported psk_identity value and servers MUST NOT negotiate any
PSK cipher suite unless the client supplies a "pre_shared_key" of these cipher suites unless a supported value was provided. If
extension. If the extension is not provided and no alternative this extension is not provided and no alternative cipher suite is
cipher suite is available, the server MUST close the connection with available, the server MUST close the connection with a fatal
a fatal "missing_extension" alert. (see Section 8.2) "missing_extension" alert. (see Section 8.2)
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"PreSharedKeyExtension" value: "PreSharedKeyExtension" value:
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..2^16-1>;
struct { struct {
select (Role) { select (Role) {
case client: case client:
psk_identity identities<0..2^16-1>; psk_identity identities<2..2^16-1>;
case server: case server:
psk_identity identity; psk_identity identity;
} }
} PreSharedKeyExtension; } PreSharedKeyExtension;
identity identity
An opaque label for the pre-shared key. An opaque label for the pre-shared key.
If no suitable identity is provided, the server MUST NOT negotiate a If no suitable identity is provided, the server MUST NOT negotiate a
skipping to change at page 54, line 15 skipping to change at page 53, line 37
If the server selects a PSK cipher suite, it MUST send a If the server selects a PSK cipher suite, it MUST send a
PreSharedKeyExtension with the identity that it selected. The client PreSharedKeyExtension with the identity that it selected. The client
MUST verify that the server has selected one of the identities that MUST verify that the server has selected one of the identities that
the client supplied. If any other identity is returned, the client the client supplied. If any other identity is returned, the client
MUST generate a fatal "unknown_psk_identity" alert and close the MUST generate a fatal "unknown_psk_identity" alert and close the
connection. connection.
6.3.2.5. Early Data Indication 6.3.2.5. Early Data Indication
In cases where TLS clients have previously interacted with the server In cases where TLS clients have previously interacted with the server
and the server has supplied a ServerConfiguration Section 6.3.7, the and the server has supplied a ServerConfiguration Section 6.3.6, the
client can send application data and its Certificate/ client can send application data and its Certificate/
CertificateVerify messages (if client authentication is required). CertificateVerify messages (if client authentication is required).
If the client opts to do so, it MUST supply an Early Data Indication If the client opts to do so, it MUST supply an Early Data Indication
extension. extension.
The "extension_data" field of this extension contains an The "extension_data" field of this extension contains an
"EarlyDataIndication" value: "EarlyDataIndication" value:
enum { client_authentication(1), early_data(2), enum { client_authentication(1), early_data(2),
client_authentication_and_data(3), (255) } EarlyDataType; client_authentication_and_data(3), (255) } EarlyDataType;
skipping to change at page 57, line 20 skipping to change at page 57, line 5
As noted in Section 6.2.2, TLS does not provide any inter-connection As noted in Section 6.2.2, TLS does not provide any inter-connection
mechanism for replay protection for data sent by the client in the mechanism for replay protection for data sent by the client in the
first flight. As a special case, implementations where the server first flight. As a special case, implementations where the server
configuration, is delivered out of band (as has been proposed for configuration, is delivered out of band (as has been proposed for
DTLS-SRTP [RFC5763]), MAY use a unique server configuration DTLS-SRTP [RFC5763]), MAY use a unique server configuration
identifier for each connection, thus preventing replay. identifier for each connection, thus preventing replay.
Implementations are responsible for ensuring uniqueness of the Implementations are responsible for ensuring uniqueness of the
identifier in this case. identifier in this case.
6.3.3. Server Key Share 6.3.3. Encrypted Extensions
When this message will be sent:
This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyShare extension
which is compatible with the selected cipher suite and group
parameters.
Meaning of this message:
This message conveys cryptographic information to allow the client
to compute a shared secret secret: a Diffie-Hellman public key
with which the client can complete a key exchange (with the result
being the shared secret) or a public key for some other algorithm.
Structure of this message:
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} ServerKeyShare;
group
The named group for the key share offer. This identifies the
selected key exchange method from the ClientKeyShare
(Section 6.3.2.3), identifying which value from the
ClientKeyShareOffer the server has accepted as is responding to.
key_exchange
Key exchange information. The contents of this field are
determined by the value of NamedGroup entry and its corresponding
definition.
6.3.4. Encrypted Extensions
When this message will be sent: When this message will be sent:
If this message is sent, it MUST be sent immediately after the If this message is sent, it MUST be sent immediately after the
server's ServerKeyShare. This is the first message that is ServerHello message. This is the first message that is encrypted
encrypted under keys derived from ES. under keys derived from ES.
Meaning of this message: Meaning of this message:
The EncryptedExtensions message simply contains any extensions The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to which should be protected, i.e., any which are not needed to
establish the cryptographic context. The same extension types establish the cryptographic context. The same extension types
MUST NOT appear in both the ServerHello and EncryptedExtensions. MUST NOT appear in both the ServerHello and EncryptedExtensions.
If the same extension appears in both locations, the client MUST If the same extension appears in both locations, the client MUST
rely only on the value in the EncryptedExtensions block. [[OPEN rely only on the value in the EncryptedExtensions block. [[OPEN
ISSUE: Should we just produce a canonical list of what goes where ISSUE: Should we just produce a canonical list of what goes where
skipping to change at page 58, line 35 skipping to change at page 57, line 35
Structure of this message: Structure of this message:
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
extensions extensions
A list of extensions. A list of extensions.
6.3.5. Server Certificate 6.3.4. 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 PSK). This message will always immediately follow the except PSK). This message will always immediately follow the
EncryptedExtensions message. EncryptedExtensions message.
Meaning of this message: Meaning of this message:
skipping to change at page 60, line 12 skipping to change at page 59, line 12
restrictions) MUST be compatible with the selected key exchange restrictions) MUST be compatible with the selected key exchange
algorithm. algorithm.
Key Exchange Alg. Certificate Key Type Key Exchange Alg. Certificate Key Type
DHE_RSA RSA public key; the certificate MUST allow the DHE_RSA RSA public key; the certificate MUST allow the
ECDHE_RSA key to be used for signing (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 server's KeyShare extension.
Note: ECDHE_RSA is defined in [RFC4492]. Note: ECDHE_RSA is defined in [RFC4492].
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 server's KeyShare extension. 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"
skipping to change at page 61, line 11 skipping to change at page 60, line 11
or better as soon as possible to maintain interoperability with or better as soon as possible to maintain interoperability with
implementations currently in the process of phasing out SHA-1 implementations currently in the process of phasing out SHA-1
support. support.
Note that a certificate containing a key for one signature algorithm Note that a certificate containing a key for one signature algorithm
MAY be signed using a different signature algorithm (for instance, an MAY be signed using a different signature algorithm (for instance, an
RSA key signed with a ECDSA key). 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 If the server has a single certificate, it SHOULD attempt to validate
validate that it meets these criteria. that it meets these criteria.
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.5. 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 {
rsa_sign(1),
ecdsa_sign(64),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} CertificateExtension;
struct {
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>;
CertificateExtension certificate_extensions<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_types
A list of the types of certificate types that the client may
offer.
rsa_sign a certificate containing an RSA key
rsa_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. Any
certificates provided by the client MUST be signed using a hash/
signature algorithm pair found in supported_signature_algorithms.
certificate_authorities certificate_authorities
A list of the distinguished names [X501] of acceptable A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These certificate_authorities, represented in DER-encoded [X690] format.
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
The interaction of the certificate_types and These distinguished names may specify a desired distinguished name
supported_signature_algorithms fields is somewhat complicated. for a root CA or for a subordinate CA; thus, this message can be
certificate_types has been present in TLS since SSL 3.0, but was used to describe known roots as well as a desired authorization
somewhat underspecified. Much of its functionality is superseded by space. If the certificate_authorities list is empty, then the
supported_signature_algorithms. The following rules apply: client MAY send any certificate that meets the rest of the
selection criteria in the CertificateRequest, unless there is some
external arrangement to the contrary.
- Any certificates provided by the client MUST be signed using a certificate_extensions
hash/signature algorithm pair found in A list of certificate extension OIDs [RFC5280] with their allowed
supported_signature_algorithms. values, represented in DER-encoded format. Some certificate
extension OIDs allow multiple values (e.g. Extended Key Usage).
If the server has included a non-empty certificate_extensions
list, the client certificate MUST contain all of the specified
extension OIDs that the client recognizes. For each extension OID
recognized by the client, all of the specified values MUST be
present in the client certificate (but the certificate MAY have
other values as well). However, the client MUST ignore and skip
any unrecognized certificate extension OIDs. If the client has
ignored some of the required certificate extension OIDs, and
supplied a certificate that does not satisfy the request, the
server MAY at its discretion either continue the session without
client authentication, or terminate the session with a fatal
unsupported_certificate alert. PKIX RFCs define a variety of
certificate extension OIDs and their corresponding value types.
Depending on the type, matching certificate extension values are
not necessarily bitwise-equal. It is expected that TLS
implementations will rely on their PKI libraries to perform
certificate selection using certificate extension OIDs. This
document defines matching rules for two standard certificate
extensions defined in [RFC5280]:
- The end-entity certificate provided by the client MUST contain a o The Key Usage extension in a certificate matches the request
key that is compatible with certificate_types. If the key is a when all key usage bits asserted in the request are also
signature key, it MUST be usable with some hash/signature asserted in the Key Usage certificate extension.
algorithm pair in supported_signature_algorithms.
New ClientCertificateType values are assigned by IANA as described in o The Extended Key Usage extension in a certificate matches the
Section 11. request when all key purpose OIDs present in the request are
also found in the Extended Key Usage certificate extension.
The special anyExtendedKeyUsage OID MUST NOT be used in the
request.
Separate specifications may define matching rules for other
certificate extensions.
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.6. 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
message is sent as the last message before the CertificateVerify. message is sent as the last message before the CertificateVerify.
Structure of this Message: Structure of this Message:
skipping to change at page 63, line 31 skipping to change at page 62, line 42
configuration_id configuration_id
The configuration identifier to be used in 0-RTT mode. The configuration identifier to be used in 0-RTT mode.
group group
The group for the long-term DH key that is being established for The group for the long-term DH key that is being established for
this configuration. this configuration.
expiration_date expiration_date
The last time when this configuration is expected to be valid (in The last time when this configuration is expected to be valid (in
seconds since the Unix epoch). Servers MUST NOT use any value seconds since the Unix epoch). Servers MUST NOT use any value
more than 604800 seconds (7 days) in the future. Clients MUST not more than 604800 seconds (7 days) in the future. Clients MUST NOT
cache configurations for longer than 7 days, regardless of the cache configurations for longer than 7 days, regardless of the
expiration_date. [[OPEN ISSUE: Is this the right value? The idea expiration_date. [[OPEN ISSUE: Is this the right value? The idea
is just to minimize exposure.]] is just to minimize exposure.]]
server_key server_key
The long-term DH key that is being established for this The long-term DH key that is being established for this
configuration. configuration.
early_data_type early_data_type
The type of 0-RTT handshake that this configuration is to be used The type of 0-RTT handshake that this configuration is to be used
skipping to change at page 64, line 14 skipping to change at page 63, line 26
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. Clients MUST not rely on the ServerConfiguration message the client. Clients MUST NOT rely on the ServerConfiguration message
until successfully receiving and processing the server's Certificate, until successfully receiving and processing the server's Certificate,
CertificateVerify, and Finished. If there is a failure in processing CertificateVerify, and Finished. If there is a failure in processing
those messages, the client MUST discard the ServerConfiguration. those messages, the client MUST discard the ServerConfiguration.
6.3.8. Server Certificate Verify 6.3.7. Server Certificate Verify
When this message will be sent: When this message will be sent:
This message is used to provide explicit proof that the server This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate 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 handshake_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
skipping to change at page 65, line 26 skipping to change at page 64, line 39
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. RSA signatures MUST be based on in the certificate, if any. RSA signatures MUST be based on
RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in
"signature_algorithms". SHA-1 MUST NOT be used in any signatures "signature_algorithms". SHA-1 MUST NOT be used in any signatures
in CertificateVerify, regardless of whether SHA-1 appears in in CertificateVerify, regardless of whether SHA-1 appears in
"signature_algorithms". "signature_algorithms".
6.3.9. Server Finished 6.3.8. Server Finished
When this message will be sent: When this message will be sent:
The Server's Finished message is the final message sent by the The Server's Finished message is the final message sent by the
server and 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:
Recipients of Finished messages MUST verify that the contents are Recipients of Finished messages MUST verify that the contents are
skipping to change at page 66, line 21 skipping to change at page 65, line 34
"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.
6.3.10. Client Certificate 6.3.9. 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
structure has a length of zero. If the client does not send any structure has a length of zero. If the client does not send any
certificates, the server MAY at its discretion either continue the certificates, the server MAY at its discretion either continue the
handshake without client authentication, or respond with a fatal handshake without client authentication, or respond with a fatal
"handshake_failure" alert. Also, if some aspect of the "handshake_failure" alert. Also, if some aspect of the
certificate chain was unacceptable (e.g., it was not signed by a certificate chain was unacceptable (e.g., it was not signed by a
known, trusted CA), the server MAY at its discretion either known, trusted CA), the server MAY at its discretion either
continue the handshake (considering the client unauthenticated) or continue the handshake (considering the client unauthenticated) or
send a fatal alert. send a fatal alert.
Client certificates are sent using the Certificate structure Client certificates are sent using the Certificate structure
defined in Section 6.3.5. defined in Section 6.3.4.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate chain to the server; This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing). The message (when the client authentication is based on signing). The
certificate MUST be appropriate for the negotiated cipher suite's certificate MUST be appropriate for the negotiated cipher suite's
key exchange algorithm, and any negotiated extensions. key exchange algorithm, and any negotiated extensions.
In particular: In particular:
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
negotiated otherwise (e.g., [RFC5081]). negotiated otherwise (e.g., [RFC5081]).
- The end-entity certificate's public key (and associated
restrictions) has to be compatible with the certificate types
listed in CertificateRequest:
Client Cert. Type Certificate Key Type
rsa_sign RSA public key; the certificate MUST allow the
key to be used for signing with the signature
scheme and hash algorithm that will be
employed in the CertificateVerify message.
ecdsa_sign ECDSA-capable 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; the public key
MUST use a curve and point format supported by
the server.
rsa_fixed_dh Diffie-Hellman public key; MUST use the same
parameters as server's key.
rsa_fixed_ecdh ECDH-capable public key; MUST use the
ecdsa_fixed_ecdh same curve as the server's key, and MUST use a
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/
signature algorithm pair, as described in Section 6.3.6. Note signature algorithm pair, as described in Section 6.3.5. Note
that this relaxes the constraints on certificate-signing that this relaxes the constraints on certificate-signing
algorithms found in prior versions of TLS. algorithms found in prior versions of TLS.
- If the certificate_extensions list in the certificate request
message was non-empty, the end-entity certificate MUST match the
extension OIDs recognized by the client, as described in
Section 6.3.5.
Note that, as with the server certificate, there are certificates Note that, as with the server certificate, there are certificates
that use algorithms/algorithm combinations that cannot be currently that use algorithms/algorithm combinations that cannot be currently
used with TLS. used with TLS.
6.3.11. Client Certificate Verify 6.3.10. Client Certificate Verify
When this message will be sent: When this message will be sent:
This message is used to provide explicit verification of a client This message is used to provide explicit verification of a client
certificate. This message is only sent following a client certificate. This message is only sent following a client
certificate that has signing capability (i.e., all certificates certificate that has signing capability (i.e., all certificates
except those containing fixed Diffie-Hellman parameters). When except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client's Certificate message. sent, it MUST immediately follow the client's Certificate message.
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.7, 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. RSA signatures MUST be based on RSASSA-PSS, certificate, if any. RSA signatures MUST be based on RSASSA-PSS,
regardless of whether RSASSA-PKCS-v1_5 appears in regardless of whether RSASSA-PKCS-v1_5 appears in
"signature_algorithms". SHA-1 MUST NOT be used in any signatures "signature_algorithms". SHA-1 MUST NOT be used in any signatures
in CertificateVerify, regardless of whether SHA-1 appears in in CertificateVerify, regardless of whether SHA-1 appears in
"signature_algorithms". "signature_algorithms".
6.3.12. New Session Ticket Message 6.3.11. 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.
skipping to change at page 72, line 18 skipping to change at page 71, line 10
server_write_IV[SecurityParameters.iv_length] server_write_IV[SecurityParameters.iv_length]
The following table describes the inputs to the key calculation for The following table describes the inputs to the key calculation for
each class of traffic keys: each class of traffic keys:
Record Type Secret Label Handshake Hash Record Type Secret Label Handshake Hash
----------- ------ ----- --------------- ----------- ------ ----- ---------------
Early data xSS "early data key expansion" ClientHello Early data xSS "early data key expansion" ClientHello
Handshake xES "handshake key expansion" ClientHello... Handshake xES "handshake key expansion" ClientHello...
ServerKeyShare ServerHello
Application master "application data key expansion" All handshake Application master "application data key expansion" All handshake
secret messages but secret messages but
Finished Finished
(session_hash) (session_hash)
7.2.1. The Handshake Hash 7.2.1. The Handshake Hash
handshake_hash = Hash( handshake_hash = Hash(
Hash(handshake_messages) || Hash(handshake_messages) ||
skipping to change at page 73, line 39 skipping to change at page 72, line 30
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 following otherwise, a TLS-compliant application MUST implement the following
cipher suites: cipher suites:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
These cipher suites MUST support both digital signatures and key These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key exchange exchange with secp256r1 (NIST P-256) and SHOULD support key exchange
with X25519 [I-D.irtf-cfrg-curves]. with X25519 [I-D.irtf-cfrg-curves].
A TLS-compliant application SHOULD implement the following cipher A TLS-compliant application SHOULD implement the following cipher
suites: 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 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
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)
- Client Key Share ("client_key_share"; Section 6.3.2.3) - Key Share ("key_share"; Section 6.3.2.3)
- Pre-Shared Key Extension ("pre_shared_key"; Section 6.3.2.4) - Pre-Shared Key Extension ("pre_shared_key"; Section 6.3.2.4)
- Server Name Indication ("server_name"; Section 3 of [RFC6066]) - Server Name Indication ("server_name"; Section 3 of [RFC6066])
All implementations MUST send and use these extensions when offering All implementations MUST send and use these extensions when offering
applicable cipher suites: applicable cipher suites:
- "signature_algorithms" is REQUIRED for certificate authenticated - "signature_algorithms" is REQUIRED for certificate authenticated
cipher suites cipher suites
- "supported_groups" and "client_key_share" are REQUIRED for DHE or - "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
ECDHE cipher suites cipher suites
- "pre_shared_key" is REQUIRED for PSK cipher suites - "pre_shared_key" is REQUIRED for PSK cipher suites
When negotiating use of applicable cipher suites, endpoints MUST When negotiating use of applicable cipher suites, endpoints MUST
abort the connection with a "missing_extension" alert if the required abort the connection with a "missing_extension" alert if the required
extension was not provided. Any endpoint that receives any invalid extension was not provided. Any endpoint that receives any invalid
combination of cipher suites and extensions MAY abort the connection combination of cipher suites and extensions MAY abort the connection
with a "missing_extension" alert, regardless of negotiated with a "missing_extension" alert, regardless of negotiated
parameters. parameters.
Additionally, all implementations MUST support use of the Additionally, all implementations MUST support use of the
"server_name" extension with applications capable of using it. "server_name" extension with applications capable of using it.
Servers MAY require clients to send a valid "server_name" extension. Servers MAY require clients to send a valid "server_name" extension.
Servers requiring this extension SHOULD respond to a ClientHello Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension with a fatal "missing_extension" lacking a "server_name" extension with a fatal "missing_extension"
alert. alert.
Some of these extensions exist only for the client to provide
additional data to the server in a backwards-compatible way and thus
have no meaning when sent from a server. The client-only extensions
defined in this document are: "Signature Algorithms" & "Negotiated
Groups". Servers MUST NOT send these extensions. Clients receiving
any of these extensions MUST respond with a fatal
"unsupported_extension" alert and close the connection.
9. Application Data Protocol 9. Application Data Protocol
Application data messages are carried by the record layer and are Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
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.
skipping to change at page 75, line 27 skipping to change at page 74, line 21
[[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- [[TODO: Rename "RSA" in TLS SignatureAlgorithm Registry to RSASSA-
PKCS1-v1_5 ]] 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
the range 0-63 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
are assigned via Specification Required [RFC2434]. Values from
224-255 (decimal) inclusive are reserved for Private Use
[RFC2434].
- TLS Cipher Suite Registry: Future values with the first byte in - TLS Cipher Suite Registry: Future values with the first byte in
the range 0-191 (decimal) inclusive are assigned via Standards the range 0-191 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values with the first byte in the range 192-254 Action [RFC2434]. Values with the first byte in the range 192-254
(decimal) are assigned via Specification Required [RFC2434]. (decimal) are assigned via Specification Required [RFC2434].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
Use [RFC2434]. Use [RFC2434].
- TLS ContentType Registry: Future values are allocated via - TLS ContentType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
skipping to change at page 78, line 39 skipping to change at page 77, line 29
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<http://www.rfc-editor.org/info/rfc7251>. <http://www.rfc-editor.org/info/rfc7251>.
[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
One (ASN.1): Specification of basic notation", ISO/IEC
8824-1:2002, 2002.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
12.2. Informative References 12.2. Informative References
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", May 2004,
<https://www.openssl.org/~bodo/tls-cbc.txt>.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard, Department of Commerce, "Digital Signature Standard,
version 4", NIST FIPS PUB 186-4, 2013. 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
skipping to change at page 79, line 43 skipping to change at page 78, line 24
[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, DOI 10.17487/RFC0793, September 1981, 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
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, DOI 10.17487/RFC1948, May 1996, RFC 1948, DOI 10.17487/RFC1948, May 1996,
<http://www.rfc-editor.org/info/rfc1948>. <http://www.rfc-editor.org/info/rfc1948>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999,
<http://www.rfc-editor.org/info/rfc2246>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", RFC Ciphersuites for Transport Layer Security (TLS)", RFC
4279, DOI 10.17487/RFC4279, December 2005, 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>. <http://www.rfc-editor.org/info/rfc4279>.
skipping to change at page 81, line 19 skipping to change at page 79, line 39
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>. <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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008, RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[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, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>. <http://www.rfc-editor.org/info/rfc5929>.
skipping to change at page 81, line 47 skipping to change at page 80, line 15
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI
10.17487/RFC7465, February 2015, 10.17487/RFC7465, February 2015,
<http://www.rfc-editor.org/info/rfc7465>. <http://www.rfc-editor.org/info/rfc7465>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
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,
DOI 10.17487/RFC7568, June 2015, DOI 10.17487/RFC7568, June 2015,
<http://www.rfc-editor.org/info/rfc7568>. <http://www.rfc-editor.org/info/rfc7568>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", RFC Session Hash and Extended Master Secret Extension", RFC
7627, DOI 10.17487/RFC7627, September 2015, 7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>. <http://www.rfc-editor.org/info/rfc7627>.
skipping to change at page 83, line 20 skipping to change at page 81, line 20
but may receive them from older TLS implementations. 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(0), invalid_RESERVED(0),
reserved(20), alert(21), handshake(22), change_cipher_spec_RESERVED(20),
application_data(23), early_handshake(25), alert(21),
handshake(22),
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];
} TLSPlaintext; } TLSPlaintext;
skipping to change at page 85, line 5 skipping to change at page 83, line 5
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.3. Handshake Protocol A.3. Handshake Protocol
enum { enum {
reserved(0), client_hello(1), server_hello(2), hello_request_RESERVED(0),
session_ticket(4), hello_retry_request(6), client_hello(1),
server_key_share(7), encrypted_extensions(8), server_hello(2),
certificate(11), reserved(12), certificate_request(13), session_ticket(4),
reserved(14), certificate_verify(15), reserved(16), hello_retry_request(6),
server_configuration(17), finished(20), (255) encrypted_extensions(8),
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_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 encrypted_extensions: EncryptedExtensions; 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;
skipping to change at page 86, line 28 skipping to change at page 84, line 36
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
supported_groups(10), supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), early_data(TBD),
pre_shared_key(TBD), pre_shared_key(TBD),
client_key_shares(TBD), key_share(TBD),
(65535) (65535)
} ExtensionType; } ExtensionType;
opaque psk_identity<0..2^16-1>; opaque psk_identity<0..2^16-1>;
struct { struct {
select (Role) { select (Role) {
case client: case client:
psk_identity identities<0..2^16-1>; psk_identity identities<2..2^16-1>;
case server: case server:
psk_identity identity; psk_identity identity;
} }
} PreSharedKeyExtension; } PreSharedKeyExtension;
enum { client_authentication(1), early_data(2), enum { client_authentication(1), early_data(2),
client_authentication_and_data(3), (255) } EarlyDataType; client_authentication_and_data(3), (255) } EarlyDataType;
struct { struct {
skipping to change at page 88, line 7 skipping to change at page 86, 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, sha1(2),
sha224_RESERVED(3), sha224_RESERVED(3),
sha256(4), sha384(5), sha512(6), sha256(4), sha384(5), sha512(6),
(255) (255)
} HashAlgorithm; } HashAlgorithm;
enum { enum {
anonymous_RESERVED(0), anonymous_RESERVED(0),
rsa(1), rsa(1),
dsa(2), dsa(2),
ecdsa(3), ecdsa(3),
skipping to change at page 88, line 40 skipping to change at page 86, line 40
A.3.1.2. Named Group Extension A.3.1.2. Named Group Extension
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
obsolete_RESERVED (1..22), 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),
// Reserved Code Points. // Reserved Code Points.
ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
obsolete_RESERVED (0xFF01..0xFF02), obsolete_RESERVED (0xFF01..0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
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 Values within "obsolete_RESERVED" ranges were used in previous
skipping to change at page 89, line 20 skipping to change at page 87, line 20
considered appropriate for general use and should be assumed to be considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly for interoperability with all currently deployed and properly
configured TLS implementations. 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; } KeyShareEntry;
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; select (role) {
} ClientKeyShare; case client:
KeyShareEntry client_shares<4..2^16-1>;
case server:
KeyShareEntry server_share;
}
} KeyShare;
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 {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} 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 {
rsa_sign(1),
dss_sign_RESERVED(2),
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;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} CertificateExtension;
struct {
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>;
CertificateExtension certificate_extensions<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
skipping to change at page 94, line 21 skipping to change at page 92, line 10
RFC 4492 do not need to read this section. RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally- This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to algorithms used to create a signature. This change applies to
digital signatures formed using ECDSA as well, thus allowing ECDSA digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1, signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [RFC5280]. restrictions imposed by future revisions of [RFC5280].
As described in Section 6.3.5 and Section 6.3.10, the restrictions on As described in Section 6.3.4, the restrictions on the signature
the signature algorithms used to sign certificates are no longer tied algorithms used to sign certificates are no longer tied to the cipher
to the cipher suite (when used by the server) or the suite. Thus, the restrictions on the algorithm used to sign
ClientCertificateType (when used by the client). Thus, the certificates specified in Sections 2 and 3 of RFC 4492 are also
restrictions on the algorithm used to sign certificates specified in relaxed. As in this document, the restrictions on the keys in the
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, end-entity certificate remain.
the restrictions on the keys in the end-entity certificate remain.
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
skipping to change at page 96, line 8 skipping to change at page 93, line 48
removed from all possible configurations that support TLS 1.3 or removed from all possible configurations that support TLS 1.3 or
later, and that attempts to use these obsolete capabilities fail later, and that attempts to use these obsolete capabilities fail
correctly? (see Appendix C) 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.9)?
- When processing the plaintext fragment produced by AEAD-Decrypt - When processing the plaintext fragment produced by AEAD-Decrypt
and scanning from the end for the ContentType, do you avoid and scanning from the end for the ContentType, do you avoid
scanning past the start of the cleartext in the event that the scanning past the start of the cleartext in the event that the
peer has sent a malformed plaintext of all-zeros? 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]?
skipping to change at page 97, line 11 skipping to change at page 95, line 5
(ClientHello.client_version & ServerHello.server_version) In order to (ClientHello.client_version & ServerHello.server_version) In order to
maximize interoperability with older endpoints, implementations that maximize interoperability with older endpoints, implementations that
negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version
number to the negotiated version for the ServerHello and all records number to the negotiated version for the ServerHello and all records
thereafter. thereafter.
For maximum compatibility with previously non-standard behavior and For maximum compatibility with previously non-standard behavior and
misconfigured deployments, all implementations SHOULD support misconfigured deployments, all implementations SHOULD support
validation of certificate chains based on the expectations in this validation of certificate chains based on the expectations in this
document, even when handling prior TLS versions' handshakes. (see document, even when handling prior TLS versions' handshakes. (see
Section 6.3.5) Section 6.3.4)
C.1. Negotiating with an older server C.1. Negotiating with an older server
A TLS 1.3 client who wishes to negotiate with such older servers will A TLS 1.3 client who wishes to negotiate with such older servers will
send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in
ClientHello.client_version. If the server does not support this ClientHello.client_version. If the server does not support this
version it will respond with a ServerHello containing an older version it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol. negotiation will proceed as appropriate for the negotiated protocol.
A client resuming a session SHOULD initiate the connection using the A client resuming a session SHOULD initiate the connection using the
skipping to change at page 99, line 46 skipping to change at page 97, line 38
leading to an acceptable certificate authority. Similarly, leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's server. Each party is responsible for verifying that the other's
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.8 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. Diffie-Hellman Key Exchange with Authentication D.1.1.1. 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 KeyShare extension to send temporary Diffie-Hellman parameters.
temporary Diffie-Hellman parameters. The signature in the The signature in the certificate verify message (if present) covers
certificate verify message (if present) covers the entire handshake the entire handshake up to that point and thus attests the
up to that point and thus attests the certificate holder's desire to certificate holder's desire to use the the ephemeral DHE keys.
use the the ephemeral DHE keys.
Peers SHOULD validate each other's public key Y (dh_Ys offered by the Peers SHOULD validate each other's public key Y (dh_Ys offered by the
server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
This simple check ensures that the remote peer is properly behaved This simple check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup. and isn't forcing the local system into a small subgroup.
Additionally, using a fresh key for each handshake provides Perfect Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE cipher suites. handshake when using DHE cipher suites.
D.1.2. Version Rollback Attacks D.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0, Because TLS includes substantial improvements over SSL Version 2.0,
skipping to change at page 104, line 31 skipping to change at page 102, line 22
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 [RFC7627]) Alfredo Pironti (co-author of [RFC7627])
INRIA INRIA
alfredo.pironti@inria.fr alfredo.pironti@inria.fr
Andrei Popov
Microsoft
andrei.popov@microsoft.com
Marsh Ray (co-author of [RFC7627]) 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
 End of changes. 148 change blocks. 
463 lines changed or deleted 418 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/