draft-ietf-tls-tls13-26.txt   draft-ietf-tls-tls13-27.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246, 6961 (if March 04, 2018 Obsoletes: 5077, 5246, 6961 (if March 18, 2018
approved) approved)
Updates: 4492, 5705, 6066 (if approved) Updates: 4492, 5705, 6066 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 5, 2018 Expires: September 19, 2018
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-26 draft-ietf-tls-tls13-27
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. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping, over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. tampering, and message forgery.
This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs
5077, 5246, and 6961. This document also specifies new requirements
for TLS 1.2 implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2018. This Internet-Draft will expire on September 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 24 skipping to change at page 2, line 28
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6
1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 15 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 16
1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 17 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 17
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21
2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28
3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 39 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 45
4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 48 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 49
4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49
4.2.6. Post-Handshake Client Authentication . . . . . . . . 50 4.2.6. Post-Handshake Client Authentication . . . . . . . . 50
4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 50 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 51
4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52
4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55
4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56
4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 58 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 59
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 64 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 64
4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65
4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66
4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71
4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73
4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 75 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 74
4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75
4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75
4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 78 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 77
4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82
5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84
5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85
5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86
6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86
6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88
6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 92 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 92
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92
7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 95 7.2. Updating Traffic Secrets . . . . . . . . . . . . . . . . 95
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 96 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 96
7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 96 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 97
7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 97 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 97
7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 97 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 97
7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 98 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 98
8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98
8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 100 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 100
8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 100 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 100
8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 103 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 103
9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 103 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 103
9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 103 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 103
9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 104 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 104
10. Security Considerations . . . . . . . . . . . . . . . . . . . 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 105
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.1. Normative References . . . . . . . . . . . . . . . . . . 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 107
12.2. Informative References . . . . . . . . . . . . . . . . . 110 12.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 118 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 118
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix B. Protocol Data Structures and Constant Values . . . . 119 Appendix B. Protocol Data Structures and Constant Values . . . . 119
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128
skipping to change at page 4, line 16 skipping to change at page 4, line 19
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix B. Protocol Data Structures and Constant Values . . . . 119 Appendix B. Protocol Data Structures and Constant Values . . . . 119
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128
B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129
B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 129 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 130
B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131
C.1. Random Number Generation and Seeding . . . . . . . . . . 131 C.1. Random Number Generation and Seeding . . . . . . . . . . 131
C.2. Certificates and Authentication . . . . . . . . . . . . . 132 C.2. Certificates and Authentication . . . . . . . . . . . . . 132
C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132
C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 133 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 133
C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 134 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 134
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 134 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 134
D.1. Negotiating with an older server . . . . . . . . . . . . 135 D.1. Negotiating with an older server . . . . . . . . . . . . 135
D.2. Negotiating with an older client . . . . . . . . . . . . 136 D.2. Negotiating with an older client . . . . . . . . . . . . 136
skipping to change at page 5, line 15 skipping to change at page 5, line 15
1. Introduction 1. Introduction
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
managed in GitHub, but any substantive change should be discussed on managed in GitHub, but any substantive change should be discussed on
the TLS mailing list. the TLS mailing list.
The primary goal of TLS is to provide a secure channel between two The primary goal of TLS is to provide a secure channel between two
communicating peers. Specifically, the channel should provide the communicating peers; the only requirement from the underlying
following properties: transport is a reliable, in-order, data stream. Specifically, the
secure channel should provide the following properties:
- Authentication: The server side of the channel is always - Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated. authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA Authentication can happen via asymmetric cryptography (e.g., RSA
[RSA], ECDSA [ECDSA], EdDSA [RFC8032]) or a pre-shared key (PSK). [RSA], ECDSA [ECDSA], EdDSA [RFC8032]) or a pre-shared key (PSK).
- Confidentiality: Data sent over the channel after establishment is - Confidentiality: Data sent over the channel after establishment is
only visible to the endpoints. TLS does not hide the length of only visible to the endpoints. TLS does not hide the length of
the data it transmits, though endpoints are able to pad TLS the data it transmits, though endpoints are able to pad TLS
records in order to obscure lengths and improve protection against records in order to obscure lengths and improve protection against
skipping to change at page 6, line 23 skipping to change at page 6, line 23
compatible with previous versions, all versions of TLS incorporate a compatible with previous versions, all versions of TLS incorporate a
versioning mechanism which allows clients and servers to versioning mechanism which allows clients and servers to
interoperably negotiate a common version if one is supported by both interoperably negotiate a common version if one is supported by both
peers. peers.
This document supersedes and obsoletes previous versions of TLS This document supersedes and obsoletes previous versions of TLS
including version 1.2 [RFC5246]. It also obsoletes the TLS ticket including version 1.2 [RFC5246]. It also obsoletes the TLS ticket
mechanism defined in [RFC5077] and replaces it with the mechanism mechanism defined in [RFC5077] and replaces it with the mechanism
defined in Section 2.2. Section 4.2.7 updates [RFC4492] by modifying defined in Section 2.2. Section 4.2.7 updates [RFC4492] by modifying
the protocol attributes used to negotiate Elliptic Curves. Because the protocol attributes used to negotiate Elliptic Curves. Because
TLS 1.3 changes the way keys are derived it updates [RFC5705] as TLS 1.3 changes the way keys are derived, it updates [RFC5705] as
described in Section 7.5 it also changes how OCSP messages are described in Section 7.5. It also changes how OCSP messages are
carried and therefore updates [RFC6066] and obsoletes [RFC6961] as carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
described in section Section 4.4.2.1. described in section Section 4.4.2.1.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are used: The following terms are used:
client: The endpoint initiating the TLS connection. client: The endpoint initiating the TLS connection.
connection: A transport-layer connection between two endpoints. connection: A transport-layer connection between two endpoints.
endpoint: Either the client or server of the connection. endpoint: Either the client or server of the connection.
handshake: An initial negotiation between client and server that handshake: An initial negotiation between client and server that
establishes the parameters of their subsequent interactions. establishes the parameters of their subsequent interactions within
TLS.
peer: An endpoint. When discussing a particular endpoint, "peer" peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is not the primary subject of discussion. refers to the endpoint that is not the primary subject of discussion.
receiver: An endpoint that is receiving records. receiver: An endpoint that is receiving records.
sender: An endpoint that is transmitting records. sender: An endpoint that is transmitting records.
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Change Log 1.2. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
(*) indicates changes to the wire protocol which may require (*) indicates changes to the wire protocol which may require
implementations to update. implementations to update.
draft-26 - Clarify that you can't negotiate pre-TLS 1.3 with draft-26
supported_versions.
draft-25 - Add the header to additional data (*) - Clarify that you can't negotiate pre-TLS 1.3 with
supported_versions.
draft-25
- Add the header to additional data (*)
- Minor clarifications. - Minor clarifications.
- IANA cleanup. - IANA cleanup.
draft-24 draft-24
- Require that CH2 have version 0303 (*) - Require that CH2 have version 0303 (*)
- Some clarifications - Some clarifications
draft-23 - Renumber key_share (*) draft-23
- Renumber key_share (*)
- Add a new extension and new code points to allow negotiating PSS - Add a new extension and new code points to allow negotiating PSS
separately for certificates and CertificateVerify (*) separately for certificates and CertificateVerify (*)
- Slightly restrict when CCS must be accepted to make implementation - Slightly restrict when CCS must be accepted to make implementation
easier. easier.
- Document protocol invariants - Document protocol invariants
- Add some text on the security of static RSA. - Add some text on the security of static RSA.
draft-22 - Implement changes for improved middlebox penetration (*) draft-22
- Implement changes for improved middlebox penetration (*)
- Move server_certificate_type to encrypted extensions (*) - Move server_certificate_type to encrypted extensions (*)
- Allow resumption with a different SNI (*) - Allow resumption with a different SNI (*)
- Padding extension can change on HRR (*) - Padding extension can change on HRR (*)
- Allow an empty ticket_nonce (*) - Allow an empty ticket_nonce (*)
- Remove requirement to immediately respond to close_notify with - Remove requirement to immediately respond to close_notify with
close_notify (allowing half-close) close_notify (allowing half-close)
draft-21
- Add a per-ticket nonce so that each ticket is associated with a - Add a per-ticket nonce so that each ticket is associated with a
different PSK (*). different PSK (*).
- Clarify that clients should send alerts with the handshake key if - Clarify that clients should send alerts with the handshake key if
possible. possible.
- Update state machine to show rekeying events - Update state machine to show rekeying events
- Add discussion of 0-RTT and replay. Recommend that - Add discussion of 0-RTT and replay. Recommend that
implementations implement some anti-replay mechanism. implementations implement some anti-replay mechanism.
skipping to change at page 14, line 5 skipping to change at page 14, line 12
- Change HKDF labeling to include protocol version and value - Change HKDF labeling to include protocol version and value
lengths. lengths.
- Shift the final decision to abort a handshake due to incompatible - Shift the final decision to abort a handshake due to incompatible
certificates to the client rather than having servers abort early. certificates to the client rather than having servers abort early.
- Deprecate SHA-1 with signatures. - Deprecate SHA-1 with signatures.
- Add MTI algorithms. - Add MTI algorithms.
draft-08
- Remove support for weak and lesser used named curves. - Remove support for weak and lesser used named curves.
- Remove support for MD5 and SHA-224 hashes with signatures. - Remove support for MD5 and SHA-224 hashes with signatures.
- Update lists of available AEAD cipher suites and error alerts. - Update lists of available AEAD cipher suites and error alerts.
- Reduce maximum permitted record expansion for AEAD from 2048 to - Reduce maximum permitted record expansion for AEAD from 2048 to
256 octets. 256 octets.
- Require digital signatures even when a previous configuration is - Require digital signatures even when a previous configuration is
skipping to change at page 16, line 34 skipping to change at page 16, line 40
enjoy confidentiality protection from active attackers. enjoy confidentiality protection from active attackers.
- The key derivation functions have been re-designed. The new - The key derivation functions have been re-designed. The new
design allows easier analysis by cryptographers due to their design allows easier analysis by cryptographers due to their
improved key separation properties. The HMAC-based Extract-and- improved key separation properties. The HMAC-based Extract-and-
Expand Key Derivation Function (HKDF) is used as an underlying Expand Key Derivation Function (HKDF) is used as an underlying
primitive. primitive.
- The handshake state machine has been significantly restructured to - The handshake state machine has been significantly restructured to
be more consistent and to remove superfluous messages such as be more consistent and to remove superfluous messages such as
ChangeCipherSpec. ChangeCipherSpec (except when needed for middlebox compatibility).
- Elliptic curve algorithms are now in the base spec and includes - Elliptic curve algorithms are now in the base spec and new
new signature algorithms, such as ed25519 and ed448. TLS 1.3 signature algorithms, such as ed25519 and ed448, are included.
removed point format negotiation in favor of a single point format TLS 1.3 removed point format negotiation in favor of a single
for each curve. point format for each curve.
- Other cryptographic improvements including the removal of - Other cryptographic improvements including the removal of
compression and custom DHE groups, changing the RSA padding to use compression and custom DHE groups, changing the RSA padding to use
PSS, and the removal of DSA. RSASSA-PSS, and the removal of DSA.
- The TLS 1.2 version negotiation mechanism has been deprecated in - The TLS 1.2 version negotiation mechanism has been deprecated in
favor of a version list in an extension. This increases favor of a version list in an extension. This increases
compatibility with servers which incorrectly implemented version compatibility with existing servers that incorrectly implemented
negotiation. version negotiation.
- Session resumption with and without server-side state as well as - Session resumption with and without server-side state as well as
the PSK-based ciphersuites of earlier TLS versions have been the PSK-based ciphersuites of earlier TLS versions have been
replaced by a single new PSK exchange. replaced by a single new PSK exchange.
- Updated references to point to the updated versions of RFCs, as - Updated references to point to the updated versions of RFCs, as
appropriate (e.g., RFC 5280 rather than RFC 3280). appropriate (e.g., RFC 5280 rather than RFC 3280).
1.4. Updates Affecting TLS 1.2 1.4. Updates Affecting TLS 1.2
This document defines several changes that optionally affect This document defines several changes that optionally affect
implementations of TLS 1.2: implementations of TLS 1.2, including those which do not also support
TLS 1.3:
- A version downgrade protection mechanism is described in - A version downgrade protection mechanism is described in
Section 4.1.3. Section 4.1.3.
- RSASSA-PSS signature schemes are defined in Section 4.2.3. - RSASSA-PSS signature schemes are defined in Section 4.2.3.
- The "supported_versions" ClientHello extension can be used to - The "supported_versions" ClientHello extension can be used to
negotiate the version of TLS to use, in preference to the negotiate the version of TLS to use, in preference to the
legacy_version field of the ClientHello. legacy_version field of the ClientHello.
An implementation of TLS 1.3 that also supports TLS 1.2 might need to - The "signature_algorithms_cert" extension allows a client to
include changes to support these changes even when TLS 1.3 is not in indicate which signature algorithms it can validate in X.509
use. See the referenced sections for more details. certificates
Additionally, this document clarifies some compliance requirements Additionally, this document clarifies some compliance requirements
for earlier versions of TLS; see Section 9.3. for earlier versions of TLS; see Section 9.3.
2. Protocol Overview 2. Protocol Overview
The cryptographic parameters used by the secure channel are produced The cryptographic parameters used by the secure channel are produced
by the TLS handshake protocol. This sub-protocol of TLS is used by by the TLS handshake protocol. This sub-protocol of TLS is used by
the client and server when first communicating with each other. The the client and server when first communicating with each other. The
handshake protocol allows peers to negotiate a protocol version, handshake protocol allows peers to negotiate a protocol version,
skipping to change at page 19, line 14 skipping to change at page 19, line 22
- Authentication: Authenticate the server (and optionally the - Authentication: Authenticate the server (and optionally the
client) and provide key confirmation and handshake integrity. client) and provide key confirmation and handshake integrity.
In the Key Exchange phase, the client sends the ClientHello In the Key Exchange phase, the client sends the ClientHello
(Section 4.1.2) message, which contains a random nonce (Section 4.1.2) message, which contains a random nonce
(ClientHello.random); its offered protocol versions; a list of (ClientHello.random); its offered protocol versions; a list of
symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key
shares (in the "key_share" extension Section 4.2.8), a set of pre- shares (in the "key_share" extension Section 4.2.8), a set of pre-
shared key labels (in the "pre_shared_key" extension Section 4.2.11) shared key labels (in the "pre_shared_key" extension Section 4.2.11)
or both; and potentially additional extensions. or both; and potentially additional extensions. Additional fields
and/or messages may also be present for middlebox compatibility.
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
its own ServerHello (Section 4.1.3), which indicates the negotiated its own ServerHello (Section 4.1.3), which indicates the negotiated
connection parameters. The combination of the ClientHello and the connection parameters. The combination of the ClientHello and the
ServerHello determines the shared keys. If (EC)DHE key establishment ServerHello determines the shared keys. If (EC)DHE key establishment
is in use, then the ServerHello contains a "key_share" extension with is in use, then the ServerHello contains a "key_share" extension with
the server's ephemeral Diffie-Hellman share which MUST be in the same the server's ephemeral Diffie-Hellman share; the server's share MUST
group as one of the client's shares. If PSK key establishment is in be in the same group as one of the client's shares. If PSK key
use, then the ServerHello contains a "pre_shared_key" extension establishment is in use, then the ServerHello contains a
indicating which of the client's offered PSKs was selected. Note "pre_shared_key" extension indicating which of the client's offered
that implementations can use (EC)DHE and PSK together, in which case PSKs was selected. Note that implementations can use (EC)DHE and PSK
both extensions will be supplied. together, in which case both extensions will be supplied.
The server then sends two messages to establish the Server The server then sends two messages to establish the Server
Parameters: Parameters:
EncryptedExtensions: responses to ClientHello extensions that are EncryptedExtensions: responses to ClientHello extensions that are
not required to determine the cryptographic parameters, other than not required to determine the cryptographic parameters, other than
those that are specific to individual certificates. those that are specific to individual certificates.
[Section 4.3.1] [Section 4.3.1]
CertificateRequest: if certificate-based client authentication is CertificateRequest: if certificate-based client authentication is
desired, the desired parameters for that certificate. This desired, the desired parameters for that certificate. This
message is omitted if client authentication is not desired. message is omitted if client authentication is not desired.
[Section 4.3.2] [Section 4.3.2]
Finally, the client and server exchange Authentication messages. TLS Finally, the client and server exchange Authentication messages. TLS
uses the same set of messages every time that authentication is uses the same set of messages every time that certificate-based
needed. Specifically: authentication is needed. (PSK-based authentication happens as a
side effect of key exchange.) Specifically:
Certificate: the certificate of the endpoint and any per-certificate Certificate: the certificate of the endpoint and any per-certificate
extensions. This message is omitted by the server if not extensions. This message is omitted by the server if not
authenticating with a certificate and by the client if the server authenticating with a certificate and by the client if the server
did not send CertificateRequest (thus indicating that the client did not send CertificateRequest (thus indicating that the client
should not authenticate with a certificate). Note that if raw should not authenticate with a certificate). Note that if raw
public keys [RFC7250] or the cached information extension public keys [RFC7250] or the cached information extension
[RFC7924] are in use, then this message will not contain a [RFC7924] are in use, then this message will not contain a
certificate but rather some other value corresponding to the certificate but rather some other value corresponding to the
server's long-term key. [Section 4.4.2] server's long-term key. [Section 4.4.2]
skipping to change at page 20, line 25 skipping to change at page 20, line 35
authenticates the handshake. [Section 4.4.4] authenticates the handshake. [Section 4.4.4]
Upon receiving the server's messages, the client responds with its Upon receiving the server's messages, the client responds with its
Authentication messages, namely Certificate and CertificateVerify (if Authentication messages, namely Certificate and CertificateVerify (if
requested), and Finished. requested), and Finished.
At this point, the handshake is complete, and the client and server At this point, the handshake is complete, and the client and server
derive the keying material required by the record layer to exchange derive the keying material required by the record layer to exchange
application-layer data protected through authenticated encryption. application-layer data protected through authenticated encryption.
Application data MUST NOT be sent prior to sending the Finished Application data MUST NOT be sent prior to sending the Finished
message and until the record layer starts using encryption keys. message, except as specified in [Section 2.3]. Note that while the
Note that while the server may send application data prior to server may send application data prior to receiving the client's
receiving the client's Authentication messages, any data sent at that Authentication messages, any data sent at that point is, of course,
point is, of course, being sent to an unauthenticated peer. being sent to an unauthenticated peer.
2.1. Incorrect DHE Share 2.1. Incorrect DHE Share
If the client has not provided a sufficient "key_share" extension If the client has not provided a sufficient "key_share" extension
(e.g., it includes only DHE or ECDHE groups unacceptable to or (e.g., it includes only DHE or ECDHE groups unacceptable to or
unsupported by the server), the server corrects the mismatch with a unsupported by the server), the server corrects the mismatch with a
HelloRetryRequest and the client needs to restart the handshake with HelloRetryRequest and the client needs to restart the handshake with
an appropriate "key_share" extension, as shown in Figure 2. If no an appropriate "key_share" extension, as shown in Figure 2. If no
common cryptographic parameters can be negotiated, the server MUST common cryptographic parameters can be negotiated, the server MUST
abort the handshake with an appropriate alert. abort the handshake with an appropriate alert.
Client Server Client Server
ClientHello ClientHello
+ key_share --------> + key_share -------->
<-------- HelloRetryRequest HelloRetryRequest
+ key_share <-------- + key_share
ClientHello ClientHello
+ key_share --------> + key_share -------->
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 2: Message flow for a full handshake with mismatched Figure 2: Message flow for a full handshake with mismatched
parameters parameters
Note: The handshake transcript includes the initial ClientHello/ Note: The handshake transcript incorporates the initial ClientHello/
HelloRetryRequest exchange; it is not reset with the new ClientHello. HelloRetryRequest exchange; it is not reset with the new ClientHello.
TLS also allows several optimized variants of the basic handshake, as TLS also allows several optimized variants of the basic handshake, as
described in the following sections. described in the following sections.
2.2. Resumption and Pre-Shared Key (PSK) 2.2. Resumption and Pre-Shared Key (PSK)
Although TLS PSKs can be established out of band, PSKs can also be Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then reused ("session established in a previous connection and then used to establish a new
resumption"). Once a handshake has completed, the server can send to connection ("session resumption" or "resuming" with a PSK). Once a
the client a PSK identity that corresponds to a unique key derived handshake has completed, the server can send to the client a PSK
from the initial handshake (see Section 4.6.1). The client can then identity that corresponds to a unique key derived from the initial
use that PSK identity in future handshakes to negotiate the use of handshake (see Section 4.6.1). The client can then use that PSK
the associated PSK. If the server accepts it, then the security identity in future handshakes to negotiate the use of the associated
context of the new connection is cryptographically tied to the PSK. If the server accepts the PSK, then the security context of the
original connection and the key derived from the initial handshake is new connection is cryptographically tied to the original connection
used to bootstrap the cryptographic state instead of a full and the key derived from the initial handshake is used to bootstrap
handshake. In TLS 1.2 and below, this functionality was provided by the cryptographic state instead of a full handshake. In TLS 1.2 and
"session IDs" and "session tickets" [RFC5077]. Both mechanisms are below, this functionality was provided by "session IDs" and "session
obsoleted in TLS 1.3. tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
PSKs can be used with (EC)DHE key exchange in order to provide PSKs can be used with (EC)DHE key exchange in order to provide
forward secrecy in combination with shared keys, or can be used forward secrecy in combination with shared keys, or can be used
alone, at the cost of losing forward secrecy for the application alone, at the cost of losing forward secrecy for the application
data. data.
Figure 3 shows a pair of handshakes in which the first establishes a Figure 3 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
skipping to change at page 23, line 18 skipping to change at page 23, line 17
When PSKs are provisioned out of band, the PSK identity and the KDF When PSKs are provisioned out of band, the PSK identity and the KDF
hash algorithm to be used with the PSK MUST also be provisioned. hash algorithm to be used with the PSK MUST also be provisioned.
Note: When using an out-of-band provisioned pre-shared secret, a Note: When using an out-of-band provisioned pre-shared secret, a
critical consideration is using sufficient entropy during the key critical consideration is using sufficient entropy during the key
generation, as discussed in [RFC4086]. Deriving a shared secret generation, as discussed in [RFC4086]. Deriving a shared secret
from a password or other low-entropy sources is not secure. A from a password or other low-entropy sources is not secure. A
low-entropy secret, or password, is subject to dictionary attacks low-entropy secret, or password, is subject to dictionary attacks
based on the PSK binder. The specified PSK authentication is not based on the PSK binder. The specified PSK authentication is not
a strong password-based authenticated key exchange even when used a strong password-based authenticated key exchange even when used
with Diffie-Hellman key establishment. with Diffie-Hellman key establishment. Specifically, it does not
prevent an attacker that can observe the handshake from performing
a brute-force attack on the password/pre-shared key.
2.3. 0-RTT Data 2.3. 0-RTT Data
When clients and servers share a PSK (either obtained externally or When clients and servers share a PSK (either obtained externally or
via a previous handshake), TLS 1.3 allows clients to send data on the via a previous handshake), TLS 1.3 allows clients to send data on the
first flight ("early data"). The client uses the PSK to authenticate first flight ("early data"). The client uses the PSK to authenticate
the server and to encrypt the early data. the server and to encrypt the early data.
As shown in Figure 4, the 0-RTT data is just added to the 1-RTT As shown in Figure 4, the 0-RTT data is just added to the 1-RTT
handshake in the first flight. The rest of the handshake uses the handshake in the first flight. The rest of the handshake uses the
same messages as with a 1-RTT handshake with PSK resumption. same messages as for a 1-RTT handshake with PSK resumption.
Client Server Client Server
ClientHello ClientHello
+ early_data + early_data
+ key_share* + key_share*
+ psk_key_exchange_modes + psk_key_exchange_modes
+ pre_shared_key + pre_shared_key
(Application Data*) --------> (Application Data*) -------->
ServerHello ServerHello
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Optional components are denoted by enclosing them in "[[ ]]" double Optional components are denoted by enclosing them in "[[ ]]" double
brackets. brackets.
Single-byte entities containing uninterpreted data are of type Single-byte entities containing uninterpreted data are of type
opaque. opaque.
A type alias T' for an existing type T is defined by: A type alias T' for an existing type T is defined by:
T T'; T T';
3.3. Vectors 3.3. Numbers
The basic numeric data type is an unsigned byte (uint8). All larger
numeric data types are formed from fixed-length series of bytes
concatenated as described in Section 3.1 and are also unsigned. The
following numeric types are predefined.
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
All values, here and elsewhere in the specification, are transmitted
in network byte (big-endian) order; the uint32 represented by the hex
bytes 01 02 03 04 is equivalent to the decimal value 16909060.
3.4. Vectors
A vector (single-dimensioned array) is a stream of homogeneous data A vector (single-dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case, the length time or left unspecified until runtime. In either case, the length
declares the number of bytes, not the number of elements, in the declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type, T', that is a fixed- vector. The syntax for specifying a new type, T', that is a fixed-
length vector of type T is length vector of type T is
T T'[n]; T T'[n];
skipping to change at page 26, line 40 skipping to change at page 27, line 8
in the byte stream. The length will be in the form of a number in the byte stream. The length will be in the form of a number
consuming as many bytes as required to hold the vector's specified consuming as many bytes as required to hold the vector's specified
maximum (ceiling) length. A variable-length vector with an actual maximum (ceiling) length. A variable-length vector with an actual
length field of zero is referred to as an empty vector. length field of zero is referred to as an empty vector.
T T'<floor..ceiling>; T T'<floor..ceiling>;
In the following example, mandatory is a vector that must contain In the following example, mandatory is a vector that must contain
between 300 and 400 bytes of type opaque. It can never be empty. between 300 and 400 bytes of type opaque. It can never be empty.
The actual length field consumes two bytes, a uint16, which is The actual length field consumes two bytes, a uint16, which is
sufficient to represent the value 400 (see Section 3.4). Similarly, sufficient to represent the value 400 (see Section 3.3). Similarly,
longer can represent up to 800 bytes of data, or 400 uint16 elements, longer can represent up to 800 bytes of data, or 400 uint16 elements,
and it may be empty. Its encoding will include a two-byte actual and it may be empty. Its encoding will include a two-byte actual
length field prepended to the vector. The length of an encoded length field prepended to the vector. The length of an encoded
vector must be an exact multiple of the length of a single element vector must be an exact multiple of the length of a single element
(e.g., a 17-byte vector of uint16 would be illegal). (e.g., a 17-byte vector of uint16 would be illegal).
opaque mandatory<300..400>; opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */ /* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>; uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */ /* zero to 400 16-bit unsigned integers */
3.4. Numbers
The basic numeric data type is an unsigned byte (uint8). All larger
numeric data types are formed from fixed-length series of bytes
concatenated as described in Section 3.1 and are also unsigned. The
following numeric types are predefined.
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
All values, here and elsewhere in the specification, are stored in
network byte (big-endian) order; the uint32 represented by the hex
bytes 01 02 03 04 is equivalent to the decimal value 16909060.
3.5. Enumerateds 3.5. Enumerateds
An additional sparse data type is available called enum. Each An additional sparse data type is available called enum or
definition is a different type. Only enumerateds of the same type enumerated. Each definition is a different type. Only enumerateds
may be assigned or compared. Every element of an enumerated must be of the same type may be assigned or compared. Every element of an
assigned a value, as demonstrated in the following example. Since enumerated must be assigned a value, as demonstrated in the following
the elements of the enumerated are not ordered, they can be assigned example. Since the elements of the enumerated are not ordered, they
any unique value, in any order. can be assigned any unique value, in any order.
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Future extensions or additions to the protocol may define new values. Future extensions or additions to the protocol may define new values.
Implementations need to be able to parse and ignore unknown values Implementations need to be able to parse and ignore unknown values
unless the definition of the field states otherwise. unless the definition of the field states otherwise.
An enumerated occupies as much space in the byte stream as would its An enumerated occupies as much space in the byte stream as would its
maximal defined ordinal value. The following definition would cause maximal defined ordinal value. The following definition would cause
one byte to be used to carry fields of type Color. one byte to be used to carry fields of type Color.
skipping to change at page 32, line 32 skipping to change at page 32, line 32
define how to use them together. define how to use them together.
If the server is unable to negotiate a supported set of parameters If the server is unable to negotiate a supported set of parameters
(i.e., there is no overlap between the client and server parameters), (i.e., there is no overlap between the client and server parameters),
it MUST abort the handshake with either a "handshake_failure" or it MUST abort the handshake with either a "handshake_failure" or
"insufficient_security" fatal alert (see Section 6). "insufficient_security" fatal alert (see Section 6).
4.1.2. Client Hello 4.1.2. Client Hello
When a client first connects to a server, it is REQUIRED to send the 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 ClientHello as its first TLS message. The client will also send a
ClientHello when the server has responded to its ClientHello with a ClientHello when the server has responded to its ClientHello with a
HelloRetryRequest. In that case, the client MUST send the same HelloRetryRequest. In that case, the client MUST send the same
ClientHello (without modification) except: ClientHello without modification, except:
- If a "key_share" extension was supplied in the HelloRetryRequest, - If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group. KeyShareEntry from the indicated group.
- Removing the "early_data" extension (Section 4.2.10) if one was - Removing the "early_data" extension (Section 4.2.10) if one was
present. Early data is not permitted after HelloRetryRequest. present. Early data is not permitted after HelloRetryRequest.
- Including a "cookie" extension if one was provided in the - Including a "cookie" extension if one was provided in the
HelloRetryRequest. HelloRetryRequest.
- Updating the "pre_shared_key" extension if present by recomputing - Updating the "pre_shared_key" extension if present by recomputing
the "obfuscated_ticket_age" and binder values and (optionally) the "obfuscated_ticket_age" and binder values and (optionally)
removing any PSKs which are incompatible with the server's removing any PSKs which are incompatible with the server's
indicated cipher suite. indicated cipher suite.
- Optionally adding, removing, or changing the length of the - Optionally adding, removing, or changing the length of the
"padding" extension [RFC7685]. "padding" extension [RFC7685].
- Other modifications that may be allowed by an extension defined in
the future and present in the HelloRetryRequest.
Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
1.3 and receives a ClientHello at any other time, it MUST terminate 1.3 and receives a ClientHello at any other time, it MUST terminate
the connection with an "unexpected_message" alert. the connection with an "unexpected_message" alert.
If a server established a TLS connection with a previous version of If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version. In particular, it MUST NOT retain the previous protocol version. In particular, it MUST NOT
negotiate TLS 1.3. negotiate TLS 1.3.
Structure of this message: Structure of this message:
skipping to change at page 34, line 25 skipping to change at page 34, line 28
contains cipher suites that the server does not recognize, support contains cipher suites that the server does not recognize, support
or wish to use, the server MUST ignore those cipher suites and or wish to use, the server MUST ignore those cipher suites and
process the remaining ones as usual. Values are defined in process the remaining ones as usual. Values are defined in
Appendix B.4. If the client is attempting a PSK key Appendix B.4. If the client is attempting a PSK key
establishment, it SHOULD advertise at least one cipher suite establishment, it SHOULD advertise at least one cipher suite
indicating a Hash associated with the PSK. indicating a Hash associated with the PSK.
legacy_compression_methods Versions of TLS before 1.3 supported legacy_compression_methods Versions of TLS before 1.3 supported
compression with the list of supported compression methods being compression with the list of supported compression methods being
sent in this field. For every TLS 1.3 ClientHello, this vector sent in this field. For every TLS 1.3 ClientHello, this vector
MUST contain exactly one byte set to zero, which corresponds to MUST contain exactly one byte, set to zero, which corresponds to
the "null" compression method in prior versions of TLS. If a TLS the "null" compression method in prior versions of TLS. If a TLS
1.3 ClientHello is received with any other value in this field, 1.3 ClientHello is received with any other value in this field,
the server MUST abort the handshake with an "illegal_parameter" the server MUST abort the handshake with an "illegal_parameter"
alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior
ClientHellos which contain other compression methods and MUST ClientHellos which contain other compression methods and (if
follow the procedures for the appropriate prior version of TLS. negotiating such a prior version) MUST follow the procedures for
TLS 1.3 ClientHellos are identified as having a legacy_version of the appropriate prior version of TLS. TLS 1.3 ClientHellos are
0x0303 and a supported_versions extension present with 0x0304 as identified as having a legacy_version of 0x0303 and a
the highest version indicated therein. supported_versions extension present with 0x0304 as the highest
version indicated therein.
extensions Clients request extended functionality from servers by extensions Clients request extended functionality from servers by
sending data in the extensions field. The actual "Extension" sending data in the extensions field. The actual "Extension"
format is defined in Section 4.2. In TLS 1.3, use of certain format is defined in Section 4.2. In TLS 1.3, use of certain
extensions is mandatory, as functionality is moved into extensions extensions is mandatory, as functionality is moved into extensions
to preserve ClientHello compatibility with previous versions of to preserve ClientHello compatibility with previous versions of
TLS. Servers MUST ignore unrecognized extensions. TLS. Servers MUST ignore unrecognized extensions.
All versions of TLS allow an extensions field to optionally follow All versions of TLS allow an extensions field to optionally follow
the compression_methods field. TLS 1.3 ClientHello messages always the compression_methods field. TLS 1.3 ClientHello messages always
skipping to change at page 36, line 12 skipping to change at page 36, line 16
Appendix C for additional information. The last eight bytes MUST Appendix C for additional information. The last eight bytes MUST
be overwritten as described below if negotiating TLS 1.2 or TLS be overwritten as described below if negotiating TLS 1.2 or TLS
1.1, but the remaining bytes MUST be random. This structure is 1.1, but the remaining bytes MUST be random. This structure is
generated by the server and MUST be generated independently of the generated by the server and MUST be generated independently of the
ClientHello.random. ClientHello.random.
legacy_session_id_echo The contents of the client's legacy_session_id_echo The contents of the client's
legacy_session_id field. Note that this field is echoed even if legacy_session_id field. Note that this field is echoed even if
the client's value corresponded to a cached pre-TLS 1.3 session the client's value corresponded to a cached pre-TLS 1.3 session
which the server has chosen not to resume. A client which which the server has chosen not to resume. A client which
receives a legacy_session_id field that does not match what it receives a legacy_session_id_echo field that does not match what
sent in the ClientHello MUST abort the handshake with an it sent in the ClientHello MUST abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
cipher_suite The single cipher suite selected by the server from the cipher_suite The single cipher suite selected by the server from the
list in ClientHello.cipher_suites. A client which receives a list in ClientHello.cipher_suites. A client which receives a
cipher suite that was not offered MUST abort the handshake with an cipher suite that was not offered MUST abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
legacy_compression_method A single byte which MUST have the value 0. legacy_compression_method A single byte which MUST have the value 0.
extensions A list of extensions. The ServerHello MUST only include extensions A list of extensions. The ServerHello MUST only include
extensions which are required to establish the cryptographic extensions which are required to establish the cryptographic
context and negotiate the protocol version. All TLS 1.3 context and negotiate the protocol version. All TLS 1.3
ServerHello messages MUST contain the "supported_versions" ServerHello messages MUST contain the "supported_versions"
extension. Current ServerHello messages contain either the extension. Current ServerHello messages additionally contain
"pre_shared_key" or "key_share" extensions, or both when using a either the "pre_shared_key" or "key_share" extensions, or both
PSK with (EC)DHE key establishment. The remaining extensions are when using a PSK with (EC)DHE key establishment. Other extensions
sent separately in the EncryptedExtensions message. are sent separately in the EncryptedExtensions message.
For backward compatibility reasons with middleboxes (see For reasons of backward compatibility with middleboxes (see
Appendix D.4) the HelloRetryRequest message uses the same structure Appendix D.4) the HelloRetryRequest message uses the same structure
as the ServerHello, but with Random set to the special value of the as the ServerHello, but with Random set to the special value of the
SHA-256 of "HelloRetryRequest": SHA-256 of "HelloRetryRequest":
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
Upon receiving a message with type server_hello, implementations MUST Upon receiving a message with type server_hello, implementations MUST
first examine the Random value and if it matches this value, process first examine the Random value and if it matches this value, process
it as described in Section 4.1.4). it as described in Section 4.1.4).
skipping to change at page 38, line 12 skipping to change at page 38, line 15
HelloRetryRequest throughout this document as if it were a distinct HelloRetryRequest throughout this document as if it were a distinct
message. message.
The server's extensions MUST contain "supported_versions" and The server's extensions MUST contain "supported_versions" and
otherwise the server SHOULD send only the extensions necessary for otherwise the server SHOULD send only the extensions necessary for
the client to generate a correct ClientHello pair. As with the client to generate a correct ClientHello pair. As with
ServerHello, a HelloRetryRequest MUST NOT contain any extensions that ServerHello, a HelloRetryRequest MUST NOT contain any extensions that
were not first offered by the client in its ClientHello, with the were not first offered by the client in its ClientHello, with the
exception of optionally the "cookie" (see Section 4.2.2) extension. exception of optionally the "cookie" (see Section 4.2.2) extension.
Upon receipt of a HelloRetryRequest, the client MUST perform the Upon receipt of a HelloRetryRequest, the client MUST check the
checks specified in Section 4.1.3 and then process the extensions, legacy_version, legacy_session_id_echo, cipher_suite, and
starting with determining the version using "supported_versions". legacy_compression_method as specified in Section 4.1.3 and then
Clients MUST abort the handshake with an "illegal_parameter" alert if process the extensions, starting with determining the version using
the HelloRetryRequest would not result in any change in the "supported_versions". Clients MUST abort the handshake with an
ClientHello. If a client receives a second HelloRetryRequest in the "illegal_parameter" alert if the HelloRetryRequest would not result
same connection (i.e., where the ClientHello was itself in response in any change in the ClientHello. If a client receives a second
to a HelloRetryRequest), it MUST abort the handshake with an HelloRetryRequest in the same connection (i.e., where the ClientHello
"unexpected_message" alert. was itself in response to a HelloRetryRequest), it MUST abort the
handshake with an "unexpected_message" alert.
Otherwise, the client MUST process all extensions in the Otherwise, the client MUST process all extensions in the
HelloRetryRequest and send a second updated ClientHello. The HelloRetryRequest and send a second updated ClientHello. The
HelloRetryRequest extensions defined in this specification are: HelloRetryRequest extensions defined in this specification are:
- supported_versions (see Section 4.2.1) - supported_versions (see Section 4.2.1)
- cookie (see Section 4.2.2) - cookie (see Section 4.2.2)
- key_share (see Section 4.2.8) - key_share (see Section 4.2.8)
skipping to change at page 42, line 23 skipping to change at page 42, line 23
parameters are those negotiated in the previous handshake; mismatches parameters are those negotiated in the previous handshake; mismatches
may require rejecting 0-RTT (see Section 4.2.10). may require rejecting 0-RTT (see Section 4.2.10).
There are subtle (and not so subtle) interactions that may occur in There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may this protocol between new features and existing features which may
result in a significant reduction in overall security. The following result in a significant reduction in overall security. The following
considerations should be taken into account when designing new considerations should be taken into account when designing new
extensions: extensions:
- Some cases where a server does not agree to an extension are error - Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular conditions (e.g., the handshake cannot continue), and some are
features. In general, error alerts should be used for the former simply refusals to support particular features. In general, error
and a field in the server extension response for the latter. alerts should be used for the former and a field in the server
extension response for the latter.
- Extensions should, as far as possible, be designed to prevent any - Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a followed regardless of whether the feature is believed to cause a
security problem. Often the fact that the extension fields are security problem. Often the fact that the extension fields are
included in the inputs to the Finished message hashes will be included in the inputs to the Finished message hashes will be
sufficient, but extreme care is needed when the extension changes sufficient, but extreme care is needed when the extension changes
the meaning of messages sent in the handshake phase. Designers the meaning of messages sent in the handshake phase. Designers
and implementors should be aware of the fact that until the and implementors should be aware of the fact that until the
skipping to change at page 43, line 6 skipping to change at page 43, line 9
case server_hello: /* and HelloRetryRequest */ case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version; ProtocolVersion selected_version;
}; };
} SupportedVersions; } SupportedVersions;
The "supported_versions" extension is used by the client to indicate The "supported_versions" extension is used by the client to indicate
which versions of TLS it supports and by the server to indicate which which versions of TLS it supports and by the server to indicate which
version it is using. The extension contains a list of supported version it is using. The extension contains a list of supported
versions in preference order, with the most preferred version first. versions in preference order, with the most preferred version first.
Implementations of this specification MUST send this extension Implementations of this specification MUST send this extension in the
containing all versions of TLS which they are prepared to negotiate ClientHello containing all versions of TLS which they are prepared to
(for this specification, that means minimally 0x0304, but if previous negotiate (for this specification, that means minimally 0x0304, but
versions of TLS are allowed to be negotiated, they MUST be present as if previous versions of TLS are allowed to be negotiated, they MUST
well). be present as well).
If this extension is not present, servers which are compliant with If this extension is not present, servers which are compliant with
this specification MUST negotiate TLS 1.2 or prior as specified in this specification, and which also support TLS 1.2, MUST negotiate
[RFC5246], even if ClientHello.legacy_version is 0x0304 or later. TLS 1.2 or prior as specified in [RFC5246], even if
Servers MAY abort the handshake upon receiving a ClientHello with ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the
legacy_version 0x0304 or later. handshake upon receiving a ClientHello with legacy_version 0x0304 or
later.
If this extension is present, servers MUST ignore the If this extension is present in the ClientHello, servers MUST NOT use
ClientHello.legacy_version value and MUST use only the the ClientHello.legacy_version value for version negotiation and MUST
"supported_versions" extension to determine client preferences. use only the "supported_versions" extension to determine client
Servers MUST only select a version of TLS present in that extension preferences. Servers MUST only select a version of TLS present in
and MUST ignore any unknown versions that are present in that that extension and MUST ignore any unknown versions that are present
extension. Note that this mechanism makes it possible to negotiate a in that extension. Note that this mechanism makes it possible to
version prior to TLS 1.2 if one side supports a sparse range. negotiate a version prior to TLS 1.2 if one side supports a sparse
Implementations of TLS 1.3 which choose to support prior versions of range. Implementations of TLS 1.3 which choose to support prior
TLS SHOULD support TLS 1.2. Servers should be prepared to receive versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to
ClientHellos that include this extension but do not include 0x0304 in receive ClientHellos that include this extension but do not include
the list of versions. 0x0304 in the list of versions.
A server which negotiates a version of TLS prior to TLS 1.3 MUST set A server which negotiates a version of TLS prior to TLS 1.3 MUST set
ServerHello.version and MUST NOT send the "supported_versions" ServerHello.version and MUST NOT send the "supported_versions"
extension. A server which negotiates TLS 1.3 MUST respond by sending extension. A server which negotiates TLS 1.3 MUST respond by sending
a "supported_versions" extension containing the selected version a "supported_versions" extension containing the selected version
value (0x0304). It MUST set the ServerHello.legacy_version field to value (0x0304). It MUST set the ServerHello.legacy_version field to
0x0303 (TLS 1.2). Clients MUST check for this extension prior to 0x0303 (TLS 1.2). Clients MUST check for this extension prior to
processing the rest of the ServerHello (although they will have to processing the rest of the ServerHello (although they will have to
parse the ServerHello in order to read the extension). If this parse the ServerHello in order to read the extension). If this
extension is present, clients MUST ignore the extension is present, clients MUST ignore the
ServerHello.legacy_version value and MUST use only the ServerHello.legacy_version value and MUST use only the
"supported_versions" extension to determine the selected version. If "supported_versions" extension to determine the selected version. If
the "supported_versions" extension contains a version not offered by the "supported_versions" extension in the ServerHello contains a
the client or contains a version prior to TLS 1.3, the client MUST version not offered by the client or contains a version prior to TLS
abort the handshake with an "illegal_parameter" alert. 1.3, the client MUST abort the handshake with an "illegal_parameter"
alert.
4.2.1.1. Draft Version Indicator 4.2.1.1. Draft Version Indicator
RFC EDITOR: PLEASE REMOVE THIS SECTION RFC EDITOR: PLEASE REMOVE THIS SECTION
While the eventual version indicator for the RFC version of TLS 1.3 While the eventual version indicator for the RFC version of TLS 1.3
will be 0x0304, implementations of draft versions of this will be 0x0304, implementations of draft versions of this
specification SHOULD instead advertise 0x7f00 | draft_version in the specification SHOULD instead advertise 0x7f00 | draft_version in the
ServerHello and HelloRetryRequest "supported_versions" extension. ServerHello and HelloRetryRequest "supported_versions" extension.
For instance, draft-17 would be encoded as the 0x7f11. This allows For instance, draft-17 would be encoded as the 0x7f11. This allows
skipping to change at page 45, line 21 skipping to change at page 45, line 31
extension, then the server MUST abort the handshake with a extension, then the server MUST abort the handshake with a
"missing_extension" alert (see Section 9.2). "missing_extension" alert (see Section 9.2).
The "signature_algorithms_cert" extension was added to allow The "signature_algorithms_cert" extension was added to allow
implementations which supported different sets of algorithms for implementations which supported different sets of algorithms for
certificates and in TLS itself to clearly signal their capabilities. certificates and in TLS itself to clearly signal their capabilities.
TLS 1.2 implementations SHOULD also process this extension. TLS 1.2 implementations SHOULD also process this extension.
Implementations which have the same policy in both cases MAY omit the Implementations which have the same policy in both cases MAY omit the
"signature_algorithms_cert" extension. "signature_algorithms_cert" extension.
The "extension_data" field of these extension contains a The "extension_data" field of these extensions contains a
SignatureSchemeList value: SignatureSchemeList value:
enum { enum {
/* RSASSA-PKCS1-v1_5 algorithms */ /* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401), rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501), rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601), rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */ /* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403), ecdsa_secp256r1_sha256(0x0403),
skipping to change at page 47, line 26 skipping to change at page 47, line 26
ECDSA algorithms Indicates a signature algorithm using ECDSA ECDSA algorithms Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure. [X690] ECDSA-Sig-Value structure.
RSASSA-PSS RSAE algorithms Indicates a signature algorithm using RSASSA-PSS RSAE algorithms Indicates a signature algorithm using
RSASSA-PSS [RFC8017] with mask generation function 1. The digest RSASSA-PSS [RFC8017] with mask generation function 1. The digest
used in the mask generation function and the digest being signed used in the mask generation function and the digest being signed
are both the corresponding hash algorithm as defined in [SHS]. are both the corresponding hash algorithm as defined in [SHS].
The length of the salt MUST be equal to the length of the digest The length of the salt MUST be equal to the length of the output
algorithm. If the public key is carried in an X.509 certificate, of the digest algorithm. If the public key is carried in an X.509
it MUST use the rsaEncryption OID [RFC5280]. certificate, it MUST use the rsaEncryption OID [RFC5280].
EdDSA algorithms Indicates a signature algorithm using EdDSA as EdDSA algorithms Indicates a signature algorithm using EdDSA as
defined in [RFC8032] or its successors. Note that these defined in [RFC8032] or its successors. Note that these
correspond to the "PureEdDSA" algorithms and not the "prehash" correspond to the "PureEdDSA" algorithms and not the "prehash"
variants. variants.
RSASSA-PSS PSS algorithms Indicates a signature algorithm using RSASSA-PSS PSS algorithms Indicates a signature algorithm using
RSASSA-PSS [RFC8017] with mask generation function 1. The digest RSASSA-PSS [RFC8017] with mask generation function 1. The digest
used in the mask generation function and the digest being signed used in the mask generation function and the digest being signed
are both the corresponding hash algorithm as defined in [SHS]. are both the corresponding hash algorithm as defined in [SHS].
The length of the salt MUST be equal to the length of the digest The length of the salt MUST be equal to the length of the digest
algorithm. If the public key is carried in an X.509 certificate, algorithm. If the public key is carried in an X.509 certificate,
it MUST use the RSASSA-PSS OID [RFC5756]. When used in it MUST use the RSASSA-PSS OID [RFC5756]. When used in
certificate signatures, the algorithm parameters MUST be DER certificate signatures, the algorithm parameters MUST be DER
encoded. If the corresponding public key's parameters present, encoded. If the corresponding public key's parameters are
then the parameters in the signature MUST be identical to those in present, then the parameters in the signature MUST be identical to
the public key. those in the public key.
Legacy algorithms Indicates algorithms which are being deprecated Legacy algorithms Indicates algorithms which are being deprecated
because they use algorithms with known weaknesses, specifically because they use algorithms with known weaknesses, specifically
SHA-1 which is used in this context with either with RSA using SHA-1 which is used in this context with either with RSA using
RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to
signatures which appear in certificates (see Section 4.4.2.2) and signatures which appear in certificates (see Section 4.4.2.2) and
are not defined for use in signed TLS handshake messages, even if are not defined for use in signed TLS handshake messages, although
they appear in the "signature_algorithms" list (this is necessary they MAY appear in "signature_algorithms" and
for backward compatibility with TLS 1.2). Endpoints SHOULD NOT "signature_algorithms_cert" for backward compatibility with TLS
negotiate these algorithms but are permitted to do so solely for 1.2, Endpoints SHOULD NOT negotiate these algorithms but are
backward compatibility. Clients offering these values MUST list permitted to do so solely for backward compatibility. Clients
them as the lowest priority (listed after all other algorithms in offering these values MUST list them as the lowest priority
SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 (listed after all other algorithms in SignatureSchemeList). TLS
signed certificate unless no valid certificate chain can be 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no
produced without it (see Section 4.4.2.2). valid certificate chain can be produced without it (see
Section 4.4.2.2).
The signatures on certificates that are self-signed or certificates The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a that are trust anchors are not validated since they begin a
certification path (see [RFC5280], Section 3.2). A certificate that certification path (see [RFC5280], Section 3.2). A certificate that
begins a certification path MAY use a signature algorithm that is not begins a certification path MAY use a signature algorithm that is not
advertised as being supported in the "signature_algorithms" advertised as being supported in the "signature_algorithms"
extension. extension.
Note that TLS 1.2 defines this extension differently. TLS 1.3 Note that TLS 1.2 defines this extension differently. TLS 1.3
implementations willing to negotiate TLS 1.2 MUST behave in implementations willing to negotiate TLS 1.2 MUST behave in
skipping to change at page 49, line 47 skipping to change at page 50, line 6
struct { struct {
opaque certificate_extension_oid<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>; opaque certificate_extension_values<0..2^16-1>;
} OIDFilter; } OIDFilter;
struct { struct {
OIDFilter filters<0..2^16-1>; OIDFilter filters<0..2^16-1>;
} OIDFilterExtension; } OIDFilterExtension;
filters A list of certificate extension OIDs [RFC5280] with their filters A list of certificate extension OIDs [RFC5280] with their
allowed values and represented in DER-encoded [X690] format. Some allowed value(s) and represented in DER-encoded [X690] format.
certificate extension OIDs allow multiple values (e.g., Extended Some certificate extension OIDs allow multiple values (e.g.,
Key Usage). If the server has included a non-empty filters list, Extended Key Usage). If the server has included a non-empty
the client certificate included in the response MUST contain all filters list, the client certificate included in the response MUST
of the specified extension OIDs that the client recognizes. For contain all of the specified extension OIDs that the client
each extension OID recognized by the client, all of the specified recognizes. For each extension OID recognized by the client, all
values MUST be present in the client certificate (but the of the specified values MUST be present in the client certificate
certificate MAY have other values as well). However, the client (but the certificate MAY have other values as well). However, the
MUST ignore and skip any unrecognized certificate extension OIDs. client MUST ignore and skip any unrecognized certificate extension
If the client ignored some of the required certificate extension OIDs. If the client ignored some of the required certificate
OIDs and supplied a certificate that does not satisfy the request, extension OIDs and supplied a certificate that does not satisfy
the server MAY at its discretion either continue the connection the request, the server MAY at its discretion either continue the
without client authentication, or abort the handshake with an connection without client authentication, or abort the handshake
"unsupported_certificate" alert. with an "unsupported_certificate" alert. Any given OID MUST NOT
appear more than once in the filters list.
PKIX RFCs define a variety of certificate extension OIDs and their PKIX RFCs define a variety of certificate extension OIDs and their
corresponding value types. Depending on the type, matching corresponding value types. Depending on the type, matching
certificate extension values are not necessarily bitwise-equal. It certificate extension values are not necessarily bitwise-equal. It
is expected that TLS implementations will rely on their PKI libraries is expected that TLS implementations will rely on their PKI libraries
to perform certificate selection using certificate extension OIDs. to perform certificate selection using certificate extension OIDs.
This document defines matching rules for two standard certificate This document defines matching rules for two standard certificate
extensions defined in [RFC5280]: extensions defined in [RFC5280]:
skipping to change at page 50, line 37 skipping to change at page 50, line 46
request when all key purpose OIDs present in the request are also request when all key purpose OIDs present in the request are also
found in the Extended Key Usage certificate extension. The found in the Extended Key Usage certificate extension. The
special anyExtendedKeyUsage OID MUST NOT be used in the request. special anyExtendedKeyUsage OID MUST NOT be used in the request.
Separate specifications may define matching rules for other Separate specifications may define matching rules for other
certificate extensions. certificate extensions.
4.2.6. Post-Handshake Client Authentication 4.2.6. Post-Handshake Client Authentication
The "post_handshake_auth" extension is used to indicate that a client The "post_handshake_auth" extension is used to indicate that a client
is willing to perform post-handshake authentication Section 4.6.2. is willing to perform post-handshake authentication (Section 4.6.2).
Servers MUST NOT send a post-handshake CertificateRequest to clients Servers MUST NOT send a post-handshake CertificateRequest to clients
which do not offer this extension. Servers MUST NOT send this which do not offer this extension. Servers MUST NOT send this
extension. extension.
struct {} PostHandshakeAuth; struct {} PostHandshakeAuth;
The "extension_data" field of the "post_handshake_auth" extension is The "extension_data" field of the "post_handshake_auth" extension is
zero length. zero length.
4.2.7. Negotiated Groups 4.2.7. Negotiated Groups
skipping to change at page 52, line 23 skipping to change at page 52, line 34
Clients MAY send an empty client_shares vector in order to request Clients MAY send an empty client_shares vector in order to request
group selection from the server at the cost of an additional round group selection from the server at the cost of an additional round
trip. (see Section 4.1.4) trip. (see Section 4.1.4)
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
group The named group for the key being exchanged. Finite Field group The named group for the key being exchanged.
Diffie-Hellman [DH] parameters are described in Section 4.2.8.1;
Elliptic Curve Diffie-Hellman parameters are described in
Section 4.2.8.2.
key_exchange Key exchange information. The contents of this field key_exchange Key exchange information. The contents of this field
are determined by the specified group and its corresponding are determined by the specified group and its corresponding
definition. definition. Finite Field Diffie-Hellman [DH] parameters are
described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman
parameters are described in Section 4.2.8.2.
In the ClientHello message, the "extension_data" field of this In the ClientHello message, the "extension_data" field of this
extension contains a "KeyShareClientHello" value: extension contains a "KeyShareClientHello" value:
struct { struct {
KeyShareEntry client_shares<0..2^16-1>; KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello; } KeyShareClientHello;
client_shares A list of offered KeyShareEntry values in descending client_shares A list of offered KeyShareEntry values in descending
order of client preference. order of client preference.
This vector MAY be empty if the client is requesting a This vector MAY be empty if the client is requesting a
HelloRetryRequest. Each KeyShareEntry value MUST correspond to a HelloRetryRequest. Each KeyShareEntry value MUST correspond to a
group offered in the "supported_groups" extension and MUST appear in group offered in the "supported_groups" extension and MUST appear in
the same order. However, the values MAY be a non-contiguous subset the same order. However, the values MAY be a non-contiguous subset
of the "supported_groups" extension and MAY omit the most preferred of the "supported_groups" extension and MAY omit the most preferred
groups. Such a situation could arise if the most preferred groups groups. Such a situation could arise if the most preferred groups
are new and unlikely to be supported in enough places to make are new and unlikely to be supported in enough places to make
pregenerating key shares for them efficient. pregenerating key shares for them efficient.
Clients can offer an arbitrary number of KeyShareEntry values, each Clients can offer as many KeyShareEntry values as the number of
representing a single set of key exchange parameters. For instance, supported groups it is offering, each representing a single set of
a client might offer shares for several elliptic curves or multiple key exchange parameters. For instance, a client might offer shares
FFDHE groups. The key_exchange values for each KeyShareEntry MUST be for several elliptic curves or multiple FFDHE groups. The
generated independently. Clients MUST NOT offer multiple key_exchange values for each KeyShareEntry MUST be generated
KeyShareEntry values for the same group. Clients MUST NOT offer any independently. Clients MUST NOT offer multiple KeyShareEntry values
KeyShareEntry values for groups not listed in the client's for the same group. Clients MUST NOT offer any KeyShareEntry values
"supported_groups" extension. Servers MAY check for violations of for groups not listed in the client's "supported_groups" extension.
these rules and abort the handshake with an "illegal_parameter" alert Servers MAY check for violations of these rules and abort the
if one is violated. handshake with an "illegal_parameter" alert if one is violated.
In a HelloRetryRequest message, the "extension_data" field of this In a HelloRetryRequest message, the "extension_data" field of this
extension contains a KeyShareHelloRetryRequest value: extension contains a KeyShareHelloRetryRequest value:
struct { struct {
NamedGroup selected_group; NamedGroup selected_group;
} KeyShareHelloRetryRequest; } KeyShareHelloRetryRequest;
selected_group The mutually supported group the server intends to selected_group The mutually supported group the server intends to
negotiate and is requesting a retried ClientHello/KeyShare for. negotiate and is requesting a retried ClientHello/KeyShare for.
skipping to change at page 54, line 30 skipping to change at page 54, line 39
Note: For a given Diffie-Hellman group, the padding results in all Note: For a given Diffie-Hellman group, the padding results in all
public keys having the same length. public keys having the same length.
Peers MUST validate each other's public key Y by ensuring that 1 < Y Peers MUST validate each other's public key Y by ensuring that 1 < Y
< p-1. This check ensures that the remote peer is properly behaved < p-1. This 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.
4.2.8.2. ECDHE Parameters 4.2.8.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the the ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure. opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
For secp256r1, secp384r1 and secp521r1, the contents are the For secp256r1, secp384r1 and secp521r1, the contents are the
serialized value of the following struct: serialized value of the following struct:
struct { struct {
uint8 legacy_form = 4; uint8 legacy_form = 4;
opaque X[coordinate_length]; opaque X[coordinate_length];
opaque Y[coordinate_length]; opaque Y[coordinate_length];
} UncompressedPointRepresentation; } UncompressedPointRepresentation;
X and Y respectively are the binary representations of the X and Y X and Y respectively are the binary representations of the x and y
values in network byte order. There are no internal length markers, values in network byte order. There are no internal length markers,
so each number representation occupies as many octets as implied by so each number representation occupies as many octets as implied by
the curve parameters. For P-256 this means that each of X and Y use the curve parameters. For P-256 this means that each of X and Y use
32 octets, padded on the left by zeros if necessary. For P-384 they 32 octets, padded on the left by zeros if necessary. For P-384 they
take 48 octets each, and for P-521 they take 66 octets each. take 48 octets each, and for P-521 they take 66 octets each.
For the curves secp256r1, secp384r1 and secp521r1, peers MUST For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Y by ensuring that the point is a validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve. The appropriate validation valid point on the elliptic curve. The appropriate validation
procedures are defined in Section 4.3.7 of [X962] and alternatively procedures are defined in Section 4.3.7 of [X962] and alternatively
in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three
steps: (1) verify that Y is not the point at infinity (O), (2) verify steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Y = (x, y) both integers are in the correct interval, (3) that for Q = (x, y) both integers x and y are in the correct
ensure that (x, y) is a correct solution to the elliptic curve interval, (3) ensure that (x, y) is a correct solution to the
equation. For these curves, implementers do not need to verify elliptic curve equation. For these curves, implementers do not need
membership in the correct subgroup. to verify membership in the correct subgroup.
For X25519 and X448, the contents of the public value are the byte For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in string inputs and outputs of the corresponding functions defined in
[RFC7748], 32 bytes for X25519 and 56 bytes for X448. [RFC7748], 32 bytes for X25519 and 56 bytes for X448.
Note: Versions of TLS prior to 1.3 permitted point format Note: Versions of TLS prior to 1.3 permitted point format
negotiation; TLS 1.3 removes this feature in favor of a single point negotiation; TLS 1.3 removes this feature in favor of a single point
format for each curve. format for each curve.
4.2.9. Pre-Shared Key Exchange Modes 4.2.9. Pre-Shared Key Exchange Modes
skipping to change at page 55, line 50 skipping to change at page 56, line 15
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct { struct {
PskKeyExchangeMode ke_modes<1..255>; PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes; } PskKeyExchangeModes;
psk_ke PSK-only key establishment. In this mode, the server MUST psk_ke PSK-only key establishment. In this mode, the server MUST
NOT supply a "key_share" value. NOT supply a "key_share" value.
psk_dhe_ke PSK with (EC)DHE key establishment. In this mode, the psk_dhe_ke PSK with (EC)DHE key establishment. In this mode, the
client and servers MUST supply "key_share" values as described in client and server MUST supply "key_share" values as described in
Section 4.2.8. Section 4.2.8.
Any future values that are allocated must ensure that the transmitted
protocol messages unambiguously identify which mode was selected by
the server; at present, this is indicated by the presence of the
"key_share" in the ServerHello.
4.2.10. Early Data Indication 4.2.10. Early Data Indication
When a PSK is used, the client can send application data in its first When a PSK is used and early data is allowed for that PSK, the client
flight of messages. If the client opts to do so, it MUST supply both can send application data in its first flight of messages. If the
the "early_data" extension as well as the "pre_shared_key" extension. client opts to do so, it MUST supply both the "early_data" extension
as well as the "pre_shared_key" extension.
The "extension_data" field of this extension contains an The "extension_data" field of this extension contains an
"EarlyDataIndication" value. "EarlyDataIndication" value.
struct {} Empty; struct {} Empty;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size; case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty; case client_hello: Empty;
case encrypted_extensions: Empty; case encrypted_extensions: Empty;
}; };
} EarlyDataIndication; } EarlyDataIndication;
See Section 4.6.1 for the use of the max_early_data_size field. See Section 4.6.1 for the use of the max_early_data_size field.
The parameters for the 0-RTT data (version, symmetric cipher suite, The parameters for the 0-RTT data (version, symmetric cipher suite,
ALPN protocol, etc.) are those associated with the PSK in use. For ALPN protocol, etc.) are those associated with the PSK in use. For
externally established PSKs, the associated values are those externally provisioned PSKs, the associated values are those
provisioned along with the key. For PSKs established via a provisioned along with the key. For PSKs established via a
NewSessionTicket message, the associated values are those which were NewSessionTicket message, the associated values are those which were
negotiated in the connection which established the PSK. The PSK used negotiated in the connection which established the PSK. The PSK used
to encrypt the early data MUST be the first PSK listed in the to encrypt the early data MUST be the first PSK listed in the
client's "pre_shared_key" extension. client's "pre_shared_key" extension.
For PSKs provisioned via NewSessionTicket, a server MUST validate For PSKs provisioned via NewSessionTicket, a server MUST validate
that the ticket age for the selected PSK identity (computed by that the ticket age for the selected PSK identity (computed by
subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age
modulo 2^32) is within a small tolerance of the time since the ticket modulo 2^32) is within a small tolerance of the time since the ticket
was issued (see Section 8). If it is not, the server SHOULD proceed was issued (see Section 8). If it is not, the server SHOULD proceed
with the handshake but reject 0-RTT, and SHOULD NOT take any other with the handshake but reject 0-RTT, and SHOULD NOT take any other
action that assumes that this ClientHello is fresh. action that assumes that this ClientHello is fresh.
0-RTT messages sent in the first flight have the same (encrypted) 0-RTT messages sent in the first flight have the same (encrypted)
content types as their corresponding messages sent in other flights content types as messages of the same type sent in other flights
(handshake and application_data) but are protected under different (handshake and application_data) but are protected under different
keys. After receiving the server's Finished message, if the server keys. After receiving the server's Finished message, if the server
has accepted early data, an EndOfEarlyData message will be sent to has accepted early data, an EndOfEarlyData message will be sent to
indicate the key change. This message will be encrypted with the indicate the key change. This message will be encrypted with the
0-RTT traffic keys. 0-RTT traffic keys.
A server which receives an "early_data" extension MUST behave in one A server which receives an "early_data" extension MUST behave in one
of three ways: of three ways:
- Ignore the extension and return a regular 1-RTT response. The - Ignore the extension and return a regular 1-RTT response. The
server then ignores early data by attempting to decrypt received server then skips past early data by attempting to deprotect
records in the handshake traffic keys until it is able to receive received records using the handshake traffic key, discarding
the client's second flight and complete an ordinary 1-RTT records which fail deprotection (up to the configured
handshake, skipping records that fail to decrypt, up to the max_early_data_size). Once a record is deprotected successfully,
configured max_early_data_size. it is treated as the start of the client's second flight and the
the server proceeds as with an ordinary 1-RTT handshake.
- Request that the client send another ClientHello by responding - Request that the client send another ClientHello by responding
with a HelloRetryRequest. A client MUST NOT include the with a HelloRetryRequest. A client MUST NOT include the
"early_data" extension in its followup ClientHello. The server "early_data" extension in its followup ClientHello. The server
then ignores early data by skipping all records with external then ignores early data by skipping all records with external
content type of "application_data" (indicating that they are content type of "application_data" (indicating that they are
encrypted). encrypted), up to the configured max_early_data_size.
- Return its own extension in EncryptedExtensions, indicating that - Return its own "early_data" extension in EncryptedExtensions,
it intends to process the early data. It is not possible for the indicating that it intends to process the early data. It is not
server to accept only a subset of the early data messages. Even possible for the server to accept only a subset of the early data
though the server sends a message accepting early data, the actual messages. Even though the server sends a message accepting early
early data itself may already be in flight by the time the server data, the actual early data itself may already be in flight by the
generates this message. time the server generates this message.
In order to accept early data, the server MUST have accepted a PSK In order to accept early data, the server MUST have accepted a PSK
cipher suite and selected the first key offered in the client's cipher suite and selected the first key offered in the client's
"pre_shared_key" extension. In addition, it MUST verify that the "pre_shared_key" extension. In addition, it MUST verify that the
following values are consistent with those associated with the following values are the same as those associated with the selected
selected PSK: PSK:
- The TLS version number - The TLS version number
- The selected cipher suite - The selected cipher suite
- The selected ALPN [RFC7301] protocol, if any - The selected ALPN [RFC7301] protocol, if any
These requirements are a superset of those needed to perform a 1-RTT These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question. For externally established handshake using the PSK in question. For externally established
PSKs, the associated values are those provisioned along with the key. PSKs, the associated values are those provisioned along with the key.
For PSKs established via a NewSessionTicket message, the associated For PSKs established via a NewSessionTicket message, the associated
values are those negotiated in the connection during which the ticket values are those negotiated in the connection during which the ticket
was established. was established.
skipping to change at page 58, line 10 skipping to change at page 58, line 29
first two mechanisms listed above (thus falling back to 1-RTT or first two mechanisms listed above (thus falling back to 1-RTT or
2-RTT). If the client attempts a 0-RTT handshake but the server 2-RTT). If the client attempts a 0-RTT handshake but the server
rejects it, the server will generally not have the 0-RTT record rejects it, the server will generally not have the 0-RTT record
protection keys and must instead use trial decryption (either with protection keys and must instead use trial decryption (either with
the 1-RTT handshake keys or by looking for a cleartext ClientHello in the 1-RTT handshake keys or by looking for a cleartext ClientHello in
the case of HelloRetryRequest) to find the first non-0-RTT message. the case of HelloRetryRequest) to find the first non-0-RTT message.
If the server chooses to accept the "early_data" extension, then it If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for MUST comply with the same error handling requirements specified for
all records when processing early data records. Specifically, if the all records when processing early data records. Specifically, if the
server fails to decrypt any 0-RTT record following an accepted server fails to decrypt a 0-RTT record following an accepted
"early_data" extension it MUST terminate the connection with a "early_data" extension it MUST terminate the connection with a
"bad_record_mac" alert as per Section 5.2. "bad_record_mac" alert as per Section 5.2.
If the server rejects the "early_data" extension, the client If the server rejects the "early_data" extension, the client
application MAY opt to retransmit early data once the handshake has application MAY opt to retransmit the application data previously
been completed. Note that automatic re-transmission of early data sent in early data once the handshake has been completed. Note that
could result in assumptions about the status of the connection being automatic re-transmission of early data could result in assumptions
incorrect. For instance, when the negotiated connection selects a about the status of the connection being incorrect. For instance,
different ALPN protocol from what was used for the early data, an when the negotiated connection selects a different ALPN protocol from
application might need to construct different messages. Similarly, what was used for the early data, an application might need to
if early data assumes anything about the connection state, it might construct different messages. Similarly, if early data assumes
be sent in error after the handshake completes. anything about the connection state, it might be sent in error after
the handshake completes.
A TLS implementation SHOULD NOT automatically re-send early data; A TLS implementation SHOULD NOT automatically re-send early data;
applications are in a better position to decide when re-transmission applications are in a better position to decide when re-transmission
is appropriate. A TLS implementation MUST NOT automatically re-send is appropriate. A TLS implementation MUST NOT automatically re-send
early data unless the negotiated connection selects the same ALPN early data unless the negotiated connection selects the same ALPN
protocol. protocol.
4.2.11. Pre-Shared Key Extension 4.2.11. Pre-Shared Key Extension
The "pre_shared_key" extension is used to indicate the identity of The "pre_shared_key" extension is used to negotiate 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 PSK key establishment. with PSK key establishment.
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"PreSharedKeyExtension" value: "PreSharedKeyExtension" value:
struct { struct {
opaque identity<1..2^16-1>; opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
} PskIdentity; } PskIdentity;
skipping to change at page 60, line 33 skipping to change at page 60, line 44
SHOULD simply be ignored. If no acceptable PSKs are found, the SHOULD simply be ignored. If no acceptable PSKs are found, the
server SHOULD perform a non-PSK handshake if possible. If backwards server SHOULD perform a non-PSK handshake if possible. If backwards
compatibility is important, client provided, externally established compatibility is important, client provided, externally established
PSKs SHOULD influence cipher suite selection. PSKs SHOULD influence cipher suite selection.
Prior to accepting PSK key establishment, the server MUST validate Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see Section 4.2.11.2 below). If this the corresponding binder value (see Section 4.2.11.2 below). If this
value is not present or does not validate, the server MUST abort the value is not present or does not validate, the server MUST abort the
handshake. Servers SHOULD NOT attempt to validate multiple binders; handshake. Servers SHOULD NOT attempt to validate multiple binders;
rather they SHOULD select a single PSK and validate solely the binder rather they SHOULD select a single PSK and validate solely the binder
that corresponds to that PSK. In order to accept PSK key that corresponds to that PSK. See [Section 8.2] for the security
rationale for this requirement. In order to accept PSK key
establishment, the server sends a "pre_shared_key" extension establishment, the server sends a "pre_shared_key" extension
indicating the selected identity. indicating the selected identity.
Clients MUST verify that the server's selected_identity is within the Clients MUST verify that the server's selected_identity is within the
range supplied by the client, that the server selected a cipher suite range supplied by the client, that the server selected a cipher suite
indicating a Hash associated with the PSK and that a server indicating a Hash associated with the PSK and that a server
"key_share" extension is present if required by the ClientHello "key_share" extension is present if required by the ClientHello
"psk_key_exchange_modes". If these values are not consistent the "psk_key_exchange_modes". If these values are not consistent the
client MUST abort the handshake with an "illegal_parameter" alert. client MUST abort the handshake with an "illegal_parameter" alert.
If the server supplies an "early_data" extension, the client MUST If the server supplies an "early_data" extension, the client MUST
verify that the server's selected_identity is 0. If any other value verify that the server's selected_identity is 0. If any other value
is returned, the client MUST abort the handshake with an is returned, the client MUST abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
This extension MUST be the last extension in the ClientHello (this The "pre_shared_key" extension MUST be the last extension in the
facilitates implementation as described below). Servers MUST check ClientHello (this facilitates implementation as described below).
that it is the last extension and otherwise fail the handshake with Servers MUST check that it is the last extension and otherwise fail
an "illegal_parameter" alert. the handshake with an "illegal_parameter" alert.
4.2.11.1. Ticket Age 4.2.11.1. Ticket Age
The client's view of the age of a ticket is the time since the The client's view of the age of a ticket is the time since the
receipt of the NewSessionTicket message. Clients MUST NOT attempt to receipt of the NewSessionTicket message. Clients MUST NOT attempt to
use tickets which have ages greater than the "ticket_lifetime" value use tickets which have ages greater than the "ticket_lifetime" value
which was provided with the ticket. The "obfuscated_ticket_age" which was provided with the ticket. The "obfuscated_ticket_age"
field of each PskIdentity contains an obfuscated version of the field of each PskIdentity contains an obfuscated version of the
ticket age formed by taking the age in milliseconds and adding the ticket age formed by taking the age in milliseconds and adding the
"ticket_age_add" value that was included with the ticket, see "ticket_age_add" value that was included with the ticket (see
Section 4.6.1 modulo 2^32. This addition prevents passive observers Section 4.6.1), modulo 2^32. This addition prevents passive
from correlating connections unless tickets are reused. Note that observers from correlating connections unless tickets are reused.
the "ticket_lifetime" field in the NewSessionTicket message is in Note that the "ticket_lifetime" field in the NewSessionTicket message
seconds but the "obfuscated_ticket_age" is in milliseconds. Because is in seconds but the "obfuscated_ticket_age" is in milliseconds.
ticket lifetimes are restricted to a week, 32 bits is enough to Because ticket lifetimes are restricted to a week, 32 bits is enough
represent any plausible age, even in milliseconds. to represent any plausible age, even in milliseconds.
4.2.11.2. PSK Binder 4.2.11.2. PSK Binder
The PSK binder value forms a binding between a PSK and the current The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the handshake in which the PSK was handshake, as well as a binding between the handshake in which the
generated (if via a NewSessionTicket message) and the handshake where PSK was generated (if via a NewSessionTicket message) and the current
it was used. Each entry in the binders list is computed as an HMAC handshake. Each entry in the binders list is computed as an HMAC
over a transcript hash (see Section 4.4.1) containing a partial over a transcript hash (see Section 4.4.1) containing a partial
ClientHello up to and including the PreSharedKeyExtension.identities ClientHello up to and including the PreSharedKeyExtension.identities
field. That is, it includes all of the ClientHello but not the field. That is, it includes all of the ClientHello but not the
binders list itself. The length fields for the message (including binders list itself. The length fields for the message (including
the overall length, the length of the extensions block, and the the overall length, the length of the extensions block, and the
length of the "pre_shared_key" extension) are all set as if binders length of the "pre_shared_key" extension) are all set as if binders
of the correct lengths were present. of the correct lengths were present.
The PskBinderEntry is computed in the same way as the Finished The PskBinderEntry is computed in the same way as the Finished
message (Section 4.4.4) but with the BaseKey being the binder_key message (Section 4.4.4) but with the BaseKey being the binder_key
skipping to change at page 62, line 21 skipping to change at page 62, line 33
Truncate(ClientHello1) is hashed directly, but in the second flight, Truncate(ClientHello1) is hashed directly, but in the second flight,
ClientHello1 is hashed and then reinjected as a "message_hash" ClientHello1 is hashed and then reinjected as a "message_hash"
message, as described in Section 4.4.1. message, as described in Section 4.4.1.
4.2.11.3. Processing Order 4.2.11.3. Processing Order
Clients are permitted to "stream" 0-RTT data until they receive the Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the EndOfEarlyData message, server's Finished, only then sending the EndOfEarlyData message,
followed by the rest of the handshake. In order to avoid deadlocks, followed by the rest of the handshake. In order to avoid deadlocks,
when accepting "early_data", servers MUST process the client's when accepting "early_data", servers MUST process the client's
ClientHello and then immediately send the ServerHello, rather than ClientHello and then immediately send their flight of messages,
waiting for the client's EndOfEarlyData message. rather than waiting for the client's EndOfEarlyData message before
sending its ServerHello.
4.3. Server Parameters 4.3. Server Parameters
The next two messages from the server, EncryptedExtensions and The next two messages from the server, EncryptedExtensions and
CertificateRequest, contain information from the server that CertificateRequest, contain information from the server that
determines the rest of the handshake. These messages are encrypted determines the rest of the handshake. These messages are encrypted
with keys derived from the server_handshake_traffic_secret. with keys derived from the server_handshake_traffic_secret.
4.3.1. Encrypted Extensions 4.3.1. Encrypted Extensions
skipping to change at page 63, line 39 skipping to change at page 64, line 4
extensions A set of extensions describing the parameters of the extensions A set of extensions describing the parameters of the
certificate being requested. The "signature_algorithms" extension certificate being requested. The "signature_algorithms" extension
MUST be specified, and other extensions may optionally be included MUST be specified, and other extensions may optionally be included
if defined for this message. Clients MUST ignore unrecognized if defined for this message. Clients MUST ignore unrecognized
extensions. extensions.
In prior versions of TLS, the CertificateRequest message carried a In prior versions of TLS, the CertificateRequest message carried a
list of signature algorithms and certificate authorities which the list of signature algorithms and certificate authorities which the
server would accept. In TLS 1.3 the former is expressed by sending server would accept. In TLS 1.3 the former is expressed by sending
the "signature_algorithms" and "signature_algorithms_cert" the "signature_algorithms" and optionally "signature_algorithms_cert"
extensions. The latter is expressed by sending the extensions. The latter is expressed by sending the
"certificate_authorities" extension (see Section 4.2.4). "certificate_authorities" extension (see Section 4.2.4).
Servers which are authenticating with a PSK MUST NOT send the Servers which are authenticating with a PSK MUST NOT send the
CertificateRequest message in the main handshake, though they MAY CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see Section 4.6.2) provided send it in post-handshake authentication (see Section 4.6.2) provided
that the client has sent the "post_handshake_auth" extension (see that the client has sent the "post_handshake_auth" extension (see
Section 4.2.6). Section 4.2.6).
4.4. Authentication Messages 4.4. Authentication Messages
skipping to change at page 64, line 32 skipping to change at page 64, line 41
- A Handshake Context consisting of the set of messages to be - A Handshake Context consisting of the set of messages to be
included in the transcript hash. included in the transcript hash.
- A base key to be used to compute a MAC key. - A base key to be used to compute a MAC key.
Based on these inputs, the messages then contain: Based on these inputs, the messages then contain:
Certificate The certificate to be used for authentication, and any Certificate The certificate to be used for authentication, and any
supporting certificates in the chain. Note that certificate-based supporting certificates in the chain. Note that certificate-based
client authentication is not available in 0-RTT mode. client authentication is not available in PSK (including 0-RTT)
flows.
CertificateVerify A signature over the value Transcript- CertificateVerify A signature over the value Transcript-
Hash(Handshake Context, Certificate) Hash(Handshake Context, Certificate)
Finished A MAC over the value Transcript-Hash(Handshake Context, Finished A MAC over the value Transcript-Hash(Handshake Context,
Certificate, CertificateVerify) using a MAC key derived from the Certificate, CertificateVerify) using a MAC key derived from the
base key. base key.
The following table defines the Handshake Context and MAC Base Key The following table defines the Handshake Context and MAC Base Key
for each scenario: for each scenario:
skipping to change at page 65, line 29 skipping to change at page 65, line 32
+-----------+----------------------------+--------------------------+ +-----------+----------------------------+--------------------------+
4.4.1. The Transcript Hash 4.4.1. The Transcript Hash
Many of the cryptographic computations in TLS make use of a Many of the cryptographic computations in TLS make use of a
transcript hash. This value is computed by hashing the concatenation transcript hash. This value is computed by hashing the concatenation
of each included handshake message, including the handshake message of each included handshake message, including the handshake message
header carrying the handshake message type and length fields, but not header carrying the handshake message type and length fields, but not
including record layer headers. I.e., including record layer headers. I.e.,
Transcript-Hash(M1, M2, ... MN) = Hash(M1 || M2 ... MN) Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
As an exception to this general rule, when the server responds to a As an exception to this general rule, when the server responds to a
ClientHello with a HelloRetryRequest, the value of ClientHello1 is ClientHello with a HelloRetryRequest, the value of ClientHello1 is
replaced with a special synthetic handshake message of handshake type replaced with a special synthetic handshake message of handshake type
"message_hash" containing Hash(ClientHello1). I.e., "message_hash" containing Hash(ClientHello1). I.e.,
Transcript-Hash(ClientHello1, HelloRetryRequest, ... MN) = Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */ Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */ 00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */ Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest ... MN) HelloRetryRequest || ... || Mn)
The reason for this construction is to allow the server to do a The reason for this construction is to allow the server to do a
stateless HelloRetryRequest by storing just the hash of ClientHello1 stateless HelloRetryRequest by storing just the hash of ClientHello1
in the cookie, rather than requiring it to export the entire in the cookie, rather than requiring it to export the entire
intermediate hash state (see Section 4.2.2). intermediate hash state (see Section 4.2.2).
For concreteness, the transcript hash is always taken from the For concreteness, the transcript hash is always taken from the
following sequence of handshake messages, starting at the first following sequence of handshake messages, starting at the first
ClientHello and including only those messages that were sent: ClientHello and including only those messages that were sent:
ClientHello, HelloRetryRequest, ClientHello, ServerHello, ClientHello, HelloRetryRequest, ClientHello, ServerHello,
EncryptedExtensions, server CertificateRequest, server Certificate, EncryptedExtensions, server CertificateRequest, server Certificate,
server CertificateVerify, server Finished, EndOfEarlyData, client server CertificateVerify, server Finished, EndOfEarlyData, client
Certificate, client CertificateVerify, client Finished. Certificate, client CertificateVerify, client Finished.
In general, implementations can implement the transcript by keeping a In general, implementations can implement the transcript by keeping a
running transcript hash value based on the negotiated hash. Note, running transcript hash value based on the negotiated hash. Note,
however, that subsequent post-handshake authentications do not however, that subsequent post-handshake authentications do not
include each other, just the messages through the end of the main include each other, just the messages through the end of the main
handshake. handshake.
skipping to change at page 66, line 27 skipping to change at page 66, line 30
The server MUST send a Certificate message whenever the agreed-upon The server MUST send a Certificate message whenever the agreed-upon
key exchange method uses certificates for authentication (this key exchange method uses certificates for authentication (this
includes all key exchange methods defined in this document except includes all key exchange methods defined in this document except
PSK). PSK).
The client MUST send a Certificate message if and only if the server The client MUST send a Certificate message if and only if the server
has requested client authentication via a CertificateRequest message has requested client authentication via a CertificateRequest message
(Section 4.3.2). If the server requests client authentication but no (Section 4.3.2). If the server requests client authentication but no
suitable certificate is available, the client MUST send a Certificate suitable certificate is available, the client MUST send a Certificate
message containing no certificates (i.e., with the "certificate_list" message containing no certificates (i.e., with the "certificate_list"
field having length 0). field having length 0). A Finished message MUST be sent regardless
of whether the Certificate message is empty.
Structure of this message: Structure of this message:
/* Managed by IANA */
enum { enum {
X509(0), X509(0),
RawPublicKey(2), RawPublicKey(2),
(255) (255)
} CertificateType; } CertificateType;
struct { struct {
select (certificate_type) { select (certificate_type) {
case RawPublicKey: case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */ /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
skipping to change at page 67, line 39 skipping to change at page 67, line 40
CertificateRequest, the value of certificate_request_context in CertificateRequest, the value of certificate_request_context in
that message. Otherwise (in the case of server authentication), that message. Otherwise (in the case of server authentication),
this field SHALL be zero length. this field SHALL be zero length.
certificate_list This is a sequence (chain) of CertificateEntry certificate_list This is a sequence (chain) of CertificateEntry
structures, each containing a single certificate and set of structures, each containing a single certificate and set of
extensions. extensions.
extensions: A set of extension values for the CertificateEntry. The extensions: A set of extension values for the CertificateEntry. The
"Extension" format is defined in Section 4.2. Valid extensions "Extension" format is defined in Section 4.2. Valid extensions
for server certificates include OCSP Status extension ([RFC6066]) for server certificates at present include OCSP Status extension
and SignedCertificateTimestamps ([RFC6962]). Extensions in the ([RFC6066]) and SignedCertificateTimestamps ([RFC6962]); future
Certificate message from the server MUST correspond to one from extensions may be defined for this message as well. Extensions in
the ClientHello message. Extensions in the Certificate from the the Certificate message from the server MUST correspond to ones
client MUST correspond with an extension in the CertificateRequest from the ClientHello message. Extensions in the Certificate from
message from the server. If an extension applies to the entire the client MUST correspond with extensions in the
chain, it SHOULD be included in the first CertificateEntry. CertificateRequest message from the server. If an extension
applies to the entire chain, it SHOULD be included in the first
CertificateEntry.
If the corresponding certificate type extension If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not ("server_certificate_type" or "client_certificate_type") was not
negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated in Encrypted Extensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains a DER-encoded X.509 negotiated, then each CertificateEntry contains a DER-encoded X.509
certificate. The sender's certificate MUST come in the first certificate. The sender's certificate MUST come in the first
CertificateEntry in the list. Each following certificate SHOULD CertificateEntry in the list. Each following certificate SHOULD
directly certify one preceding it. Because certificate validation directly certify the one immediately preceding it. Because
requires that trust anchors be distributed independently, a certificate validation requires that trust anchors be distributed
certificate that specifies a trust anchor MAY be omitted from the independently, a certificate that specifies a trust anchor MAY be
chain, provided that supported peers are known to possess any omitted omitted from the chain, provided that supported peers are known to
certificates. possess any omitted certificates.
Note: Prior to TLS 1.3, "certificate_list" ordering required each Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however, certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which TLS version, with the exception of the end-entity certificate which
skipping to change at page 69, line 27 skipping to change at page 69, line 29
4.4.2.2. Server Certificate Selection 4.4.2.2. Server Certificate Selection
The following rules apply to the certificates sent by the server: The following rules apply to the certificates sent by the server:
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
negotiated otherwise (e.g., [RFC7250]). negotiated otherwise (e.g., [RFC7250]).
- The server's end-entity certificate's public key (and associated - The server's end-entity certificate's public key (and associated
restrictions) MUST be compatible with the selected authentication restrictions) MUST be compatible with the selected authentication
algorithm (currently RSA, ECDSA, or EdDSA). algorithm from the client's "signature_algorithms" extension
(currently RSA, ECDSA, or EdDSA).
- The certificate MUST allow the key to be used for signing (i.e., - The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme indicated in the client's present) with a signature scheme indicated in the client's
"signature_algorithms"/"signature_algorithms_cert" extensions (see "signature_algorithms"/"signature_algorithms_cert" extensions (see
Section 4.2.3). Section 4.2.3).
- The "server_name" [RFC6066] and "certificate_authorities" - The "server_name" [RFC6066] and "certificate_authorities"
extensions are used to guide certificate selection. As servers extensions are used to guide certificate selection. As servers
MAY require the presence of the "server_name" extension, clients MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable. SHOULD send this extension, when applicable.
All certificates provided by the server MUST be signed by a signature All certificates provided by the server MUST be signed by a signature
algorithm advertised by the client, if they are able to provide such algorithm advertised by the client, if it is able to provide such a
a chain (see Section 4.2.3). Certificates that are self-signed or chain (see Section 4.2.3). Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm. as part of the chain and therefore MAY be signed with any algorithm.
If the server cannot produce a certificate chain that is signed only If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the that may include algorithms that are not known to be supported by the
client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise. permits it, and MUST NOT do so otherwise.
skipping to change at page 70, line 35 skipping to change at page 70, line 37
certificates in the certificate chain SHOULD be issued by one of certificates in the certificate chain SHOULD be issued by one of
the listed CAs. the listed CAs.
- The certificates MUST be signed using an acceptable signature - The certificates MUST be signed using an acceptable signature
algorithm, as described in Section 4.3.2. Note that this relaxes algorithm, as described in Section 4.3.2. Note that this relaxes
the constraints on certificate-signing algorithms found in prior the constraints on certificate-signing algorithms found in prior
versions of TLS. versions of TLS.
- If the CertificateRequest message contained a non-empty - If the CertificateRequest message contained a non-empty
"oid_filters" extension, the end-entity certificate MUST match the "oid_filters" extension, the end-entity certificate MUST match the
extension OIDs recognized by the client, as described in extension OIDs that are recognized by the client, as described in
Section 4.2.5. Section 4.2.5.
Note that, as with the server certificate, there are certificates Note that, as with the server certificate, there are certificates
that use algorithm combinations that cannot be currently used with that use algorithm combinations that cannot be currently used with
TLS. TLS.
4.4.2.4. Receiving a Certificate Message 4.4.2.4. Receiving a Certificate Message
In general, detailed certificate validation procedures are out of In general, detailed certificate validation procedures are out of
scope for TLS (see [RFC5280]). This section provides TLS-specific scope for TLS (see [RFC5280]). This section provides TLS-specific
requirements. requirements.
If the server supplies an empty Certificate message, the client MUST If the server supplies an empty Certificate message, the client MUST
abort the handshake with a "decode_error" alert. abort the handshake with a "decode_error" alert.
If the client does not send any certificates, the server MAY at its If the client does not send any certificates (i.e., it sends an empty
discretion either continue the handshake without client Certificate message), the server MAY at its discretion either
authentication, or abort the handshake with a "certificate_required" continue the handshake without client authentication, or abort the
alert. Also, if some aspect of the certificate chain was handshake with a "certificate_required" alert. Also, if some aspect
unacceptable (e.g., it was not signed by a known, trusted CA), the of the certificate chain was unacceptable (e.g., it was not signed by
server MAY at its discretion either continue the handshake a known, trusted CA), the server MAY at its discretion either
(considering the client unauthenticated) or abort the handshake. continue the handshake (considering the client unauthenticated) or
abort the handshake.
Any endpoint receiving any certificate which it would need to Any endpoint receiving any certificate which it would need to
validate using any signature algorithm using an MD5 hash MUST abort validate using any signature algorithm using an MD5 hash MUST abort
the handshake with a "bad_certificate" alert. SHA-1 is deprecated the handshake with a "bad_certificate" alert. SHA-1 is deprecated
and it is RECOMMENDED that any endpoint receiving any certificate and it is RECOMMENDED that any endpoint receiving any certificate
which it would need to validate using any signature algorithm using a which it would need to validate using any signature algorithm using a
SHA-1 hash abort the handshake with a "bad_certificate" alert. For SHA-1 hash abort the handshake with a "bad_certificate" alert. For
clarity, this means that endpoints MAY accept these algorithms for clarity, this means that endpoints MAY accept these algorithms for
certificates that are self-signed or are trust anchors. certificates that are self-signed or are trust anchors.
skipping to change at page 72, line 25 skipping to change at page 72, line 25
- A single 0 byte which serves as the separator - A single 0 byte which serves as the separator
- The content to be signed - The content to be signed
This structure is intended to prevent an attack on previous versions This structure is intended to prevent an attack on previous versions
of TLS in which the ServerKeyExchange format meant that attackers of TLS in which the ServerKeyExchange format meant that attackers
could obtain a signature of a message with a chosen 32-byte prefix could obtain a signature of a message with a chosen 32-byte prefix
(ClientHello.random). The initial 64-byte pad clears that prefix (ClientHello.random). The initial 64-byte pad clears that prefix
along with the server-controlled ServerHello.random. along with the server-controlled ServerHello.random.
The context string for a server signature is "TLS 1.3, server The context string for a server signature is: "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client CertificateVerify" The context string for a client signature is: "TLS
CertificateVerify". It is used to provide separation between 1.3, client CertificateVerify" It is used to provide separation
signatures made in different contexts, helping against potential between signatures made in different contexts, helping against
cross-protocol attacks. potential cross-protocol attacks.
For example, if the transcript hash was 32 bytes of 01 (this length For example, if the transcript hash was 32 bytes of 01 (this length
would make sense for SHA-256), the content covered by the digital would make sense for SHA-256), the content covered by the digital
signature for a server CertificateVerify would be: signature for a server CertificateVerify would be:
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966 544c5320312e332c207365727665722043657274696669636174655665726966
79 79
00 00
skipping to change at page 74, line 10 skipping to change at page 74, line 10
which it is permitted to send data prior to receiving the peer's which it is permitted to send data prior to receiving the peer's
Finished: Finished:
1. Clients sending 0-RTT data as described in Section 4.2.10. 1. Clients sending 0-RTT data as described in Section 4.2.10.
2. Servers MAY send data after sending their first flight, but 2. Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance because the handshake is not yet complete, they have no assurance
of either the peer's identity or of its liveness (i.e., the of either the peer's identity or of its liveness (i.e., the
ClientHello might have been replayed). ClientHello might have been replayed).
The key used to compute the finished message is computed from the The key used to compute the Finished message is computed from the
Base key defined in Section 4.4 using HKDF (see Section 7.1). Base key defined in Section 4.4 using HKDF (see Section 7.1).
Specifically: Specifically:
finished_key = finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
Structure of this message: Structure of this message:
struct { struct {
opaque verify_data[Hash.length]; opaque verify_data[Hash.length];
skipping to change at page 74, line 43 skipping to change at page 74, line 43
above, the HMAC input can generally be implemented by a running hash, above, the HMAC input can generally be implemented by a running hash,
i.e., just the handshake hash at this point. i.e., just the handshake hash at this point.
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 TLS 1.3, it is the size of the HMAC output for the Hash long. In TLS 1.3, it is the size of the HMAC output for the Hash
used for the handshake. 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. and are not included in the hash computations.
Any records following a 1-RTT Finished message MUST be encrypted Any records following a Finished message MUST be encrypted under the
under the appropriate application traffic key as described in appropriate application traffic key as described in Section 7.2. In
Section 7.2. In particular, this includes any alerts sent by the particular, this includes any alerts sent by the server in response
server in response to client Certificate and CertificateVerify to client Certificate and CertificateVerify messages.
messages.
4.5. End of Early Data 4.5. End of Early Data
struct {} EndOfEarlyData; struct {} EndOfEarlyData;
If the server sent an "early_data" extension, the client MUST send an If the server sent an "early_data" extension, the client MUST send an
EndOfEarlyData message after receiving the server Finished. If the EndOfEarlyData message after receiving the server Finished. If the
server does not send an "early_data" extension, then the client MUST server does not send an "early_data" extension, then the client MUST
NOT send an EndOfEarlyData message. This message indicates that all NOT send an EndOfEarlyData message. This message indicates that all
0-RTT application_data messages, if any, have been transmitted and 0-RTT application_data messages, if any, have been transmitted and
skipping to change at page 75, line 31 skipping to change at page 75, line 27
TLS also allows other messages to be sent after the main handshake. TLS also allows other messages to be sent after the main handshake.
These messages use a handshake content type and are encrypted under These messages use a handshake content type and are encrypted under
the appropriate application traffic key. the appropriate application traffic key.
4.6.1. New Session Ticket Message 4.6.1. New Session Ticket Message
At any time after the server has received the client Finished At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message. This message message, it MAY send a NewSessionTicket message. This message
creates a unique association between the ticket value and a secret creates a unique association between the ticket value and a secret
PSK derived from the resumption master secret. PSK derived from the resumption master secret (see Section 7.
The client MAY use this PSK for future handshakes by including the The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello ticket value in the "pre_shared_key" extension in its ClientHello
(Section 4.2.11). Servers MAY send multiple tickets on a single (Section 4.2.11). Servers MAY send multiple tickets on a single
connection, either immediately after each other or after specific connection, either immediately after each other or after specific
events (see Appendix C.4). For instance, the server might send a new events (see Appendix C.4). For instance, the server might send a new
ticket after post-handshake authentication in order to encapsulate ticket after post-handshake authentication in order to encapsulate
the additional client authentication state. Multiple tickets are the additional client authentication state. Multiple tickets are
useful for clients for a variety of purposes, including: useful for clients for a variety of purposes, including:
skipping to change at page 76, line 41 skipping to change at page 76, line 37
opaque ticket<1..2^16-1>; opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>; Extension extensions<0..2^16-2>;
} NewSessionTicket; } NewSessionTicket;
ticket_lifetime Indicates the lifetime in seconds as a 32-bit ticket_lifetime Indicates the lifetime in seconds as a 32-bit
unsigned integer in network byte order from the time of ticket unsigned integer in network byte order from the time of ticket
issuance. Servers MUST NOT use any value greater than 604800 issuance. Servers MUST NOT use any value greater than 604800
seconds (7 days). The value of zero indicates that the ticket seconds (7 days). The value of zero indicates that the ticket
should be discarded immediately. Clients MUST NOT cache tickets should be discarded immediately. Clients MUST NOT cache tickets
for longer than 7 days, regardless of the ticket_lifetime, and MAY for longer than 7 days, regardless of the ticket_lifetime, and MAY
delete the ticket earlier based on local policy. A server MAY delete tickets earlier based on local policy. A server MAY treat
treat a ticket as valid for a shorter period of time than what is a ticket as valid for a shorter period of time than what is stated
stated in the ticket_lifetime. in the ticket_lifetime.
ticket_age_add A securely generated, random 32-bit value that is ticket_age_add A securely generated, random 32-bit value that is
used to obscure the age of the ticket that the client includes in used to obscure the age of the ticket that the client includes in
the "pre_shared_key" extension. The client-side ticket age is the "pre_shared_key" extension. The client-side ticket age is
added to this value modulo 2^32 to obtain the value that is added to this value modulo 2^32 to obtain the value that is
transmitted by the client. The server MUST generate a fresh value transmitted by the client. The server MUST generate a fresh value
for each ticket it sends. for each ticket it sends.
ticket_nonce A per-ticket value that is unique across all tickets ticket_nonce A per-ticket value that is unique across all tickets
issued on this connection. issued on this connection.
skipping to change at page 80, line 9 skipping to change at page 79, line 51
time after the first ClientHello message has been sent or received time after the first ClientHello message has been sent or received
and before the peer's Finished message has been received and MUST and before the peer's Finished message has been received and MUST
simply drop it without further processing. Note that this record may simply drop it without further processing. Note that this record may
appear at a point at the handshake where the implementation is appear at a point at the handshake where the implementation is
expecting protected records and so it is necessary to detect this expecting protected records and so it is necessary to detect this
condition prior to attempting to deprotect the record. An condition prior to attempting to deprotect the record. An
implementation which receives any other change_cipher_spec value or implementation which receives any other change_cipher_spec value or
which receives a protected change_cipher_spec record MUST abort the which receives a protected change_cipher_spec record MUST abort the
handshake with an "unexpected_message" alert. A change_cipher_spec handshake with an "unexpected_message" alert. A change_cipher_spec
record received before the first ClientHello message or after the record received before the first ClientHello message or after the
peer's Finished message MUST be treated as an unexpected record type. peer's Finished message MUST be treated as an unexpected record type
(though stateless servers may not be able to distinguish these cases
from allowed cases).
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST terminate implementation receives an unexpected record type, it MUST terminate
the connection with an "unexpected_message" alert. New record the connection with an "unexpected_message" alert. New record
content type values are assigned by IANA in the TLS Content Type content type values are assigned by IANA in the TLS Content Type
Registry as described in Section 11. Registry as described in Section 11.
5.1. Record Layer 5.1. Record Layer
skipping to change at page 82, line 10 skipping to change at page 82, line 4
1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards
compatibility, records containing an initial ClientHello SHOULD have compatibility, records containing an initial ClientHello SHOULD have
version 0x0301 and a record containing a second ClientHello or a version 0x0301 and a record containing a second ClientHello or a
ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
respectively. When negotiating prior versions of TLS, endpoints respectively. When negotiating prior versions of TLS, endpoints
follow the procedure and requirements in Appendix D. follow the procedure and requirements in Appendix D.
When record protection has not yet been engaged, TLSPlaintext When record protection has not yet been engaged, TLSPlaintext
structures are written directly onto the wire. Once record structures are written directly onto the wire. Once record
protection has started, TLSPlaintext records are protected and sent protection has started, TLSPlaintext records are protected and sent
as described in the following section. as described in the following section. Note that application data
records MUST NOT be written to the wire unprotected (see Section 2
for details).
5.2. Record Payload Protection 5.2. Record Payload Protection
The record protection functions translate a TLSPlaintext structure The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext. The deprotection functions reverse the into a TLSCiphertext. The deprotection functions reverse the
process. In TLS 1.3, as opposed to previous versions of TLS, all process. In TLS 1.3, as opposed to previous versions of TLS, all
ciphers are modeled as "Authenticated Encryption with Additional ciphers are modeled as "Authenticated Encryption with Additional
Data" (AEAD) [RFC5116]. AEAD functions provide an unified encryption Data" (AEAD) [RFC5116]. AEAD functions provide an unified encryption
and authentication operation which turns plaintext into authenticated and authentication operation which turns plaintext into authenticated
ciphertext and back again. Each encrypted record consists of a ciphertext and back again. Each encrypted record consists of a
skipping to change at page 82, line 37 skipping to change at page 82, line 33
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} TLSInnerPlaintext; } TLSInnerPlaintext;
struct { struct {
ContentType opaque_type = application_data; /* 23 */ ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length; uint16 length;
opaque encrypted_record[TLSCiphertext.length]; opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext; } TLSCiphertext;
content The byte encoding of a handshake or an alert message, or the content The TLSPLaintext.fragment value, containing the byte
raw bytes of the application's data to send. encoding of a handshake or an alert message, or the raw bytes of
the application's data to send.
type The content type of the record. type The TLSPlaintext.type value containing the content type of the
record.
zeros An arbitrary-length run of zero-valued bytes may appear in the zeros An arbitrary-length run of zero-valued bytes may appear in the
cleartext after the type field. This provides an opportunity for cleartext after the type field. This provides an opportunity for
senders to pad any TLS record by a chosen amount as long as the senders to pad any TLS record by a chosen amount as long as the
total stays within record size limits. See Section 5.4 for more total stays within record size limits. See Section 5.4 for more
details. details.
opaque_type The outer opaque_type field of a TLSCiphertext record is opaque_type The outer opaque_type field of a TLSCiphertext record is
always set to the value 23 (application_data) for outward always set to the value 23 (application_data) for outward
compatibility with middleboxes accustomed to parsing previous compatibility with middleboxes accustomed to parsing previous
skipping to change at page 83, line 30 skipping to change at page 83, line 28
that exceeds this length MUST terminate the connection with a that exceeds this length MUST terminate the connection with a
"record_overflow" alert. "record_overflow" alert.
encrypted_record The AEAD-encrypted form of the serialized encrypted_record The AEAD-encrypted form of the serialized
TLSInnerPlaintext structure. TLSInnerPlaintext structure.
AEAD algorithms take as input a single key, a nonce, a plaintext, and AEAD algorithms take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [RFC5116]. The key is either the described in Section 2.1 of [RFC5116]. The key is either the
client_write_key or the server_write_key, the nonce is derived from client_write_key or the server_write_key, the nonce is derived from
the sequence number (see Section 5.3) and the client_write_iv or the sequence number and the client_write_iv or server_write_iv (see
server_write_iv, and the additional data input is the record header. Section 5.3), and the additional data input is the record header.
I.e., I.e.,
additional_data = TLSCiphertext.opaque_type || additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version || TLSCiphertext.legacy_record_version ||
TLSCiphertext.length TLSCiphertext.length
The plaintext input to the AEAD algorithm is the encoded The plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure. Derivation of traffic keys is defined TLSInnerPlaintext structure. Derivation of traffic keys is defined
in Section 7.3. in Section 7.3.
skipping to change at page 84, line 25 skipping to change at page 84, line 23
plaintext of encrypted_record = plaintext of encrypted_record =
AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
If the decryption fails, the receiver MUST terminate the connection If the decryption fails, the receiver MUST terminate the connection
with a "bad_record_mac" alert. with a "bad_record_mac" alert.
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion
greater than 255 octets. An endpoint that receives a record from its greater than 255 octets. An endpoint that receives a record from its
peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST
terminate the connection with a "record_overflow" alert. This limit terminate the connection with a "record_overflow" alert. This limit
is derived from the maximum TLSPlaintext length of 2^14 octets + 1 is derived from the maximum TLSInnerPlaintext length of 2^14 octets +
octet for ContentType + the maximum AEAD expansion of 255 octets. 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
5.3. Per-Record Nonce 5.3. Per-Record Nonce
A 64-bit sequence number is maintained separately for reading and A 64-bit sequence number is maintained separately for reading and
writing records. Each sequence number is set to zero at the writing records. The appropriate sequence number is incremented by
beginning of a connection and whenever the key is changed. one after reading or writing each record. Each sequence number is
set to zero at the beginning of a connection and whenever the key is
The appropriate sequence number is incremented by one after reading changed; the first record transmitted under a particular traffic key
or writing each record. The first record transmitted under a MUST use sequence number 0.
particular traffic key MUST use sequence number 0.
Because the size of sequence numbers is 64-bit, they should not wrap. Because the size of sequence numbers is 64-bit, they should not wrap.
If a TLS implementation would need to wrap a sequence number, it MUST If a TLS implementation would need to wrap a sequence number, it MUST
either re-key (Section 4.6.3) or terminate the connection. either re-key (Section 4.6.3) or terminate the connection.
Each AEAD algorithm will specify a range of possible lengths for the Each AEAD algorithm will specify a range of possible lengths for the
per-record nonce, from N_MIN bytes to N_MAX bytes of input per-record nonce, from N_MIN bytes to N_MAX bytes of input
([RFC5116]). The length of the TLS per-record nonce (iv_length) is ([RFC5116]). The length of the TLS per-record nonce (iv_length) is
set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see
[RFC5116] Section 4). An AEAD algorithm where N_MAX is less than 8 [RFC5116] Section 4). An AEAD algorithm where N_MAX is less than 8
skipping to change at page 86, line 41 skipping to change at page 86, line 39
safety limit is reached. safety limit is reached.
6. Alert Protocol 6. Alert Protocol
One of the content types supported by the TLS record layer is the One of the content types supported by the TLS record layer is the
alert type. Like other messages, alert messages are encrypted as alert type. Like other messages, alert messages are encrypted as
specified by the current connection state. specified by the current connection state.
Alert messages convey a description of the alert and a legacy field Alert messages convey a description of the alert and a legacy field
that conveyed the severity of the message in previous versions of that conveyed the severity of the message in previous versions of
TLS. In TLS 1.3, the severity is implicit in the type of alert being TLS. Alerts are divided into two classes: closure alerts and error
sent, and the 'level' field can safely be ignored. The alerts. In TLS 1.3, the severity is implicit in the type of alert
being sent, and the 'level' field can safely be ignored. The
"close_notify" alert is used to indicate orderly closure of one "close_notify" alert is used to indicate orderly closure of one
direction of the connection. Upon receiving such an alert, the TLS direction of the connection. Upon receiving such an alert, the TLS
implementation SHOULD indicate end-of-data to the application. implementation SHOULD indicate end-of-data to the application.
Error alerts indicate abortive closure of the connection (see Error alerts indicate abortive closure of the connection (see
Section 6.2). Upon receiving an error alert, the TLS implementation Section 6.2). Upon receiving an error alert, the TLS implementation
SHOULD indicate an error to the application and MUST NOT allow any SHOULD indicate an error to the application and MUST NOT allow any
further data to be sent or received on the connection. Servers and further data to be sent or received on the connection. Servers and
clients MUST forget keys and secrets associated with a failed clients MUST forget the secret values and keys established in failed
connection. Stateful implementations of tickets (as in many clients) connections, with the exception of the PSKs associated with session
SHOULD discard tickets associated with failed connections. tickets, which SHOULD be discarded if possible.
All the alerts listed in Section 6.2 MUST be sent as fatal and MUST All the alerts listed in Section 6.2 MUST be sent with
be treated as fatal regardless of the AlertLevel in the message. AlertLevel=fatal and MUST be treated as error alerts regardless of
Unknown alert types MUST be treated as fatal. the AlertLevel in the message. Unknown alert types MUST be treated
as error alerts.
Note: TLS defines two generic alerts (see Section 6) to use upon Note: TLS defines two generic alerts (see Section 6) to use upon
failure to parse a message. Peers which receive a message which failure to parse a message. Peers which receive a message which
cannot be parsed according to the syntax (e.g., have a length cannot be parsed according to the syntax (e.g., have a length
extending beyond the message boundary or contain an out-of-range extending beyond the message boundary or contain an out-of-range
length) MUST terminate the connection with a "decode_error" alert. length) MUST terminate the connection with a "decode_error" alert.
Peers which receive a message which is syntactically correct but Peers which receive a message which is syntactically correct but
semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
MUST terminate the connection with an "illegal_parameter" alert. MUST terminate the connection with an "illegal_parameter" alert.
skipping to change at page 88, line 30 skipping to change at page 88, line 30
access_denied(49), access_denied(49),
decode_error(50), decode_error(50),
decrypt_error(51), decrypt_error(51),
protocol_version(70), protocol_version(70),
insufficient_security(71), insufficient_security(71),
internal_error(80), internal_error(80),
inappropriate_fallback(86), inappropriate_fallback(86),
user_canceled(90), user_canceled(90),
missing_extension(109), missing_extension(109),
unsupported_extension(110), unsupported_extension(110),
certificate_unobtainable(111),
unrecognized_name(112), unrecognized_name(112),
bad_certificate_status_response(113), bad_certificate_status_response(113),
bad_certificate_hash_value(114),
unknown_psk_identity(115), unknown_psk_identity(115),
certificate_required(116), certificate_required(116),
no_application_protocol(120), no_application_protocol(120),
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
skipping to change at page 89, line 10 skipping to change at page 89, line 10
close_notify This alert notifies the recipient that the sender will close_notify This alert notifies the recipient that the sender will
not send any more messages on this connection. Any data received not send any more messages on this connection. Any data received
after a closure alert has been received MUST be ignored. after a closure alert has been received MUST be ignored.
user_canceled This alert notifies the recipient that the sender is user_canceled This alert notifies the recipient that the sender is
canceling the handshake for some reason unrelated to a protocol canceling the handshake for some reason unrelated to a protocol
failure. If a user cancels an operation after the handshake is failure. If a user cancels an operation after the handshake is
complete, just closing the connection by sending a "close_notify" complete, just closing the connection by sending a "close_notify"
is more appropriate. This alert SHOULD be followed by a is more appropriate. This alert SHOULD be followed by a
"close_notify". This alert is generally a warning. "close_notify". This alert generally has AlertLevel=warning.
Either party MAY initiate a close of its write side of the connection Either party MAY initiate a close of its write side of the connection
by sending a "close_notify" alert. Any data received after a closure by sending a "close_notify" alert. Any data received after a closure
alert has been received MUST be ignored. If a transport-level close alert has been received MUST be ignored. If a transport-level close
is received prior to a "close_notify", the receiver cannot know that is received prior to a "close_notify", the receiver cannot know that
all the data that was sent has been received. all the data that was sent has been received.
Each party MUST send a "close_notify" alert before closing its write Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some other fatal side of the connection, unless it has already sent some error alert.
alert. This does not have any effect on its read side of the This does not have any effect on its read side of the connection.
connection. Note that this is a change from versions of TLS prior to Note that this is a change from versions of TLS prior to TLS 1.3 in
TLS 1.3 in which implementations were required to react to a which implementations were required to react to a "close_notify" by
"close_notify" by discarding pending writes and sending an immediate discarding pending writes and sending an immediate "close_notify"
"close_notify" alert of their own. That previous requirement could alert of their own. That previous requirement could cause truncation
cause truncation in the read side. Both parties need not wait to in the read side. Both parties need not wait to receive a
receive a "close_notify" alert before closing their read side of the "close_notify" alert before closing their read side of the
connection. connection, though doing so would introduce the possibility of
truncation.
If the application protocol using TLS provides that any data may be If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application-layer. No part of before indicating end-of-data to the application-layer. No part of
this standard should be taken to dictate the manner in which a usage this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when profile for TLS manages its data transport, including when
connections are opened or closed. connections are opened or closed.
Note: It is assumed that closing the write side of a connection Note: It is assumed that closing the write side of a connection
skipping to change at page 90, line 28 skipping to change at page 90, line 29
bad_record_mac This alert is returned if a record is received which bad_record_mac This alert is returned if a record is received which
cannot be deprotected. Because AEAD algorithms combine decryption cannot be deprotected. Because AEAD algorithms combine decryption
and verification, and also to avoid side channel attacks, this and verification, and also to avoid side channel attacks, this
alert is used for all deprotection failures. This alert should alert is used for all deprotection failures. This alert should
never be observed in communication between proper implementations, never be observed in communication between proper implementations,
except when messages were corrupted in the network. except when messages were corrupted in the network.
record_overflow A TLSCiphertext record was received that had a record_overflow A TLSCiphertext record was received that had a
length more than 2^14 + 256 bytes, or a record decrypted to a length more than 2^14 + 256 bytes, or a record decrypted to a
TLSPlaintext record with more than 2^14 bytes. This alert should TLSPlaintext record with more than 2^14 bytes (or some other
never be observed in communication between proper implementations, negotiated limit). This alert should never be observed in
except when messages were corrupted in the network. communication between proper implementations, except when messages
were corrupted in the network.
handshake_failure Receipt of a "handshake_failure" alert message handshake_failure Receipt of a "handshake_failure" alert message
indicates that the sender was unable to negotiate an acceptable indicates that the sender was unable to negotiate an acceptable
set of security parameters given the options available. set of security parameters given the options available.
bad_certificate A certificate was corrupt, contained signatures that bad_certificate A certificate was corrupt, contained signatures that
did not verify correctly, etc. did not verify correctly, etc.
unsupported_certificate A certificate was of an unsupported type. unsupported_certificate A certificate was of an unsupported type.
skipping to change at page 91, line 41 skipping to change at page 91, line 44
negotiation has failed specifically because the server requires negotiation has failed specifically because the server requires
parameters more secure than those supported by the client. parameters more secure than those supported by the client.
internal_error An internal error unrelated to the peer or the internal_error An internal error unrelated to the peer or the
correctness of the protocol (such as a memory allocation failure) correctness of the protocol (such as a memory allocation failure)
makes it impossible to continue. makes it impossible to continue.
inappropriate_fallback Sent by a server in response to an invalid inappropriate_fallback Sent by a server in response to an invalid
connection retry attempt from a client (see [RFC7507]). connection retry attempt from a client (see [RFC7507]).
missing_extension Sent by endpoints that receive a hello message not missing_extension Sent by endpoints that receive a handshake message
containing an extension that is mandatory to send for the offered not containing an extension that is mandatory to send for the
TLS version or other negotiated parameters. offered TLS version or other negotiated parameters.
unsupported_extension Sent by endpoints receiving any hello message
containing an extension known to be prohibited for inclusion in
the given hello message, or including any extensions in a
ServerHello or Certificate not first offered in the corresponding
ClientHello.
certificate_unobtainable Sent by servers when unable to obtain a unsupported_extension Sent by endpoints receiving any handshake
certificate from a URL provided by the client via the message containing an extension known to be prohibited for
"client_certificate_url" extension (see [RFC6066]). inclusion in the given handshake message, or including any
extensions in a ServerHello or Certificate not first offered in
the corresponding ClientHello.
unrecognized_name Sent by servers when no server exists identified unrecognized_name Sent by servers when no server exists identified
by the name provided by the client via the "server_name" extension by the name provided by the client via the "server_name" extension
(see [RFC6066]). (see [RFC6066]).
bad_certificate_status_response Sent by clients when an invalid or bad_certificate_status_response Sent by clients when an invalid or
unacceptable OCSP response is provided by the server via the unacceptable OCSP response is provided by the server via the
"status_request" extension (see [RFC6066]). "status_request" extension (see [RFC6066]).
bad_certificate_hash_value Sent by servers when a retrieved object
does not have the correct hash provided by the client via the
"client_certificate_url" extension (see [RFC6066]).
unknown_psk_identity Sent by servers when PSK key establishment is unknown_psk_identity Sent by servers when PSK key establishment is
desired but no acceptable PSK identity is provided by the client. desired but no acceptable PSK identity is provided by the client.
Sending this alert is OPTIONAL; servers MAY instead choose to send Sending this alert is OPTIONAL; servers MAY instead choose to send
a "decrypt_error" alert to merely indicate an invalid PSK a "decrypt_error" alert to merely indicate an invalid PSK
identity. identity.
certificate_required Sent by servers when a client certificate is certificate_required Sent by servers when a client certificate is
desired but none was provided by the client. desired but none was provided by the client.
no_application_protocol Sent by servers when a client no_application_protocol Sent by servers when a client
skipping to change at page 93, line 22 skipping to change at page 93, line 22
opaque label<7..255> = "tls13 " + Label; opaque label<7..255> = "tls13 " + Label;
opaque context<0..255> = Context; opaque context<0..255> = Context;
} HkdfLabel; } HkdfLabel;
Derive-Secret(Secret, Label, Messages) = Derive-Secret(Secret, Label, Messages) =
HKDF-Expand-Label(Secret, Label, HKDF-Expand-Label(Secret, Label,
Transcript-Hash(Messages), Hash.length) Transcript-Hash(Messages), Hash.length)
The Hash function used by Transcript-Hash and HKDF is the cipher The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm. Hash.length is its output length in bytes. suite hash algorithm. Hash.length is its output length in bytes.
Messages are the concatenation of the indicated handshake messages, Messages is the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not including the handshake message type and length fields, but not
including record layer headers. Note that in some cases a zero- including record layer headers. Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label. The length Context (indicated by "") is passed to HKDF-Expand-Label. The
Labels specified in this document are all ASCII strings, and do not Labels specified in this document are all ASCII strings, and do not
include a trailing NUL byte. include a trailing NUL byte.
Note: with common hash functions, any label longer than 12 characters Note: with common hash functions, any label longer than 12 characters
requires an additional iteration of the hash function to compute. requires an additional iteration of the hash function to compute.
The labels in this specification have all been chosen to fit within The labels in this specification have all been chosen to fit within
this limit. this limit.
Given a set of n InputSecrets, the final "master secret" is computed Keys are derived from two input secrets using the HKDF-Extract and
by iteratively invoking HKDF-Extract with InputSecret_1, Derive-Secret functions. The general pattern for adding a new secret
InputSecret_2, etc. The initial secret is simply a string of is to use HKDF-Extract with the salt being the current secret state
Hash.length bytes set to zeros. Concretely, for the present version and the IKM being the new secret to be added. In this version of TLS
of TLS 1.3, secrets are added in the following order: 1.3, the two input secrets are:
- PSK (a pre-shared key established externally or derived from the - PSK (a pre-shared key established externally or derived from the
resumption_master_secret value from a previous connection) resumption_master_secret value from a previous connection)
- (EC)DHE shared secret (Section 7.4) - (EC)DHE shared secret (Section 7.4)
This produces a full key derivation schedule shown in the diagram This produces a full key derivation schedule shown in the diagram
below. In this diagram, the following formatting conventions apply: below. In this diagram, the following formatting conventions apply:
- HKDF-Extract is drawn as taking the Salt argument from the top and - HKDF-Extract is drawn as taking the Salt argument from the top and
the IKM argument from the left. the IKM argument from the left, with its output to the bottom and
the name of the output on the right.
- Derive-Secret's Secret argument is indicated by the incoming - Derive-Secret's Secret argument is indicated by the incoming
arrow. For instance, the Early Secret is the Secret for arrow. For instance, the Early Secret is the Secret for
generating the client_early_traffic_secret. generating the client_early_traffic_secret.
- "0" indicates a string of Hash-lengths bytes set to 0.
0 0
| |
v v
PSK -> HKDF-Extract = Early Secret PSK -> HKDF-Extract = Early Secret
| |
+-----> Derive-Secret(., +-----> Derive-Secret(.,
| "ext binder" | | "ext binder" |
| "res binder", | "res binder",
| "") | "")
| = binder_key | = binder_key
skipping to change at page 95, line 40 skipping to change at page 95, line 42
type of PSK for the other. type of PSK for the other.
There are multiple potential Early Secret values depending on which There are multiple potential Early Secret values depending on which
PSK the server ultimately selects. The client will need to compute PSK the server ultimately selects. The client will need to compute
one for each potential PSK; if no PSK is selected, it will then need one for each potential PSK; if no PSK is selected, it will then need
to compute the early secret corresponding to the zero PSK. to compute the early secret corresponding to the zero PSK.
Once all the values which are to be derived from a given secret have Once all the values which are to be derived from a given secret have
been computed, that secret SHOULD be erased. been computed, that secret SHOULD be erased.
7.2. Updating Traffic Keys and IVs 7.2. Updating Traffic Secrets
Once the handshake is complete, it is possible for either side to Once the handshake is complete, it is possible for either side to
update its sending traffic keys using the KeyUpdate handshake message update its sending traffic keys using the KeyUpdate handshake message
defined in Section 4.6.3. The next generation of traffic keys is defined in Section 4.6.3. The next generation of traffic keys is
computed by generating client_/server_application_traffic_secret_N+1 computed by generating client_/server_application_traffic_secret_N+1
from client_/server_application_traffic_secret_N as described in this from client_/server_application_traffic_secret_N as described in this
section then re-deriving the traffic keys as described in section then re-deriving the traffic keys as described in
Section 7.3. Section 7.3.
The next-generation application_traffic_secret is computed as: The next-generation application_traffic_secret is computed as:
skipping to change at page 96, line 23 skipping to change at page 96, line 25
7.3. Traffic Key Calculation 7.3. Traffic Key Calculation
The traffic keying material is generated from the following input The traffic keying material is generated from the following input
values: values:
- A secret value - A secret value
- A purpose value indicating the specific value being generated - A purpose value indicating the specific value being generated
- The length of the key - The length of the key being generated
The traffic keying material is generated from an input traffic secret The traffic keying material is generated from an input traffic secret
value using: value using:
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv" , "", iv_length) [sender]_write_iv = HKDF-Expand-Label(Secret, "iv" , "", iv_length)
[sender] denotes the sending side. The Secret value for each record [sender] denotes the sending side. The Secret value for each record
type is shown in the table below. type is shown in the table below.
skipping to change at page 97, line 4 skipping to change at page 97, line 6
| Handshake | [sender]_handshake_traffic_secret | | Handshake | [sender]_handshake_traffic_secret |
| | | | | |
| Application Data | [sender]_application_traffic_secret_N | | Application Data | [sender]_application_traffic_secret_N |
+-------------------+---------------------------------------+ +-------------------+---------------------------------------+
All the traffic keying material is recomputed whenever the underlying All the traffic keying material is recomputed whenever the underlying
Secret changes (e.g., when changing from the handshake to application Secret changes (e.g., when changing from the handshake to application
data keys or upon a key update). data keys or upon a key update).
7.4. (EC)DHE Shared Secret Calculation 7.4. (EC)DHE Shared Secret Calculation
7.4.1. Finite Field Diffie-Hellman 7.4.1. Finite Field Diffie-Hellman
For finite field groups, a conventional Diffie-Hellman computation is For finite field groups, a conventional Diffie-Hellman [DH76]
performed. The negotiated key (Z) is converted to a byte string by computation is performed. The negotiated key (Z) is converted to a
encoding in big-endian and padded with zeros up to the size of the byte string by encoding in big-endian and left padded with zeros up
prime. This byte string is used as the shared secret in the key to the size of the prime. This byte string is used as the shared
schedule as specified above. secret in the key schedule as specified above.
Note that this construction differs from previous versions of TLS Note that this construction differs from previous versions of TLS
which remove leading zeros. which remove leading zeros.
7.4.2. Elliptic Curve Diffie-Hellman 7.4.2. Elliptic Curve Diffie-Hellman
For secp256r1, secp384r1 and secp521r1, ECDH calculations (including For secp256r1, secp384r1 and secp521r1, ECDH calculations (including
parameter and key generation as well as the shared secret parameter and key generation as well as the shared secret
calculation) are performed according to [IEEE1363] using the ECKAS- calculation) are performed according to [IEEE1363] using the ECKAS-
DH1 scheme with the identity map as key derivation function (KDF), so DH1 scheme with the identity map as key derivation function (KDF), so
skipping to change at page 97, line 50 skipping to change at page 98, line 4
- The ECDH shared secret is the result of applying the ECDH scalar - The ECDH shared secret is the result of applying the ECDH scalar
multiplication function to the secret key (into scalar input) and multiplication function to the secret key (into scalar input) and
the peer's public key (into u-coordinate point input). The output the peer's public key (into u-coordinate point input). The output
is used raw, with no processing. is used raw, with no processing.
For X25519 and X448, implementations SHOULD use the approach For X25519 and X448, implementations SHOULD use the approach
specified in [RFC7748] to calculate the Diffie-Hellman shared secret. specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
Implementations MUST check whether the computed Diffie-Hellman shared Implementations MUST check whether the computed Diffie-Hellman shared
secret is the all-zero value and abort if so, as described in secret is the all-zero value and abort if so, as described in
Section 6 of [RFC7748]. If implementers use an alternative Section 6 of [RFC7748]. If implementors use an alternative
implementation of these elliptic curves, they SHOULD perform the implementation of these elliptic curves, they SHOULD perform the
additional checks specified in Section 7 of [RFC7748]. additional checks specified in Section 7 of [RFC7748].
7.5. Exporters 7.5. Exporters
[RFC5705] defines keying material exporters for TLS in terms of the [RFC5705] defines keying material exporters for TLS in terms of the
TLS pseudorandom function (PRF). This document replaces the PRF with TLS pseudorandom function (PRF). This document replaces the PRF with
HKDF, thus requiring a new construction. The exporter interface HKDF, thus requiring a new construction. The exporter interface
remains the same. remains the same.
skipping to change at page 98, line 25 skipping to change at page 98, line 26
TLS-Exporter(label, context_value, key_length) = TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""), HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length) "exporter", Hash(context_value), key_length)
Where Secret is either the early_exporter_master_secret or the Where Secret is either the early_exporter_master_secret or the
exporter_master_secret. Implementations MUST use the exporter_master_secret. Implementations MUST use the
exporter_master_secret unless explicitly specified by the exporter_master_secret unless explicitly specified by the
application. The early_exporter_master_secret is defined for use in application. The early_exporter_master_secret is defined for use in
settings where an exporter is needed for 0-RTT data. A separate settings where an exporter is needed for 0-RTT data. A separate
interface for the early exporter is RECOMMENDED, especially on a interface for the early exporter is RECOMMENDED; this avoids the
server where a single interface can make the early exporter exporter user accidentally using an early exporter when a regular one
inaccessible. is desired or vice versa.
If no context is provided, the context_value is zero-length. If no context is provided, the context_value is zero-length.
Consequently, providing no context computes the same value as Consequently, providing no context computes the same value as
providing an empty context. This is a change from previous versions providing an empty context. This is a change from previous versions
of TLS where an empty context produced a different output to an of TLS where an empty context produced a different output to an
absent context. As of this document's publication, no allocated absent context. As of this document's publication, no allocated
exporter label is used both with and without a context. Future exporter label is used both with and without a context. Future
specifications MUST NOT define a use of exporters that permit both an specifications MUST NOT define a use of exporters that permit both an
empty context and no context with the same label. New uses of empty context and no context with the same label. New uses of
exporters SHOULD provide a context in all exporter computations, exporters SHOULD provide a context in all exporter computations,
skipping to change at page 100, line 15 skipping to change at page 100, line 15
8.1. Single-Use Tickets 8.1. Single-Use Tickets
The simplest form of anti-replay defense is for the server to only The simplest form of anti-replay defense is for the server to only
allow each session ticket to be used once. For instance, the server allow each session ticket to be used once. For instance, the server
can maintain a database of all outstanding valid tickets; deleting can maintain a database of all outstanding valid tickets; deleting
each ticket from the database as it is used. If an unknown ticket is each ticket from the database as it is used. If an unknown ticket is
provided, the server would then fall back to a full handshake. provided, the server would then fall back to a full handshake.
If the tickets are not self-contained but rather are database keys, If the tickets are not self-contained but rather are database keys,
and the corresponding PSKs are deleted upon use, then connections and the corresponding PSKs are deleted upon use, then connections
established using one PSK enjoy forward secrecy. This improves established using PSKs enjoy forward secrecy. This improves security
security for all 0-RTT data and PSK usage when PSK is used without for all 0-RTT data and PSK usage when PSK is used without (EC)DHE.
(EC)DHE.
Because this mechanism requires sharing the session database between Because this mechanism requires sharing the session database between
server nodes in environments with multiple distributed servers, it server nodes in environments with multiple distributed servers, it
may be hard to achieve high rates of successful PSK 0-RTT connections may be hard to achieve high rates of successful PSK 0-RTT connections
when compared to self-encrypted tickets. Unlike session databases, when compared to self-encrypted tickets. Unlike session databases,
session tickets can successfully do PSK-based session establishment session tickets can successfully do PSK-based session establishment
even without consistent storage, though when 0-RTT is allowed they even without consistent storage, though when 0-RTT is allowed they
still require consistent storage for anti-replay of 0-RTT data, as still require consistent storage for anti-replay of 0-RTT data, as
detailed in the following section. detailed in the following section.
skipping to change at page 101, line 12 skipping to change at page 101, line 12
filters, in which case they MUST respond to apparent replay by filters, in which case they MUST respond to apparent replay by
rejecting 0-RTT but MUST NOT abort the handshake. rejecting 0-RTT but MUST NOT abort the handshake.
The server MUST derive the storage key only from validated sections The server MUST derive the storage key only from validated sections
of the ClientHello. If the ClientHello contains multiple PSK of the ClientHello. If the ClientHello contains multiple PSK
identities, then an attacker can create multiple ClientHellos with identities, then an attacker can create multiple ClientHellos with
different binder values for the less-preferred identity on the different binder values for the less-preferred identity on the
assumption that the server will not verify it, as recommended by assumption that the server will not verify it, as recommended by
Section 4.2.11. I.e., if the client sends PSKs A and B but the Section 4.2.11. I.e., if the client sends PSKs A and B but the
server prefers A, then the attacker can change the binder for B server prefers A, then the attacker can change the binder for B
without affecting the binder for A. This will cause the ClientHello without affecting the binder for A. If the binder for B is part of
to be accepted, and may cause side effects such as replay cache the storage key, then this ClientHello will not appear as a
pollution, although any 0-RTT data will not be decryptable because it duplicate, which will cause the ClientHello to be accepted, and may
will use different keys. If the validated binder or the cause side effects such as replay cache pollution, although any 0-RTT
ClientHello.random are used as the storage key, then this attack is data will not be decryptable because it will use different keys. If
not possible. the validated binder or the ClientHello.random are used as the
storage key, then this attack is not possible.
Because this mechanism does not require storing all outstanding Because this mechanism does not require storing all outstanding
tickets, it may be easier to implement in distributed systems with tickets, it may be easier to implement in distributed systems with
high rates of resumption and 0-RTT, at the cost of potentially weaker high rates of resumption and 0-RTT, at the cost of potentially weaker
anti-replay defense because of the difficulty of reliably storing and anti-replay defense because of the difficulty of reliably storing and
retrieving the received ClientHello messages. In many such systems, retrieving the received ClientHello messages. In many such systems,
it is impractical to have globally consistent storage of all the it is impractical to have globally consistent storage of all the
received ClientHellos. In this case, the best anti-replay protection received ClientHellos. In this case, the best anti-replay protection
is provided by having a single storage zone be authoritative for a is provided by having a single storage zone be authoritative for a
given ticket and refusing 0-RTT for that ticket in any other zone. given ticket and refusing 0-RTT for that ticket in any other zone.
skipping to change at page 102, line 4 skipping to change at page 102, line 5
variant of the second form of attack described above. variant of the second form of attack described above.
8.3. Freshness Checks 8.3. Freshness Checks
Because the ClientHello indicates the time at which the client sent Because the ClientHello indicates the time at which the client sent
it, it is possible to efficiently determine whether a ClientHello was it, it is possible to efficiently determine whether a ClientHello was
likely sent reasonably recently and only accept 0-RTT for such a likely sent reasonably recently and only accept 0-RTT for such a
ClientHello, otherwise falling back to a 1-RTT handshake. This is ClientHello, otherwise falling back to a 1-RTT handshake. This is
necessary for the ClientHello storage mechanism described in necessary for the ClientHello storage mechanism described in
Section 8.2 because otherwise the server needs to store an unlimited Section 8.2 because otherwise the server needs to store an unlimited
number of ClientHellos and is a useful optimization for single-use number of ClientHellos and is a useful optimization for self-
tickets because it allows efficient rejection of ClientHellos which contained single-use tickets because it allows efficient rejection of
cannot be used for 0-RTT. ClientHellos which cannot be used for 0-RTT.
In order to implement this mechanism, a server needs to store the In order to implement this mechanism, a server needs to store the
time that the server generated the session ticket, offset by an time that the server generated the session ticket, offset by an
estimate of the round trip time between client and server. I.e., estimate of the round trip time between client and server. I.e.,
adjusted_creation_time = creation_time + estimated_RTT adjusted_creation_time = creation_time + estimated_RTT
This value can be encoded in the ticket, thus avoiding the need to This value can be encoded in the ticket, thus avoiding the need to
keep state for each outstanding ticket. The server can determine the keep state for each outstanding ticket. The server can determine the
client's view of the age of the ticket by subtracting the ticket's client's view of the age of the ticket by subtracting the ticket's
skipping to change at page 102, line 31 skipping to change at page 102, line 32
expected_arrival_time = adjusted_creation_time + clients_ticket_age expected_arrival_time = adjusted_creation_time + clients_ticket_age
When a new ClientHello is received, the expected_arrival_time is then When a new ClientHello is received, the expected_arrival_time is then
compared against the current server wall clock time and if they compared against the current server wall clock time and if they
differ by more than a certain amount, 0-RTT is rejected, though the differ by more than a certain amount, 0-RTT is rejected, though the
1-RTT handshake can be allowed to complete. 1-RTT handshake can be allowed to complete.
There are several potential sources of error that might cause There are several potential sources of error that might cause
mismatches between the expected arrival time and the measured time. mismatches between the expected arrival time and the measured time.
Variations in client and server clock rates are likely to be minimal, Variations in client and server clock rates are likely to be minimal,
though potentially with gross time corrections. Network propagation though potentially the absolute times may be off by large values.
delays are the most likely causes of a mismatch in legitimate values Network propagation delays are the most likely causes of a mismatch
for elapsed time. Both the NewSessionTicket and ClientHello messages in legitimate values for elapsed time. Both the NewSessionTicket and
might be retransmitted and therefore delayed, which might be hidden ClientHello messages might be retransmitted and therefore delayed,
by TCP. For clients on the Internet, this implies windows on the which might be hidden by TCP. For clients on the Internet, this
order of ten seconds to account for errors in clocks and variations implies windows on the order of ten seconds to account for errors in
in measurements; other deployment scenarios may have different needs. clocks and variations in measurements; other deployment scenarios may
Clock skew distributions are not symmetric, so the optimal tradeoff have different needs. Clock skew distributions are not symmetric, so
may involve an asymmetric range of permissible mismatch values. the optimal tradeoff may involve an asymmetric range of permissible
mismatch values.
Note that freshness checking alone is not sufficient to prevent Note that freshness checking alone is not sufficient to prevent
replays because it does not detect them during the error window, replays because it does not detect them during the error window,
which, depending on bandwidth and system capacity could include which, depending on bandwidth and system capacity could include
billions of replays in real-world settings. In addition, this billions of replays in real-world settings. In addition, this
freshness checking is only done at the time the ClientHello is freshness checking is only done at the time the ClientHello is
received, and not when later early application data records are received, and not when later early application data records are
received. After early data is accepted, records may continue to be received. After early data is accepted, records may continue to be
streamed to the server over a longer time period. streamed to the server over a longer time period.
skipping to change at page 104, line 13 skipping to change at page 104, line 13
or ECDHE key exchange. or ECDHE key exchange.
- "key_share" is REQUIRED for DHE or ECDHE key exchange. - "key_share" is REQUIRED for DHE or ECDHE key exchange.
- "pre_shared_key" is REQUIRED for PSK key agreement. - "pre_shared_key" is REQUIRED for PSK key agreement.
- "psk_key_exchange_modes" is REQUIRED for PSK key agreement. - "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
A client is considered to be attempting to negotiate using this A client is considered to be attempting to negotiate using this
specification if the ClientHello contains a "supported_versions" specification if the ClientHello contains a "supported_versions"
extension with 0x0304 as the highest version number contained in its extension with 0x0304 contained in its body. Such a ClientHello
body. Such a ClientHello message MUST meet the following message MUST meet the following requirements:
requirements:
- If not containing a "pre_shared_key" extension, it MUST contain - If not containing a "pre_shared_key" extension, it MUST contain
both a "signature_algorithms" extension and a "supported_groups" both a "signature_algorithms" extension and a "supported_groups"
extension. extension.
- If containing a "supported_groups" extension, it MUST also contain - If containing a "supported_groups" extension, it MUST also contain
a "key_share" extension, and vice versa. An empty a "key_share" extension, and vice versa. An empty
KeyShare.client_shares vector is permitted. KeyShare.client_shares vector is permitted.
Servers receiving a ClientHello which does not conform to these Servers receiving a ClientHello which does not conform to these
skipping to change at page 104, line 39 skipping to change at page 104, line 38
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 by terminating the connection with lacking a "server_name" extension by terminating the connection with
a "missing_extension" alert. a "missing_extension" alert.
9.3. Protocol Invariants 9.3. Protocol Invariants
This section describes invariants that TLS endpoints and middleboxes This section describes invariants that TLS endpoints and middleboxes
MUST follow. It also applies to earlier versions, which assumed MUST follow. It also applies to earlier versions of TLS.
these rules but did not document them.
TLS is designed to be securely and compatibly extensible. Newer TLS is designed to be securely and compatibly extensible. Newer
clients or servers, when communicating with newer peers, SHOULD clients or servers, when communicating with newer peers, should
negotiate the most preferred common parameters. The TLS handshake negotiate the most preferred common parameters. The TLS handshake
provides downgrade protection: Middleboxes passing traffic between a provides downgrade protection: Middleboxes passing traffic between a
newer client and newer server without terminating TLS should be newer client and newer server without terminating TLS should be
unable to influence the handshake (see Appendix E.1). At the same unable to influence the handshake (see Appendix E.1). At the same
time, deployments update at different rates, so a newer client or time, deployments update at different rates, so a newer client or
server MAY continue to support older parameters, which would allow it server MAY continue to support older parameters, which would allow it
to interoperate with older endpoints. to interoperate with older endpoints.
For this to work, implementations MUST correctly handle extensible For this to work, implementations MUST correctly handle extensible
fields: fields:
skipping to change at page 107, line 22 skipping to change at page 107, line 15
"certificate_authorities", "oid_filters", "post_handshake_auth", "certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_cert", extensions with the values and "signature_algorithms_cert", extensions with the values
defined in this document and the Recommended value of "Yes". defined in this document and the Recommended value of "Yes".
- IANA [SHALL update/has updated] this registry to include a "TLS - IANA [SHALL update/has updated] this registry to include a "TLS
1.3" column which lists the messages in which the extension may 1.3" column which lists the messages in which the extension may
appear. This column [SHALL be/has been] initially populated from appear. This column [SHALL be/has been] initially populated from
the table in Section 4.2 with any extension not listed there the table in Section 4.2 with any extension not listed there
marked as "-" to indicate that it is not used by TLS 1.3. marked as "-" to indicate that it is not used by TLS 1.3.
In addition, this document defines a new registry to be maintained by In addition, this document defines two new registries to be
IANA: maintained by IANA:
- TLS SignatureScheme Registry: Values with the first byte in the - TLS SignatureScheme Registry: Values with the first byte in the
range 0-253 (decimal) are assigned via Specification Required range 0-253 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 254 or 255 (decimal) are [RFC8126]. Values with the first byte 254 or 255 (decimal) are
reserved for Private Use [RFC8126]. Values with the first byte in reserved for Private Use [RFC8126]. Values with the first byte in
the range 0-6 or with the second byte in the range 0-3 that are the range 0-6 or with the second byte in the range 0-3 that are
not currently allocated are reserved for backwards compatibility. not currently allocated are reserved for backwards compatibility.
This registry SHALL have a "Recommended" column. The registry This registry SHALL have a "Recommended" column. The registry
[shall be/ has been] initially populated with the values described [shall be/ has been] initially populated with the values described
in Section 4.2.3. The following values SHALL be marked as in Section 4.2.3. The following values SHALL be marked as
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
ed25519. ed25519.
- TLS PskKeyExchangeMode Registry: Values in the range 0-253
(decimal) are assigned via Specification Required [RFC8126].
Values with the first byte 254 or 255 (decimal) are reserved for
Private Use [RFC8126]. This registry SHALL have a "Recommended"
column. The registry [shall be/ has been] initially populated
psk_ke (0) and psk_dhe_ke (1). Both SHALL be marked as
"Recommended".
12. References 12. References
12.1. Normative References 12.1. Normative References
[DH] Diffie, W. and M. Hellman, "New Directions in [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977. V.IT-22 n.6 , June 1977.
[DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", IEEE Transactions on Information
Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638,
November 1976.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", Operation: Galois/Counter Mode (GCM) and GMAC",
NIST Special Publication 800-38D, November 2007. NIST Special Publication 800-38D, November 2007.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
skipping to change at page 112, line 31 skipping to change at page 112, line 38
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", Proceedings of ACM CCS Pre-shared Key Handshake Protocol", Proceedings of ACM CCS
2015 , 2015, <https://eprint.iacr.org/2015/914>. 2015 , 2015, <https://eprint.iacr.org/2015/914>.
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", TRON 2016 , 2016, Pre-shared Key Handshake Protocol", TRON 2016 , 2016,
<https://eprint.iacr.org/2016/081>. <https://eprint.iacr.org/2016/081>.
[DOW92] Diffie, W., van Oorschot, P., and M. Wiener, [DOW92] Diffie, W., van Oorschot, P., and M. Wiener,
""Authentication and authenticated key exchanges"", "Authentication and authenticated key exchanges", Designs,
Designs, Codes and Cryptography , 1992. Codes and Cryptography , 1992.
[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)", Elliptic Curve Digital Signature Algorithm (ECDSA)",
ANSI ANS X9.62-2005, November 2005. ANSI ANS X9.62-2005, November 2005.
skipping to change at page 115, line 26 skipping to change at page 115, line 36
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006, <https://www.rfc- DOI 10.17487/RFC4492, May 2006, <https://www.rfc-
editor.org/info/rfc4492>. editor.org/info/rfc4492>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://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, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, <https://www.rfc- DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
editor.org/info/rfc5764>. editor.org/info/rfc5764>.
skipping to change at page 119, line 50 skipping to change at page 119, line 50
| | | Recv | | | Recv
| v | CertificateVerify | v | CertificateVerify
+-> WAIT_FINISHED <---+ +-> WAIT_FINISHED <---+
| Recv Finished | Recv Finished
| K_recv = application | K_recv = application
v v
CONNECTED CONNECTED
Appendix B. Protocol Data Structures and Constant Values Appendix B. Protocol Data Structures and Constant Values
This section describes protocol types and constants. Values listed This section provides the normative protocol types and constants
as _RESERVED were used in previous versions of TLS and are listed definitions. Values listed as _RESERVED were used in previous
here for completeness. TLS 1.3 implementations MUST NOT send them versions of TLS and are listed here for completeness. TLS 1.3
but might receive them from older TLS implementations. implementations MUST NOT send them but might receive them from older
TLS implementations.
B.1. Record Layer B.1. Record Layer
enum { enum {
invalid(0), invalid(0),
change_cipher_spec(20), change_cipher_spec(20),
alert(21), alert(21),
handshake(22), handshake(22),
application_data(23), application_data(23),
(255) (255)
skipping to change at page 121, line 34 skipping to change at page 121, line 34
decrypt_error(51), decrypt_error(51),
export_restriction_RESERVED(60), export_restriction_RESERVED(60),
protocol_version(70), protocol_version(70),
insufficient_security(71), insufficient_security(71),
internal_error(80), internal_error(80),
inappropriate_fallback(86), inappropriate_fallback(86),
user_canceled(90), user_canceled(90),
no_renegotiation_RESERVED(100), no_renegotiation_RESERVED(100),
missing_extension(109), missing_extension(109),
unsupported_extension(110), unsupported_extension(110),
certificate_unobtainable(111), certificate_unobtainable_RESERVED(111),
unrecognized_name(112), unrecognized_name(112),
bad_certificate_status_response(113), bad_certificate_status_response(113),
bad_certificate_hash_value(114), bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115), unknown_psk_identity(115),
certificate_required(116), certificate_required(116),
no_application_protocol(120), no_application_protocol(120),
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
skipping to change at page 129, line 4 skipping to change at page 129, line 4
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>; Extension extensions<2..2^16-1>;
} CertificateRequest; } CertificateRequest;
B.3.3. Authentication Messages B.3.3. Authentication Messages
/* Managed by IANA */
enum { enum {
X509(0), X509(0),
OpenPGP_RESERVED(1), OpenPGP_RESERVED(1),
RawPublicKey(2), RawPublicKey(2),
(255) (255)
} CertificateType; } CertificateType;
struct { struct {
select (certificate_type) { select (certificate_type) {
case RawPublicKey: case RawPublicKey:
skipping to change at page 134, line 37 skipping to change at page 134, line 37
application profile. application profile.
Appendix D. Backward Compatibility Appendix D. Backward Compatibility
The TLS protocol provides a built-in mechanism for version The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different negotiation between endpoints potentially supporting different
versions of TLS. versions of TLS.
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and and there is at least the ClientHello format remains compatible and there is at least one
one protocol version supported by both the client and the server. protocol version supported by both the client and the server.
Prior versions of TLS used the record layer version number for Prior versions of TLS used the record layer version number
various purposes. (TLSPlaintext.legacy_record_version and (TLSPlaintext.legacy_record_version and
TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is TLSCiphertext.legacy_record_version) for various purposes. As of TLS
deprecated. The value of TLSPlaintext.legacy_record_version MUST be 1.3, this field is deprecated. The value of
ignored by all implementations. The value of TLSPlaintext.legacy_record_version MUST be ignored by all
TLSCiphertext.legacy_record_version is included in the additional implementations. The value of TLSCiphertext.legacy_record_version is
data for deprotection but MAY otherwise be ignored or MAY be included in the additional data for deprotection but MAY otherwise be
validated to match the fixed constant value. Version negotiation is ignored or MAY be validated to match the fixed constant value.
performed using only the handshake versions Version negotiation is performed using only the handshake versions
(ClientHello.legacy_version, ServerHello.legacy_version, as well as (ClientHello.legacy_version, ServerHello.legacy_version, as well as
the ClientHello, HelloRetryRequest and ServerHello the ClientHello, HelloRetryRequest and ServerHello
"supported_versions" extensions). In order to maximize "supported_versions" extensions). In order to maximize
interoperability with older endpoints, implementations that negotiate interoperability with older endpoints, implementations that negotiate
the use of TLS 1.0-1.2 SHOULD set the record layer version number to 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 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
skipping to change at page 137, line 44 skipping to change at page 137, line 44
The security of RC4 cipher suites is considered insufficient for the The security of RC4 cipher suites is considered insufficient for the
reasons cited in [RFC7465]. Implementations MUST NOT offer or reasons cited in [RFC7465]. Implementations MUST NOT offer or
negotiate RC4 cipher suites for any version of TLS for any reason. negotiate RC4 cipher suites for any version of TLS for any reason.
Old versions of TLS permitted the use of very low strength ciphers. Old versions of TLS permitted the use of very low strength ciphers.
Ciphers with a strength less than 112 bits MUST NOT be offered or Ciphers with a strength less than 112 bits MUST NOT be offered or
negotiated for any version of TLS for any reason. negotiated for any version of TLS for any reason.
The security of SSL 3.0 [SSL3] is considered insufficient for the The security of SSL 3.0 [SSL3] is considered insufficient for the
reasons enumerated in [RFC7568], and MUST NOT be negotiated for any reasons enumerated in [RFC7568], and it MUST NOT be negotiated for
reason. any reason.
The security of SSL 2.0 [SSL2] is considered insufficient for the The security of SSL 2.0 [SSL2] is considered insufficient for the
reasons enumerated in [RFC6176], and MUST NOT be negotiated for any reasons enumerated in [RFC6176], and it MUST NOT be negotiated for
reason. any reason.
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS. order to negotiate older versions of TLS.
Implementations MUST NOT send a ClientHello.legacy_version or Implementations MUST NOT send a ClientHello.legacy_version or
ServerHello.legacy_version set to 0x0300 or less. Any endpoint ServerHello.legacy_version set to 0x0300 or less. Any endpoint
receiving a Hello message with ClientHello.legacy_version or receiving a Hello message with ClientHello.legacy_version or
skipping to change at page 139, line 26 skipping to change at page 139, line 26
session keys with the server, but those session keys are distinct session keys with the server, but those session keys are distinct
from those established by the client. from those established by the client.
Peer Authentication. The client's view of the peer identity should Peer Authentication. The client's view of the peer identity should
reflect the server's identity. If the client is authenticated, reflect the server's identity. If the client is authenticated,
the server's view of the peer identity should match the client's the server's view of the peer identity should match the client's
identity. identity.
Uniqueness of the session keys: Any two distinct handshakes should Uniqueness of the session keys: Any two distinct handshakes should
produce distinct, unrelated session keys. Individual session keys produce distinct, unrelated session keys. Individual session keys
produced by a handshake should also be distinct and unrelated. produced by a handshake should also be distinct and independent.
Downgrade protection. The cryptographic parameters should be the Downgrade protection. The cryptographic parameters should be the
same on both sides and should be the same as if the peers had been same on both sides and should be the same as if the peers had been
communicating in the absence of an attack (See [BBFKZG16]; defns 8 communicating in the absence of an attack (See [BBFKZG16]; defns 8
and 9}). and 9}).
Forward secret with respect to long-term keys If the long-term Forward secret with respect to long-term keys If the long-term
keying material (in this case the signature keys in certificate- keying material (in this case the signature keys in certificate-
based authentication modes or the external/resumption PSK in PSK based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) is compromised after the handshake is with (EC)DHE modes) is compromised after the handshake is
skipping to change at page 140, line 34 skipping to change at page 140, line 34
connection N, thus providing forward secrecy between the connections. connection N, thus providing forward secrecy between the connections.
In addition, if multiple tickets are established on the same In addition, if multiple tickets are established on the same
connection, they are associated with different keys, so compromise of connection, they are associated with different keys, so compromise of
the PSK associated with one ticket does not lead to the compromise of the PSK associated with one ticket does not lead to the compromise of
connections established with PSKs associated with other tickets. connections established with PSKs associated with other tickets.
This property is most interesting if tickets are stored in a database This property is most interesting if tickets are stored in a database
(and so can be deleted) rather than if they are self-encrypted. (and so can be deleted) rather than if they are self-encrypted.
The PSK binder value forms a binding between a PSK and the current The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was handshake, as well as between the session where the PSK was
established and the session where it was used. This binding established and the current session. This binding transitively
transitively includes the original handshake transcript, because that includes the original handshake transcript, because that transcript
transcript is digested into the values which produce the Resumption is digested into the values which produce the Resumption Master
Master Secret. This requires that both the KDF used to produce the Secret. This requires that both the KDF used to produce the
resumption master secret and the MAC used to compute the binder be resumption master secret and the MAC used to compute the binder be
collision resistant. See Appendix E.1.1 for more on this. Note: The collision resistant. See Appendix E.1.1 for more on this. Note: The
binder does not cover the binder values from other PSKs, though they binder does not cover the binder values from other PSKs, though they
are included in the Finished MAC. are included in the Finished MAC.
Note: TLS does not currently permit the server to send a Note: TLS does not currently permit the server to send a
certificate_request message in non-certificate-based handshakes certificate_request message in non-certificate-based handshakes
(e.g., PSK). If this restriction were to be relaxed in future, the (e.g., PSK). If this restriction were to be relaxed in future, the
client's signature would not cover the server's certificate directly. client's signature would not cover the server's certificate directly.
However, if the PSK was established through a NewSessionTicket, the However, if the PSK was established through a NewSessionTicket, the
skipping to change at page 142, line 41 skipping to change at page 142, line 41
one to whom the original client delegated the traffic key (assuming one to whom the original client delegated the traffic key (assuming
that the traffic key has not been compromised). that the traffic key has not been compromised).
E.1.3. 0-RTT E.1.3. 0-RTT
The 0-RTT mode of operation generally provides similar security The 0-RTT mode of operation generally provides similar security
properties as 1-RTT data, with the two exceptions that the 0-RTT properties as 1-RTT data, with the two exceptions that the 0-RTT
encryption keys do not provide full forward secrecy and that the encryption keys do not provide full forward secrecy and that the
server is not able to guarantee uniqueness of the handshake (non- server is not able to guarantee uniqueness of the handshake (non-
replayability) without keeping potentially undue amounts of state. replayability) without keeping potentially undue amounts of state.
See Section 4.2.10 for one mechanism to limit the exposure to replay. See Section 8 for mechanisms to limit the exposure to replay.
E.1.4. Exporter Independence E.1.4. Exporter Independence
The exporter_master_secret and early_exporter_master_secret are The exporter_master_secret and early_exporter_master_secret are
derived to be independent of the traffic keys and therefore do not derived to be independent of the traffic keys and therefore do not
represent a threat to the security of traffic encrypted with those represent a threat to the security of traffic encrypted with those
keys. However, because these secrets can be used to compute any keys. However, because these secrets can be used to compute any
exporter value, they SHOULD be erased as soon as possible. If the exporter value, they SHOULD be erased as soon as possible. If the
total set of exporter labels is known, then implementations SHOULD total set of exporter labels is known, then implementations SHOULD
pre-compute the inner Derive-Secret stage of the exporter computation pre-compute the inner Derive-Secret stage of the exporter computation
skipping to change at page 146, line 29 skipping to change at page 146, line 29
- Attackers can store and replay 0-RTT messages in order to re-order - Attackers can store and replay 0-RTT messages in order to re-order
them with respect to other messages (e.g., moving a delete to them with respect to other messages (e.g., moving a delete to
after a create). after a create).
- Exploiting cache timing behavior to discover the content of 0-RTT - Exploiting cache timing behavior to discover the content of 0-RTT
messages by replaying a 0-RTT message to a different cache node messages by replaying a 0-RTT message to a different cache node
and then using a separate connection to measure request latency, and then using a separate connection to measure request latency,
to see if the two requests address the same resource. to see if the two requests address the same resource.
If data can be replayed a large number of times, additional attacks If data can be replayed a large number of times, additional attacks
become possible, such as making repeated measurements of the the become possible, such as making repeated measurements of the speed of
speed of cryptographic operations. In addition, they may be able to cryptographic operations. In addition, they may be able to overload
overload rate-limiting systems. For further description of these rate-limiting systems. For further description of these attacks, see
attacks, see [Mac17]. [Mac17].
Ultimately, servers have the responsibility to protect themselves Ultimately, servers have the responsibility to protect themselves
against attacks employing 0-RTT data replication. The mechanisms against attacks employing 0-RTT data replication. The mechanisms
described in Section 8 are intended to prevent replay at the TLS described in Section 8 are intended to prevent replay at the TLS
layer but do not provide complete protection against receiving layer but do not provide complete protection against receiving
multiple copies of client data. TLS 1.3 falls back to the 1-RTT multiple copies of client data. TLS 1.3 falls back to the 1-RTT
handshake when the server does not have any information about the handshake when the server does not have any information about the
client, e.g., because it is in a different cluster which does not client, e.g., because it is in a different cluster which does not
share state or because the ticket has been deleted as described in share state or because the ticket has been deleted as described in
Section 8.1. If the application layer protocol retransmits data in Section 8.1. If the application layer protocol retransmits data in
skipping to change at page 149, line 45 skipping to change at page 149, line 45
- Katriel Cohn-Gordon - Katriel Cohn-Gordon
University of Oxford University of Oxford
me@katriel.co.uk me@katriel.co.uk
- Cas Cremers - Cas Cremers
University of Oxford University of Oxford
cas.cremers@cs.ox.ac.uk cas.cremers@cs.ox.ac.uk
- Antoine Delignat-Lavaud (co-author of [RFC7627]) - Antoine Delignat-Lavaud (co-author of [RFC7627])
INRIA INRIA
antoine.delignat-lavaud@inria.fr antdl@microsoft.com
- Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) - Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
Independent Independent
tim@dierks.org tim@dierks.org
- Roelof DuToit - Roelof DuToit
Symantec Corporation Symantec Corporation
roelof_dutoit@symantec.com roelof_dutoit@symantec.com
- Taher Elgamal - Taher Elgamal
skipping to change at page 151, line 22 skipping to change at page 151, line 22
- David Hopwood - David Hopwood
Independent Consultant Independent Consultant
david.hopwood@blueyonder.co.uk david.hopwood@blueyonder.co.uk
- Marko Horvat - Marko Horvat
MPI-SWS MPI-SWS
mhorvat@mpi-sws.org mhorvat@mpi-sws.org
- Jonathan Hoyland - Jonathan Hoyland
Royal Holloway, University of London Royal Holloway, University of London jonathan.hoyland@gmail.com
- Subodh Iyengar - Subodh Iyengar
Facebook Facebook
subodh@fb.com subodh@fb.com
- Benjamin Kaduk - Benjamin Kaduk
Akamai Akamai
kaduk@mit.edu kaduk@mit.edu
- Hubert Kario - Hubert Kario
skipping to change at page 152, line 35 skipping to change at page 152, line 35
- Carl Mehner - Carl Mehner
USAA USAA
carl.mehner@usaa.com carl.mehner@usaa.com
- Jan Mikkelsen - Jan Mikkelsen
Transactionware Transactionware
janm@transactionware.com janm@transactionware.com
- Bodo Moeller (co-author of [RFC4492]) - Bodo Moeller (co-author of [RFC4492])
Google Google
bodo@openssl.org bodo@acm.org
- Kyle Nekritz - Kyle Nekritz
Facebook Facebook
knekritz@fb.com knekritz@fb.com
- Erik Nygren - Erik Nygren
Akamai Technologies Akamai Technologies
erik+ietf@nygren.org erik+ietf@nygren.org
- Magnus Nystrom - Magnus Nystrom
 End of changes. 166 change blocks. 
432 lines changed or deleted 494 lines changed or added

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