draft-ietf-tls-tls13-21.txt   draft-ietf-tls-tls13-22.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246 (if approved) July 03, 2017 Obsoletes: 5077, 5246 (if approved) November 29, 2017
Updates: 4492, 5705, 6066, 6961 (if Updates: 4492, 5705, 6066, 6961 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 4, 2018 Expires: June 2, 2018
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-21 draft-ietf-tls-tls13-22
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.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on June 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 24 skipping to change at page 2, line 24
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6
1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 14 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 15
1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 16 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 16
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 19 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 20 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21
2.3. Zero-RTT Data . . . . . . . . . . . . . . . . . . . . . . 22 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 24 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 24 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 24 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 27 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28
3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 27 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 28 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 29 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 30 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 31 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 34 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 35 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 37 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 40 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 42 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44
4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 45 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 47
4.2.5. Post-Handshake Client Authentication . . . . . . . . 47 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 48
4.2.6. Negotiated Groups . . . . . . . . . . . . . . . . . . 47 4.2.6. Post-Handshake Client Authentication . . . . . . . . 49
4.2.7. Key Share . . . . . . . . . . . . . . . . . . . . . . 48 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 49
4.2.8. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 52 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 51
4.2.9. Early Data Indication . . . . . . . . . . . . . . . . 52 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 54
4.2.10. Pre-Shared Key Extension . . . . . . . . . . . . . . 55 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 54
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 58 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 57
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 58 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 61
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 59 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 61
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 59 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 62
4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 61 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 62
4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 62 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 64
4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 66 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 65
4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 68 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 70
4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 70 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 72
4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 70 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 73
4.6.1. New Session Ticket Message . . . . . . . . . . . . . 70 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 74
4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 72 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 74
4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 73 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 76
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 74 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 77
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 74 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 78
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 76 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 79
5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 78 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 81
5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 79 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 83
5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 80 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 83
6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 80 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 85
6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 82 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 85
6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 83 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 86
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 85 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 87
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 86 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 90
7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 88 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 90
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 89 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 93
7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 90 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 94
7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 90 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 94
7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 90 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 95
7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 91 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 95
8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 91 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 96
8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 92 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 96
8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 93 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 98
8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 94 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 98
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 95 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 99
9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 95 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 101
9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 96 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 101
10. Security Considerations . . . . . . . . . . . . . . . . . . . 97 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 101
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 102
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102
12.1. Normative References . . . . . . . . . . . . . . . . . . 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.2. Informative References . . . . . . . . . . . . . . . . . 101 12.1. Normative References . . . . . . . . . . . . . . . . . . 104
Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 108 12.2. Informative References . . . . . . . . . . . . . . . . . 106
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 108 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 114
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 114
Appendix B. Protocol Data Structures and Constant Values . . . . 109 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 110 Appendix B. Protocol Data Structures and Constant Values . . . . 115
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 110 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 116
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 112 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 116
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 112 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 118
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 117 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 118
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 118 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 123
B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 119 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 124
B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 119 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 125
B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 120 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 125
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 121 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 126
C.1. Random Number Generation and Seeding . . . . . . . . . . 121 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 127
C.2. Certificates and Authentication . . . . . . . . . . . . . 121 C.1. Random Number Generation and Seeding . . . . . . . . . . 127
C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 121 C.2. Certificates and Authentication . . . . . . . . . . . . . 128
C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 123 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 128
C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 123 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 129
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 124 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 130
D.1. Negotiating with an older server . . . . . . . . . . . . 124 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 130
D.2. Negotiating with an older client . . . . . . . . . . . . 125 D.1. Negotiating with an older server . . . . . . . . . . . . 131
D.3. Zero-RTT backwards compatibility . . . . . . . . . . . . 125 D.2. Negotiating with an older client . . . . . . . . . . . . 132
D.4. Backwards Compatibility Security Restrictions . . . . . . 126 D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 132
Appendix E. Overview of Security Properties . . . . . . . . . . 127 D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 132
E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 127 D.5. Backwards Compatibility Security Restrictions . . . . . . 133
E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 130 Appendix E. Overview of Security Properties . . . . . . . . . . 134
E.1.2. Client Authentication . . . . . . . . . . . . . . . . 131 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 134
E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 131 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 137
E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 131 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 138
E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 131 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 138
E.1.6. External References . . . . . . . . . . . . . . . . . 132 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 138
E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 132 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 139
E.2.1. External References . . . . . . . . . . . . . . . . . 133 E.1.6. External References . . . . . . . . . . . . . . . . . 139
E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 133 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 139
E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 134 E.2.1. External References . . . . . . . . . . . . . . . . . 140
E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 134 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 140
E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 136 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 141
Appendix F. Working Group Information . . . . . . . . . . . . . 136 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 142
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 136 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 143
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 143 Appendix F. Working Group Information . . . . . . . . . . . . . 143
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 144
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150
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.
skipping to change at page 5, line 17 skipping to change at page 5, line 19
following properties: 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 agains records in order to obscure lengths and improve protection against
traffic analysis techniques. traffic analysis techniques.
- Integrity: Data sent over the channel after establishment cannot - Integrity: Data sent over the channel after establishment cannot
be modified by attackers. be modified by attackers.
These properties should be true even in the face of an attacker who These properties should be true even in the face of an attacker who
has complete control of the network, as described in [RFC3552]. See has complete control of the network, as described in [RFC3552]. See
Appendix E for a more complete statement of the relevant security Appendix E for a more complete statement of the relevant security
properties. properties.
skipping to change at page 6, line 11 skipping to change at page 6, line 14
This document defines TLS version 1.3. While TLS 1.3 is not directly This document defines TLS version 1.3. While TLS 1.3 is not directly
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.6 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
skipping to change at page 7, line 5 skipping to change at page 7, line 8
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-22 - Implement changes for improved middlebox penetration (*)
- Move server_certificate_type to encrypted extensions (*)
- Allow resumption with a different SNI (*)
- Padding extension can change on HRR (*)
- Allow an empty ticket_nonce (*)
- Remove requirement to immediately respond to close_notify with
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 13, line 5 skipping to change at page 13, line 22
- 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 15, line 13 skipping to change at page 15, line 29
are many minor differences. are many minor differences.
- The list of supported symmetric algorithms has been pruned of all - The list of supported symmetric algorithms has been pruned of all
algorithms that are considered legacy. Those that remain all use algorithms that are considered legacy. Those that remain all use
Authenticated Encryption with Associated Data (AEAD) algorithms. Authenticated Encryption with Associated Data (AEAD) algorithms.
The ciphersuite concept has been changed to separate the The ciphersuite concept has been changed to separate the
authentication and key exchange mechanisms from the record authentication and key exchange mechanisms from the record
protection algorithm (including secret key length) and a hash to protection algorithm (including secret key length) and a hash to
be used with the key derivation function and HMAC. be used with the key derivation function and HMAC.
- A Zero-RTT mode was added, saving a round-trip at connection setup - A 0-RTT mode was added, saving a round-trip at connection setup
for some application data, at the cost of certain security for some application data, at the cost of certain security
properties. properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all - Static RSA and Diffie-Hellman cipher suites have been removed; all
public-key based key exchange mechanisms now provide forward public-key based key exchange mechanisms now provide forward
secrecy. secrecy.
- All handshake messages after the ServerHello are now encrypted. - All handshake messages after the ServerHello are now encrypted.
The newly introduced EncryptedExtension message allows various The newly introduced EncryptedExtension message allows various
extensions previously sent in clear in the ServerHello to also extensions previously sent in clear in the ServerHello to also
enjoy confidentiality protection. 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.
- ECC is now in the base spec and includes new signature algorithms, - Elliptic curve algorithms are now in the base spec and includes
such as ed25519 and ed448. TLS 1.3 removed point format new signature algorithms, such as ed25519 and ed448. TLS 1.3
negotiation in favor of a single point format for each curve. removed point format negotiation in favor of a single 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. 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 servers which incorrectly implemented version
negotiation. negotiation.
skipping to change at page 18, line 9 skipping to change at page 19, line 9
the client is authenticated, application layer protocol support, the client is authenticated, application layer protocol support,
etc.). etc.).
- 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.7), 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.10) 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.
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 which MUST be in the same
group as one of the client's shares. If PSK key establishment is in group as one of the client's shares. If PSK key establishment is in
skipping to change at page 19, line 20 skipping to change at page 20, line 20
Finished: a MAC (Message Authentication Code) over the entire Finished: a MAC (Message Authentication Code) over the entire
handshake. This message provides key confirmation, binds the handshake. This message provides key confirmation, binds the
endpoint's identity to the exchanged keys, and in PSK mode also endpoint's identity to the exchanged keys, and in PSK mode also
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
must derive the keying material required by the record layer to derive the keying material required by the record layer to exchange
exchange application-layer data protected through authenticated application-layer data protected through authenticated encryption.
encryption. Application data MUST NOT be sent prior to sending the Application data MUST NOT be sent prior to sending the Finished
Finished message and until the record layer starts using encryption message and until the record layer starts using encryption keys.
keys. Note that while the server may send application data prior to Note that while the server may send application data prior to
receiving the client's Authentication messages, any data sent at that receiving the client's Authentication messages, any data sent at that
point is, of course, being sent to an unauthenticated peer. point is, of course, 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
skipping to change at page 21, line 35 skipping to change at page 22, line 35
<-------- [Application Data*] <-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
<-------- [NewSessionTicket] <-------- [NewSessionTicket]
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Subsequent Handshake: Subsequent Handshake:
ClientHello ClientHello
+ key_share* + key_share*
+ psk_key_exchange_modes
+ pre_shared_key --------> + pre_shared_key -------->
ServerHello ServerHello
+ pre_shared_key + pre_shared_key
+ key_share* + key_share*
{EncryptedExtensions} {EncryptedExtensions}
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
skipping to change at page 22, line 11 skipping to change at page 23, line 10
Certificate or a CertificateVerify message. When a client offers Certificate or a CertificateVerify message. When a client offers
resumption via PSK, it SHOULD also supply a "key_share" extension to resumption via PSK, it SHOULD also supply a "key_share" extension to
the server to allow the server to decline resumption and fall back to the server to allow the server to decline resumption and fall back to
a full handshake, if needed. The server responds with a a full handshake, if needed. The server responds with a
"pre_shared_key" extension to negotiate use of PSK key establishment "pre_shared_key" extension to negotiate use of PSK key establishment
and can (as shown here) respond with a "key_share" extension to do and can (as shown here) respond with a "key_share" extension to do
(EC)DHE key establishment, thus providing forward secrecy. (EC)DHE key establishment, thus providing forward secrecy.
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
critical consideration is using sufficient entropy during the key
generation, as discussed in [RFC4086]. Deriving a shared secret from
a password or other low-entropy sources is not secure. A low-entropy
secret, or password, is subject to dictionary attacks based on the
PSK binder. The specified PSK authentication is not a strong
password-based authenticated key exchange even when used with Diffie-
Hellman key establishment.
2.3. Zero-RTT Data Note: When using an out-of-band provisioned pre-shared secret, a
critical consideration is using sufficient entropy during the key
generation, as discussed in [RFC4086]. Deriving a shared secret
from a password or other low-entropy sources is not secure. A
low-entropy secret, or password, is subject to dictionary attacks
based on the PSK binder. The specified PSK authentication is not
a strong password-based authenticated key exchange even when used
with Diffie-Hellman key establishment.
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.
When clients use a PSK obtained externally to send early data, then
the following additional information MUST be provisioned to both
parties:
- The TLS version number for use with this PSK
- The cipher suite for use with this PSK
- The Application-Layer Protocol Negotiation (ALPN) protocol
[RFC7301], if any is to be used
- The Server Name Indication (SNI), if any is to be used
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 with 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
skipping to change at page 24, line 45 skipping to change at page 25, line 45
3.2. Miscellaneous 3.2. Miscellaneous
Comments begin with "/*" and end with "*/". Comments begin with "/*" and end with "*/".
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:
T T';
3.3. Vectors 3.3. 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 27, line 24 skipping to change at page 28, line 30
Structure types may be constructed from primitive types for Structure types may be constructed from primitive types for
convenience. Each specification declares a new, unique type. The convenience. Each specification declares a new, unique type. The
syntax for definition is much like that of C. syntax for definition is much like that of C.
struct { struct {
T1 f1; T1 f1;
T2 f2; T2 f2;
... ...
Tn fn; Tn fn;
} [[T]]; } T;
Fixed- and variable-length vector fields are allowed using the
standard vector syntax. Structures V1 and V2 in the variants example
below demonstrate this.
The fields within a structure may be qualified using the type's name, The fields within a structure may be qualified using the type's name,
with a syntax much like that available for enumerateds. For example, with a syntax much like that available for enumerateds. For example,
T.f2 refers to the second field of the previous declaration. T.f2 refers to the second field of the previous declaration.
Structure definitions may be embedded. Anonymous structs may also be
defined inside other structures.
3.7. Constants 3.7. Constants
Fields and variables may be assigned a fixed value using "=", as in: Fields and variables may be assigned a fixed value using "=", as in:
struct { struct {
T1 f1 = 8; /* T.f1 must always be 8 */ T1 f1 = 8; /* T.f1 must always be 8 */
T2 f2; T2 f2;
} T; } T;
3.8. Variants 3.8. Variants
Defined structures may have variants based on some knowledge that is Defined structures may have variants based on some knowledge that is
available within the environment. The selector must be an enumerated available within the environment. The selector must be an enumerated
type that defines the possible variants the structure defines. The type that defines the possible variants the structure defines. Each
body of the variant structure may be given a label for reference. arm of the select specifies the type of that variant's field and an
The mechanism by which the variant is selected at runtime is not optional field label. The mechanism by which the variant is selected
prescribed by the presentation language. at runtime is not prescribed by the presentation language.
struct { struct {
T1 f1; T1 f1;
T2 f2; T2 f2;
.... ....
Tn fn; Tn fn;
select (E) { select (E) {
case e1: Te1; case e1: Te1 [[fe1]];
case e2: Te2; case e2: Te2 [[fe2]];
.... ....
case en: Ten; case en: Ten [[fen]];
} [[fv]]; };
} [[Tv]]; } Tv;
For example: For example:
enum { apple(0), orange(1) } VariantTag; enum { apple(0), orange(1) } VariantTag;
struct { struct {
uint16 number; uint16 number;
opaque string<0..10>; /* variable length */ opaque string<0..10>; /* variable length */
} V1; } V1;
skipping to change at page 29, line 10 skipping to change at page 30, line 18
of a connection. Handshake messages are supplied to the TLS record of a connection. Handshake messages are supplied to the TLS record
layer, where they are encapsulated within one or more TLSPlaintext or layer, where they are encapsulated within one or more TLSPlaintext or
TLSCiphertext structures, which are processed and transmitted as TLSCiphertext structures, which are processed and transmitted as
specified by the current active connection state. specified by the current active connection state.
enum { enum {
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
new_session_ticket(4), new_session_ticket(4),
end_of_early_data(5), end_of_early_data(5),
hello_retry_request(6),
encrypted_extensions(8), encrypted_extensions(8),
certificate(11), certificate(11),
certificate_request(13), certificate_request(13),
certificate_verify(15), certificate_verify(15),
finished(20), finished(20),
key_update(24), key_update(24),
message_hash(254), message_hash(254),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case hello_retry_request: HelloRetryRequest;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
} body; };
} Handshake; } Handshake;
Protocol messages MUST be sent in the order defined in Section 4.4.1 Protocol messages MUST be sent in the order defined in Section 4.4.1
and shown in the diagrams in Section 2. A peer which receives a and shown in the diagrams in Section 2. A peer which receives a
handshake message in an unexpected order MUST abort the handshake handshake message in an unexpected order MUST abort the handshake
with an "unexpected_message" alert. with an "unexpected_message" alert.
New handshake message types are assigned by IANA as described in New handshake message types are assigned by IANA as described in
Section 11. Section 11.
skipping to change at page 30, line 13 skipping to change at page 31, line 20
handshake and the data. handshake and the data.
4.1.1. Cryptographic Negotiation 4.1.1. Cryptographic Negotiation
In TLS, the cryptographic negotiation proceeds by the client offering In TLS, the cryptographic negotiation proceeds by the client offering
the following four sets of options in its ClientHello: the following four sets of options in its ClientHello:
- A list of cipher suites which indicates the AEAD algorithm/HKDF - A list of cipher suites which indicates the AEAD algorithm/HKDF
hash pairs which the client supports. hash pairs which the client supports.
- A "supported_groups" (Section 4.2.6) extension which indicates the - A "supported_groups" (Section 4.2.7) extension which indicates the
(EC)DHE groups which the client supports and a "key_share" (EC)DHE groups which the client supports and a "key_share"
(Section 4.2.7) extension which contains (EC)DHE shares for some (Section 4.2.8) extension which contains (EC)DHE shares for some
or all of these groups. or all of these groups.
- A "signature_algorithms" (Section 4.2.3) extension which indicates - A "signature_algorithms" (Section 4.2.3) extension which indicates
the signature algorithms which the client can accept. the signature algorithms which the client can accept.
- A "pre_shared_key" (Section 4.2.10) extension which contains a - A "pre_shared_key" (Section 4.2.11) extension which contains a
list of symmetric key identities known to the client and a list of symmetric key identities known to the client and a
"psk_key_exchange_modes" (Section 4.2.8) extension which indicates "psk_key_exchange_modes" (Section 4.2.9) extension which indicates
the key exchange modes that may be used with PSKs. the key exchange modes that may be used with PSKs.
If the server does not select a PSK, then the first three of these If the server does not select a PSK, then the first three of these
options are entirely orthogonal: the server independently selects a options are entirely orthogonal: the server independently selects a
cipher suite, an (EC)DHE group and key share for key establishment, cipher suite, an (EC)DHE group and key share for key establishment,
and a signature algorithm/certificate pair to authenticate itself to and a signature algorithm/certificate pair to authenticate itself to
the client. If there is no overlap between the received the client. If there is no overlap between the received
"supported_groups" and the groups supported by the server then the "supported_groups" and the groups supported by the server then the
server MUST abort the handshake with a "handshake_failure" or an server MUST abort the handshake with a "handshake_failure" or an
"insufficient_security" alert. "insufficient_security" alert.
skipping to change at page 31, line 34 skipping to change at page 32, line 41
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 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.9) 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
"padding" extension [RFC7685].
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 32, line 38 skipping to change at page 33, line 50
"supported_versions" extension (Section 4.2.1) and the "supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. (See Appendix D for details about backward number for TLS 1.2. (See Appendix D for details about backward
compatibility.) compatibility.)
random 32 bytes generated by a secure random number generator. See random 32 bytes generated by a secure random number generator. See
Appendix C for additional information. Appendix C for additional information.
legacy_session_id Versions of TLS before TLS 1.3 supported a legacy_session_id Versions of TLS before TLS 1.3 supported a
"session resumption" feature which has been merged with Pre-Shared "session resumption" feature which has been merged with Pre-Shared
Keys in this version (see Section 2.2). This field MUST be Keys in this version (see Section 2.2). A client which has a
ignored by a server negotiating TLS 1.3 and MUST be set as a zero cached session ID set by a pre-TLS 1.3 server SHOULD set this
length vector (i.e., a single zero byte length field) by clients field to that value. In compatibility mode (see Appendix D.4)
that do not have a cached session ID set by a pre-TLS 1.3 server. this field MUST be non-empty, so a client not offering a pre-TLS
1.3 session MUST generate a new 32-byte value. This value need
not be random but SHOULD be unpredictable to avoid ossification.
Otherwise, it MUST be set as a zero length vector (i.e., a single
zero byte length field).
cipher_suites This is a list of the symmetric cipher options cipher_suites This is a list of the symmetric cipher options
supported by the client, specifically the record protection supported by the client, specifically the record protection
algorithm (including secret key length) and a hash to be used with algorithm (including secret key length) and a hash to be used with
HKDF, in descending order of client preference. If the list HKDF, in descending order of client preference. If the list
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
skipping to change at page 33, line 50 skipping to change at page 35, line 18
the message either contains no data after legacy_compression_methods the message either contains no data after legacy_compression_methods
or that it contains a valid extensions block with no data following. or that it contains a valid extensions block with no data following.
If not, then it MUST abort the handshake with a "decode_error" alert. If not, then it MUST abort the handshake with a "decode_error" alert.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake. client MAY abort the handshake.
After sending the ClientHello message, the client waits for a After sending the ClientHello message, the client waits for a
ServerHello or HelloRetryRequest message. If early data is in use, ServerHello or HelloRetryRequest message. If early data is in use,
the client may transmit early application data Section 2.3 while the client may transmit early application data (Section 2.3) while
waiting for the next handshake message. waiting for the next handshake message.
4.1.3. Server Hello 4.1.3. Server Hello
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message to proceed with the handshake if it is able to negotiate an message to proceed with the handshake if it is able to negotiate an
acceptable set of handshake parameters based on the ClientHello. acceptable set of handshake parameters based on the ClientHello.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion version; ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite; CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>; Extension extensions<6..2^16-1>;
} ServerHello; } ServerHello;
version This field contains the version of TLS negotiated for this version In previous versions of TLS, this field was used for version
connection. Servers MUST select a version from the list in negotiation and represented the selected version number for the
ClientHello's supported_versions extension, or otherwise negotiate connection. Unfortunately, some middleboxes fail when presented
TLS 1.2 or previous. A client that receives a version that was with new values. In TLS 1.3, the TLS server indicates its version
not offered MUST abort the handshake. For this version of the using the "supported_versions" extension (Section 4.2.1), and the
specification, the version is 0x0304. (See Appendix D for details legacy_version field MUST be set to 0x0303, which is the version
about backward compatibility.) number for TLS 1.2. (See Appendix D for details about backward
compatibility.)
random 32 bytes generated by a secure random number generator. See random 32 bytes generated by a secure random number generator. See
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 field. Note that this field is echoed even if
the client's value corresponded to a cached pre-TLS 1.3 session
which the server has chosen not to resume. A client which
receives a legacy_session_id field that does not match what it
sent in the ClientHello MUST abort the handshake with an
"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.
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. Currently the only such extensions are "key_share" and context. Currently the only such extensions are "key_share" and
"pre_shared_key". All current TLS 1.3 ServerHello messages will "pre_shared_key". All current TLS 1.3 ServerHello messages will
contain one of these two extensions, or both when using a PSK with contain one of these two extensions, or both when using a PSK with
(EC)DHE key establishment. The remaining extensions are sent (EC)DHE key establishment. The remaining extensions are sent
separately in the EncryptedExtensions message. separately in the EncryptedExtensions message.
For backward compatibility reasons with middleboxes (see
Appendix D.4) the HelloRetryRequest message uses the same structure
as the ServerHello, but with Random set to the special value of the
SHA-256 of "HelloRetryRequest":
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
Upon receiving a message with type server_hello, implementations MUST
first examine the Random value and if it matches this value, process
it as described in Section 4.1.4).
TLS 1.3 has a downgrade protection mechanism embedded in the server's TLS 1.3 has a downgrade protection mechanism embedded in the server's
random value. TLS 1.3 servers which negotiate TLS 1.2 or below in random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
response to a ClientHello MUST set the last eight bytes of their response to a ClientHello MUST set the last eight bytes of their
Random value specially. Random value specially.
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes
of their Random value to the bytes: of their Random value to the bytes:
44 4F 57 4E 47 52 44 01 44 4F 57 4E 47 52 44 01
skipping to change at page 35, line 50 skipping to change at page 37, line 45
implement this mechanism on either client and server. A pre-RFC implement this mechanism on either client and server. A pre-RFC
client connecting to RFC servers, or vice versa, will appear to client connecting to RFC servers, or vice versa, will appear to
downgrade to TLS 1.2. With the mechanism enabled, this will cause an downgrade to TLS 1.2. With the mechanism enabled, this will cause an
interoperability failure. interoperability failure.
4.1.4. Hello Retry Request 4.1.4. Hello Retry Request
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message if it is able to find an acceptable set of parameters but the message if it is able to find an acceptable set of parameters but the
ClientHello does not contain sufficient information to proceed with ClientHello does not contain sufficient information to proceed with
the handshake. the handshake. As discussed in Section 4.1.3, the HelloRetryRequest
has the same format as a ServerHello message, and the legacy_version,
Structure of this message: legacy_session_id_echo, cipher_suite, and legacy_compression methods
fields have the same meaning. However, for convenience we discuss
struct { HelloRetryRequest throughout this document as if it were a distinct
ProtocolVersion server_version; message.
CipherSuite cipher_suite;
Extension extensions<2..2^16-1>;
} HelloRetryRequest;
The version, cipher_suite, and extensions fields have the same The server's extensions MUST contain "supported_versions" and
meanings as their corresponding values in the ServerHello. The otherwise the server SHOULD send only the extensions necessary for
server SHOULD send only the extensions necessary for the client to the client to generate a correct ClientHello pair. As with
generate a correct ClientHello pair. As with ServerHello, a ServerHello, a HelloRetryRequest MUST NOT contain any extensions that
HelloRetryRequest MUST NOT contain any extensions that were not first were not first offered by the client in its ClientHello, with the
offered by the client in its ClientHello, with the exception of exception of optionally the "cookie" (see Section 4.2.2) extension.
optionally the "cookie" (see Section 4.2.2) extension.
Upon receipt of a HelloRetryRequest, the client MUST verify that the Upon receipt of a HelloRetryRequest, the client MUST perform the
extensions block is not empty and otherwise MUST abort the handshake checks specified in Section 4.1.3 and then process the extensions,
with a "decode_error" alert. Clients MUST abort the handshake with starting with determining the version using "supported_versions".
an "illegal_parameter" alert if the HelloRetryRequest would not Clients MUST abort the handshake with an "illegal_parameter" alert if
result in any change in the ClientHello. If a client receives a the HelloRetryRequest would not result in any change in the
second HelloRetryRequest in the same connection (i.e., where the ClientHello. If a client receives a second HelloRetryRequest in the
ClientHello was itself in response to a HelloRetryRequest), it MUST same connection (i.e., where the ClientHello was itself in response
abort the handshake with an "unexpected_message" alert. 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)
- cookie (see Section 4.2.2) - cookie (see Section 4.2.2)
- key_share (see Section 4.2.7) - key_share (see Section 4.2.8)
In addition, in its updated ClientHello, the client SHOULD NOT offer In addition, in its updated ClientHello, the client SHOULD NOT offer
any pre-shared keys associated with a hash other than that of the any pre-shared keys associated with a hash other than that of the
selected cipher suite. This allows the client to avoid having to selected cipher suite. This allows the client to avoid having to
compute partial hash transcripts for multiple hashes in the second compute partial hash transcripts for multiple hashes in the second
ClientHello. A client which receives a cipher suite that was not ClientHello. A client which receives a cipher suite that was not
offered MUST abort the handshake. Servers MUST ensure that they offered MUST abort the handshake. Servers MUST ensure that they
negotiate the same cipher suite when receiving a conformant updated negotiate the same cipher suite when receiving a conformant updated
ClientHello (if the server selects the cipher suite as the first step ClientHello (if the server selects the cipher suite as the first step
in the negotiation, then this will happen automatically). Upon in the negotiation, then this will happen automatically). Upon
skipping to change at page 37, line 20 skipping to change at page 39, line 15
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
server_name(0), /* RFC 6066 */ server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */ max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */ status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 4492, 7919 */ supported_groups(10), /* RFC 4492, 7919 */
signature_algorithms(13), /* RFC 5246 */ signature_algorithms(13), /* [[this document]] */
use_srtp(14), /* RFC 5764 */ use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */ heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */ application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */ signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */ client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */ server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */ padding(21), /* RFC 7685 */
key_share(40), /* [[this document]] */ key_share(40), /* [[this document]] */
pre_shared_key(41), /* [[this document]] */ pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */ early_data(42), /* [[this document]] */
skipping to change at page 39, line 28 skipping to change at page 41, line 28
| use_srtp [RFC5764] | CH, EE | | use_srtp [RFC5764] | CH, EE |
| | | | | |
| heartbeat [RFC6520] | CH, EE | | heartbeat [RFC6520] | CH, EE |
| | | | | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE | | application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | | | | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT | | signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | | | | |
| client_certificate_type [RFC7250] | CH, EE | | client_certificate_type [RFC7250] | CH, EE |
| | | | | |
| server_certificate_type [RFC7250] | CH, CT | | server_certificate_type [RFC7250] | CH, EE |
| | | | | |
| padding [RFC7685] | CH | | padding [RFC7685] | CH |
| | | | | |
| key_share [[this document]] | CH, SH, HRR | | key_share [[this document]] | CH, SH, HRR |
| | | | | |
| pre_shared_key [[this document]] | CH, SH | | pre_shared_key [[this document]] | CH, SH |
| | | | | |
| psk_key_exchange_modes [[this document]] | CH | | psk_key_exchange_modes [[this document]] | CH |
| | | | | |
| early_data [[this document]] | CH, EE, NST | | early_data [[this document]] | CH, EE, NST |
| | | | | |
| cookie [[this document]] | CH, HRR | | cookie [[this document]] | CH, HRR |
| | | | | |
| supported_versions [[this document]] | CH | | supported_versions [[this document]] | CH, SH, HRR |
| | | | | |
| certificate_authorities [[this document]] | CH, CR | | certificate_authorities [[this document]] | CH, CR |
| | | | | |
| oid_filters [[this document]] | CR | | oid_filters [[this document]] | CR |
| | | | | |
| post_handshake_auth [[this document]] | CH | | post_handshake_auth [[this document]] | CH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
When multiple extensions of different types are present, the When multiple extensions of different types are present, the
extensions MAY appear in any order, with the exception of extensions MAY appear in any order, with the exception of
"pre_shared_key" Section 4.2.10 which MUST be the last extension in "pre_shared_key" Section 4.2.11 which MUST be the last extension in
the ClientHello. There MUST NOT be more than one extension of the the ClientHello. There MUST NOT be more than one extension of the
same type in a given extension block. same type in a given extension block.
In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each
handshake even when in resumption-PSK mode. However, 0-RTT handshake even when in resumption-PSK mode. However, 0-RTT
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.9). 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, and some are simply refusals to support particular
features. In general, error alerts should be used for the former features. In general, error alerts should be used for the former
skipping to change at page 40, line 39 skipping to change at page 42, line 39
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
handshake has been authenticated, active attackers can modify handshake has been authenticated, active attackers can modify
messages and insert, remove, or replace extensions. messages and insert, remove, or replace extensions.
4.2.1. Supported Versions 4.2.1. Supported Versions
struct { struct {
ProtocolVersion versions<2..254>; select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello:
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. The extension contains a list of which versions of TLS it supports and by the server to indicate which
supported versions in preference order, with the most preferred version it is using. The extension contains a list of supported
version first. Implementations of this specification MUST send this versions in preference order, with the most preferred version first.
extension containing all versions of TLS which they are prepared to
negotiate (for this specification, that means minimally 0x0304, but Implementations of this specification MUST send this extension
if previous versions of TLS are allowed to be negotiated, they MUST containing all versions of TLS which they are prepared to negotiate
be present as well). (for this specification, that means minimally 0x0304, but if previous
versions of TLS are allowed to be negotiated, they MUST 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 MUST negotiate TLS 1.2 or prior as specified in
[RFC5246], even if ClientHello.legacy_version is 0x0304 or later. [RFC5246], even if ClientHello.legacy_version is 0x0304 or later.
Servers MAY abort the handshake upon receiving a ClientHello with Servers MAY abort the handshake upon receiving a ClientHello with
legacy_version 0x0304 or later. legacy_version 0x0304 or later.
If this extension is present, servers MUST ignore the If this extension is present, servers MUST ignore the
ClientHello.legacy_version value and MUST use only the ClientHello.legacy_version value and MUST use only the
"supported_versions" extension to determine client preferences. "supported_versions" extension to determine client preferences.
Servers MUST only select a version of TLS present in that extension Servers MUST only select a version of TLS present in that extension
and MUST ignore any unknown versions that are present in that and MUST ignore any unknown versions that are present in that
extension. Note that this mechanism makes it possible to negotiate a extension. Note that this mechanism makes it possible to negotiate a
version prior to TLS 1.2 if one side supports a sparse range. version prior to TLS 1.2 if one side supports a sparse range.
Implementations of TLS 1.3 which choose to support prior versions of Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2. Servers should be prepared to receive TLS SHOULD support TLS 1.2. Servers should be prepared to receive
ClientHellos that include this extension but do not include 0x0304 in ClientHellos that include this extension but do not include 0x0304 in
the list of versions. the list of versions.
The server MUST NOT send the "supported_versions" extension. The A server which negotiates TLS 1.3 MUST respond by sending a
server's selected version is contained in the ServerHello.version "supported_versions" extension containing the selected version value
field as in previous versions of TLS. (0x0304). It MUST set the ServerHello.legacy_version field to 0x0303
(TLS 1.2). Clients MUST check for this extension prior to processing
the rest of the ServerHello (although they will have to parse the
ServerHello in order to read the extension). If this extension is
present, clients MUST ignore the ServerHello.legacy_version value and
MUST use only the "supported_versions" extension to determine client
preferences. If the "supported_versions" extension contains a
version not offered by the client, 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 specification SHOULD instead advertise 0x7f00 | draft_version in
ServerHello.version, and HelloRetryRequest.server_version. For ServerHello.version, and HelloRetryRequest.server_version. For
instance, draft-17 would be encoded as the 0x7f11. This allows pre- instance, draft-17 would be encoded as the 0x7f11. This allows pre-
skipping to change at page 42, line 17 skipping to change at page 44, line 31
server can do this by storing the hash of the ClientHello in the server can do this by storing the hash of the ClientHello in the
HelloRetryRequest cookie (protected with some suitable integrity HelloRetryRequest cookie (protected with some suitable integrity
algorithm). algorithm).
When sending a HelloRetryRequest, the server MAY provide a "cookie" When sending a HelloRetryRequest, the server MAY provide a "cookie"
extension to the client (this is an exception to the usual rule that extension to the client (this is an exception to the usual rule that
the only extensions that may be sent are those that appear in the the only extensions that may be sent are those that appear in the
ClientHello). When sending the new ClientHello, the client MUST copy ClientHello). When sending the new ClientHello, the client MUST copy
the contents of the extension received in the HelloRetryRequest into the contents of the extension received in the HelloRetryRequest into
a "cookie" extension in the new ClientHello. Clients MUST NOT use a "cookie" extension in the new ClientHello. Clients MUST NOT use
cookies in subsequent connections. cookies in their initial ClientHello in subsequent connections.
4.2.3. Signature Algorithms 4.2.3. Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital the server which signature algorithms may be used in digital
signatures. Clients which desire the server to authenticate itself signatures. Clients which desire the server to authenticate itself
via a certificate MUST send this extension. If a server is via a certificate MUST send this extension. If a server is
authenticating via a certificate and the client has not sent a authenticating via a certificate and the client has not sent a
"signature_algorithms" extension, then the server MUST abort the "signature_algorithms" extension, then the server MUST abort the
handshake with a "missing_extension" alert (see Section 9.2). handshake with a "missing_extension" alert (see Section 9.2).
skipping to change at page 46, line 10 skipping to change at page 48, line 10
The client MAY send the "certificate_authorities" extension in the The client MAY send the "certificate_authorities" extension in the
ClientHello message. The server MAY send it in the ClientHello message. The server MAY send it in the
CertificateRequest message. CertificateRequest message.
The "trusted_ca_keys" extension, which serves a similar purpose The "trusted_ca_keys" extension, which serves a similar purpose
[RFC6066], but is more complicated, is not used in TLS 1.3 (although [RFC6066], but is more complicated, is not used in TLS 1.3 (although
it may appear in ClientHello messages from clients which are offering it may appear in ClientHello messages from clients which are offering
prior versions of TLS). prior versions of TLS).
4.2.4.1. OID Filters 4.2.5. OID Filters
The "oid_filters" extension allows servers to provide a set of OID/ The "oid_filters" extension allows servers to provide a set of OID/
value pairs which it would like the client's certificate to match. value pairs which it would like the client's certificate to match.
This extension, if provided by the server, MUST only be sent in the This extension, if provided by the server, MUST only be sent in the
CertificateRequest message. CertificateRequest message.
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;
skipping to change at page 47, line 17 skipping to change at page 49, line 17
the Key Usage certificate extension. the Key Usage certificate extension.
- The Extended Key Usage extension in a certificate matches the - The Extended Key Usage extension in a certificate matches the
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.5. 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;
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.6. Negotiated Groups 4.2.7. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports for key exchange, ordered the named groups which the client supports for key exchange, ordered
from most preferred to least preferred. from most preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups. See "elliptic_curves" and only contained elliptic curve groups. See
[RFC4492] and [RFC7919]. This extension was also used to negotiate [RFC4492] and [RFC7919]. This extension was also used to negotiate
ECDSA curves. Signature algorithms are now negotiated independently ECDSA curves. Signature algorithms are now negotiated independently
(see Section 4.2.3). (see Section 4.2.3).
skipping to change at page 48, line 6 skipping to change at page 50, line 6
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups. See "elliptic_curves" and only contained elliptic curve groups. See
[RFC4492] and [RFC7919]. This extension was also used to negotiate [RFC4492] and [RFC7919]. This extension was also used to negotiate
ECDSA curves. Signature algorithms are now negotiated independently ECDSA curves. Signature algorithms are now negotiated independently
(see Section 4.2.3). (see Section 4.2.3).
The "extension_data" field of this extension contains a The "extension_data" field of this extension contains a
"NamedGroupList" value: "NamedGroupList" value:
enum { enum {
/* Elliptic Curve Groups (ECDHE) */ /* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E), x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */ /* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096 (0x0102), ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104), ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */ /* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF), ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF), ecdhe_private_use(0xFE00..0xFEFF),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<2..2^16-1>; NamedGroup named_group_list<2..2^16-1>;
skipping to change at page 48, line 48 skipping to change at page 51, line 5
found in "supported_groups" prior to successful completion of the found in "supported_groups" prior to successful completion of the
handshake but MAY use the information learned from a successfully handshake but MAY use the information learned from a successfully
completed handshake to change what groups they use in their completed handshake to change what groups they use in their
"key_share" extension in subsequent connections. If the server has a "key_share" extension in subsequent connections. If the server has a
group it prefers to the ones in the "key_share" extension but is group it prefers to the ones in the "key_share" extension but is
still willing to accept the ClientHello, it SHOULD send still willing to accept the ClientHello, it SHOULD send
"supported_groups" to update the client's view of its preferences; "supported_groups" to update the client's view of its preferences;
this extension SHOULD contain all groups the server supports, this extension SHOULD contain all groups the server supports,
regardless of whether they are currently supported by the client. regardless of whether they are currently supported by the client.
4.2.7. Key Share 4.2.8. Key Share
The "key_share" extension contains the endpoint's cryptographic The "key_share" extension contains the endpoint's cryptographic
parameters. parameters.
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. Finite Field
Diffie-Hellman [DH] parameters are described in Section 4.2.7.1; Diffie-Hellman [DH] parameters are described in Section 4.2.8.1;
Elliptic Curve Diffie-Hellman parameters are described in Elliptic Curve Diffie-Hellman parameters are described in
Section 4.2.7.2. 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.
The "extension_data" field of this extension contains a "KeyShare" In the ClientHello message, the "extension_data" field of this
value: extension contains a "KeyShareClientHello" value:
struct { struct {
select (Handshake.msg_type) { KeyShareEntry client_shares<0..2^16-1>;
case client_hello: } KeyShareClientHello;
KeyShareEntry client_shares<0..2^16-1>;
case hello_retry_request:
NamedGroup selected_group;
case server_hello:
KeyShareEntry server_share;
};
} KeyShare;
client_shares A list of offered KeyShareEntry values in descending client_shares A list of offered KeyShareEntry values in descending
order of client preference. This vector MAY be empty if the order of client preference.
client is requesting a HelloRetryRequest. Each KeyShareEntry
value MUST correspond to a group offered in the "supported_groups"
extension and MUST appear in the same order. However, the values
MAY be a non-contiguous subset of the "supported_groups" extension
and MAY omit the most preferred groups. Such a situation could
arise if the most preferred groups are new and unlikely to be
supported in enough places to make pregenerating key shares for
them efficient.
selected_group The mutually supported group the server intends to
negotiate and is requesting a retried ClientHello/KeyShare for.
server_share A single KeyShareEntry value that is in the same group This vector MAY be empty if the client is requesting a
as one of the client's shares. HelloRetryRequest. Each KeyShareEntry value MUST correspond to a
group offered in the "supported_groups" extension and MUST appear in
the same order. However, the values MAY be a non-contiguous subset
of the "supported_groups" extension and MAY omit the most preferred
groups. Such a situation could arise if the most preferred groups
are new and unlikely to be supported in enough places to make
pregenerating key shares for them efficient.
Clients can offer an arbitrary number of KeyShareEntry values, each Clients can offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters. For instance, representing a single set of key exchange parameters. For instance,
a client might offer shares for several elliptic curves or multiple a client might offer shares for several elliptic curves or multiple
FFDHE groups. The key_exchange values for each KeyShareEntry MUST be FFDHE groups. The key_exchange values for each KeyShareEntry MUST be
generated independently. Clients MUST NOT offer multiple generated independently. Clients MUST NOT offer multiple
KeyShareEntry values for the same group. Clients MUST NOT offer any KeyShareEntry values for the same group. Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's KeyShareEntry values for groups not listed in the client's
"supported_groups" extension. Servers MAY check for violations of "supported_groups" extension. Servers MAY check for violations of
these rules and abort the handshake with an "illegal_parameter" alert these rules and abort the handshake with an "illegal_parameter" alert
if one is violated. if one is violated.
In a HelloRetryRequest message, the "extension_data" field of this
extension contains a KeyShareHelloRetryRequest value:
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
selected_group The mutually supported group the server intends to
negotiate and is requesting a retried ClientHello/KeyShare for.
Upon receipt of this extension in a HelloRetryRequest, the client Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that (1) the selected_group field corresponds to a group MUST verify that (1) the selected_group field corresponds to a group
which was provided in the "supported_groups" extension in the which was provided in the "supported_groups" extension in the
original ClientHello; and (2) the selected_group field does not original ClientHello; and (2) the selected_group field does not
correspond to a group which was provided in the "key_share" extension correspond to a group which was provided in the "key_share" extension
in the original ClientHello. If either of these checks fails, then in the original ClientHello. If either of these checks fails, then
the client MUST abort the handshake with an "illegal_parameter" the client MUST abort the handshake with an "illegal_parameter"
alert. Otherwise, when sending the new ClientHello, the client MUST alert. Otherwise, when sending the new ClientHello, the client MUST
replace the original "key_share" extension with one containing only a replace the original "key_share" extension with one containing only a
new KeyShareEntry for the group indicated in the selected_group field new KeyShareEntry for the group indicated in the selected_group field
of the triggering HelloRetryRequest. of the triggering HelloRetryRequest.
In a ServerHello message, the "extension_data" field of this
extension contains a KeyShareServerHello value:
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
server_share A single KeyShareEntry value that is in the same group
as one of the client's shares.
If using (EC)DHE key establishment, servers offer exactly one If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello. This value MUST be in the same KeyShareEntry in the ServerHello. This value MUST be in the same
group as the KeyShareEntry value offered by the client that the group as the KeyShareEntry value offered by the client that the
server has selected for the negotiated key exchange. Servers MUST server has selected for the negotiated key exchange. Servers MUST
NOT send a KeyShareEntry for any group not indicated in the NOT send a KeyShareEntry for any group not indicated in the
"supported_groups" extension and MUST NOT send a KeyShareEntry when "supported_groups" extension and MUST NOT send a KeyShareEntry when
using the "psk_ke" PskKeyExchangeMode. If a HelloRetryRequest was using the "psk_ke" PskKeyExchangeMode. If a HelloRetryRequest was
received by the client, the client MUST verify that the selected received by the client, the client MUST verify that the selected
NamedGroup in the ServerHello is the same as that in the NamedGroup in the ServerHello is the same as that in the
HelloRetryRequest. If this check fails, the client MUST abort the HelloRetryRequest. If this check fails, the client MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
4.2.7.1. Diffie-Hellman Parameters 4.2.8.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of a KeyShareEntry in a encoded in the opaque key_exchange field of a KeyShareEntry in a
KeyShare structure. The opaque value contains the Diffie-Hellman KeyShare structure. The opaque value contains the Diffie-Hellman
public value (Y = g^X mod p) for the specified group (see [RFC7919] public value (Y = g^X mod p) for the specified group (see [RFC7919]
for group definitions) encoded as a big-endian integer and padded to for group definitions) encoded as a big-endian integer and padded to
the left with zeros to the size of p in bytes. the left with zeros to the size of p in bytes.
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.7.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 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 Y 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.6 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 Y is not the point at infinity (O), (2) verify
that for Y = (x, y) both integers are in the correct interval, (3) that for Y = (x, y) both integers are in the correct interval, (3)
ensure that (x, y) is a correct solution to the elliptic curve ensure that (x, y) is a correct solution to the elliptic curve
equation. For these curves, implementers do not need to verify equation. For these curves, implementers do not need to verify
membership in the correct subgroup. 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.8. Pre-Shared Key Exchange Modes 4.2.9. Pre-Shared Key Exchange Modes
In order to use PSKs, clients MUST also send a In order to use PSKs, clients MUST also send a
"psk_key_exchange_modes" extension. The semantics of this extension "psk_key_exchange_modes" extension. The semantics of this extension
are that the client only supports the use of PSKs with these modes, are that the client only supports the use of PSKs with these modes,
which restricts both the use of PSKs offered in this ClientHello and which restricts both the use of PSKs offered in this ClientHello and
those which the server might supply via NewSessionTicket. those which the server might supply via NewSessionTicket.
A client MUST provide a "psk_key_exchange_modes" extension if it A client MUST provide a "psk_key_exchange_modes" extension if it
offers a "pre_shared_key" extension. If clients offer offers a "pre_shared_key" extension. If clients offer
"pre_shared_key" without a "psk_key_exchange_modes" extension, "pre_shared_key" without a "psk_key_exchange_modes" extension,
skipping to change at page 52, line 36 skipping to change at page 54, line 44
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 servers MUST supply "key_share" values as described in
Section 4.2.7. Section 4.2.8.
4.2.9. 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, the client can send application data in its first
flight of messages. If the client opts to do so, it MUST supply both flight of messages. If the client opts to do so, it MUST supply both
the "early_data" extension as well as the "pre_shared_key" extension. 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 (symmetric cipher suite, ALPN The parameters for the 0-RTT data (version, symmetric cipher suite,
protocol, etc.) are the same as those which were negotiated in the ALPN protocol, etc.) are those associated with the PSK in use. For
connection which established the PSK. The PSK used to encrypt the externally established PSKs, the associated values are those
early data MUST be the first PSK listed in the client's provisioned along with the key. For PSKs established via a
"pre_shared_key" extension. NewSessionTicket message, the associated values are those which were
negotiated in the connection which established the PSK. The PSK used
to encrypt the early data MUST be the first PSK listed in the
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)
skipping to change at page 54, line 17 skipping to change at page 56, line 24
- Return its own extension in EncryptedExtensions, indicating that - Return its own extension in EncryptedExtensions, indicating that
it intends to process the early data. It is not possible for the it intends to process the early data. It is not possible for the
server to accept only a subset of the early data messages. Even server to accept only a subset of the early data messages. Even
though the server sends a message accepting early data, the actual though the server sends a message accepting early data, the actual
early data itself may already be in flight by the time the server early data itself may already be in flight by the time the server
generates this message. 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 negotiated in the following values are consistent with those associated with the
connection during which the ticket was established. selected PSK:
- The TLS version number and cipher suite. - The TLS version number
- The selected ALPN [RFC7301] protocol, if any. - The selected cipher suite
- The selected ALPN [RFC7301] protocol, if any
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question. For externally established
PSKs, the associated values are those provisioned along with the key.
For PSKs established via a NewSessionTicket message, the associated
values are those negotiated in the connection during which the ticket
was established.
Future extensions MUST define their interaction with 0-RTT. Future extensions MUST define their interaction with 0-RTT.
If any of these checks fail, the server MUST NOT respond with the If any of these checks fail, the server MUST NOT respond with the
extension and must discard all the first flight data using one of the extension and must discard all the first flight data using one of the
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-0RTT 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 any 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 early data once the handshake has
skipping to change at page 55, line 11 skipping to change at page 57, line 28
application might need to construct different messages. Similarly, application might need to construct different messages. Similarly,
if early data assumes anything about the connection state, it might if early data assumes anything about the connection state, it might
be sent in error after the handshake completes. 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.10. 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 indicate the identity of
the pre-shared key to be used with a given handshake in association the pre-shared key to be used with a given handshake in association
with 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;
opaque PskBinderEntry<32..255>; opaque PskBinderEntry<32..255>;
struct { struct {
select (Handshake.msg_type) { PskIdentity identities<7..2^16-1>;
case client_hello: PskBinderEntry binders<33..2^16-1>;
PskIdentity identities<7..2^16-1>; } OfferedPsks;
PskBinderEntry binders<33..2^16-1>;
case server_hello: struct {
uint16 selected_identity; select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
}; };
} PreSharedKeyExtension; } PreSharedKeyExtension;
identity A label for a key. For instance, a ticket defined in identity A label for a key. For instance, a ticket defined in
Appendix B.3.4 or a label for a pre-shared key established Appendix B.3.4 or a label for a pre-shared key established
externally. externally.
obfuscated_ticket_age An obfuscated version of the age of the key. obfuscated_ticket_age An obfuscated version of the age of the key.
Section 4.2.10.1 describes how to form this value for identities Section 4.2.11.1 describes how to form this value for identities
established via the NewSessionTicket message. For identities established via the NewSessionTicket message. For identities
established externally an obfuscated_ticket_age of 0 SHOULD be established externally an obfuscated_ticket_age of 0 SHOULD be
used, and servers MUST ignore the value. used, and servers MUST ignore the value.
identities A list of the identities that the client is willing to identities A list of the identities that the client is willing to
negotiate with the server. If sent alongside the "early_data" negotiate with the server. If sent alongside the "early_data"
extension (see Section 4.2.9), the first identity is the one used extension (see Section 4.2.10), the first identity is the one used
for 0-RTT data. for 0-RTT data.
binders A series of HMAC values, one for each PSK offered in the binders A series of HMAC values, one for each PSK offered in the
"pre_shared_keys" extension and in the same order, computed as "pre_shared_keys" extension and in the same order, computed as
described below. described below.
selected_identity The server's chosen identity expressed as a selected_identity The server's chosen identity expressed as a
(0-based) index into the identities in the client's list. (0-based) index into the identities in the client's list.
Each PSK is associated with a single Hash algorithm. For PSKs Each PSK is associated with a single Hash algorithm. For PSKs
established via the ticket mechanism (Section 4.6.1), this is the KDF established via the ticket mechanism (Section 4.6.1), this is the KDF
Hash algorithm on the connection where the ticket was established. Hash algorithm on the connection where the ticket was established.
For externally established PSKs, the Hash algorithm MUST be set when For externally established PSKs, the Hash algorithm MUST be set when
the PSK is established, or default to SHA-256 if no such algorithm is the PSK is established, or default to SHA-256 if no such algorithm is
defined. The server must ensure that it selects a compatible PSK (if defined. The server MUST ensure that it selects a compatible PSK (if
any) and cipher suite. any) and cipher suite.
In TLS versions prior to TLS 1.3, the Server Name Identification
(SNI) value was intended to be associated with the session (Section 3
of [RFC6066]), with the server being required to enforce that the SNI
value associated with the session matches the one specified in the
resumption handshake. However, in reality the implementations were
not consistent on which of two supplied SNI values they would use,
leading to the consistency requirement being de-facto enforced by the
clients. In TLS 1.3, the SNI value is always explicitly specified in
the resumption handshake, and there is no need for the server to
associate an SNI value with the ticket. Clients, however, SHOULD
store the SNI with the PSK to fulfill the requirements of
Section 4.6.1.
Implementor's note: the most straightforward way to implement the Implementor's note: the most straightforward way to implement the
PSK/cipher suite matching requirements is to negotiate the cipher PSK/cipher suite matching requirements is to negotiate the cipher
suite first and then exclude any incompatible PSKs. Any unknown PSKs suite first and then exclude any incompatible PSKs. Any unknown PSKs
(e.g., they are not in the PSK database or are encrypted with an (e.g., they are not in the PSK database or are encrypted with an
unknown key) SHOULD simply be ignored. If no acceptable PSKs are unknown key) SHOULD simply be ignored. If no acceptable PSKs are
found, the server SHOULD perform a non-PSK handshake if possible. found, the server SHOULD perform a non-PSK handshake if possible.
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.10.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. 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
skipping to change at page 57, line 5 skipping to change at page 60, line 5
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 This extension MUST be the last extension in the ClientHello (this
facilitates implementation as described below). Servers MUST check facilitates implementation as described below). Servers MUST check
that it is the last extension and otherwise fail the handshake with that it is the last extension and otherwise fail the handshake with
an "illegal_parameter" alert. an "illegal_parameter" alert.
4.2.10.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 observers
from correlating connections unless tickets are reused. Note that from correlating connections unless tickets are reused. Note that
the "ticket_lifetime" field in the NewSessionTicket message is in the "ticket_lifetime" field in the NewSessionTicket message is in
seconds but the "obfuscated_ticket_age" is in milliseconds. Because seconds but the "obfuscated_ticket_age" is in milliseconds. Because
ticket lifetimes are restricted to a week, 32 bits is enough to ticket lifetimes are restricted to a week, 32 bits is enough to
represent any plausible age, even in milliseconds. represent any plausible age, even in milliseconds.
4.2.10.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 between the handshake in which the PSK was
generated (if via a NewSessionTicket message) and the handshake where generated (if via a NewSessionTicket message) and the handshake where
it was used. Each entry in the binders list is computed as an HMAC it was used. 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
skipping to change at page 57, line 45 skipping to change at page 60, line 45
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
derived via the key schedule from the corresponding PSK which is derived via the key schedule from the corresponding PSK which is
being offered (see Section 7.1). being offered (see Section 7.1).
If the handshake includes a HelloRetryRequest, the initial If the handshake includes a HelloRetryRequest, the initial
ClientHello and HelloRetryRequest are included in the transcript ClientHello and HelloRetryRequest are included in the transcript
along with the new ClientHello. For instance, if the client sends along with the new ClientHello. For instance, if the client sends
ClientHello1, its binder will be computed over: ClientHello1, its binder will be computed over:
Transcript-Hash(ClientHello1[truncated]) Transcript-Hash(Truncate(ClientHello1))
Where Truncate() removes the binders list from the ClientHello.
If the server responds with HelloRetryRequest, and the client then If the server responds with HelloRetryRequest, and the client then
sends ClientHello2, its binder will be computed over: sends ClientHello2, its binder will be computed over:
Transcript-Hash(ClientHello1, Transcript-Hash(ClientHello1,
HelloRetryRequest, HelloRetryRequest,
ClientHello2[truncated]) Truncate(ClientHello2))
The full ClientHello1 is included in all other handshake hash The full ClientHello1/ClientHello2 is included in all other handshake
computations. Note that in the first flight, ClientHello1[truncated] hash computations. Note that in the first flight,
is hashed directly, but in the second flight, ClientHello1 is hashed Truncate(ClientHello1) is hashed directly, but in the second flight,
and then reinjected as a "handshake_hash" message, as described in ClientHello1 is hashed and then reinjected as a "message_hash"
Section 4.4.1. message, as described in Section 4.4.1.
4.2.10.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 the ServerHello, rather than
waiting for the client's EndOfEarlyData message. waiting for the client's EndOfEarlyData message.
4.3. Server Parameters 4.3. Server Parameters
skipping to change at page 59, line 46 skipping to change at page 62, line 46
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" extension. The latter is expressed by the "signature_algorithms" extension. The latter is expressed by
sending the "certificate_authorities" extension (see Section 4.2.4). sending the "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.5). Section 4.2.6).
4.4. Authentication Messages 4.4. Authentication Messages
As discussed in Section 2, TLS generally uses a common set of As discussed in Section 2, TLS generally uses a common set of
messages for authentication, key confirmation, and handshake messages for authentication, key confirmation, and handshake
integrity: Certificate, CertificateVerify, and Finished. (The integrity: Certificate, CertificateVerify, and Finished. (The
PreSharedKey binders also perform key confirmation, in a similar PreSharedKey binders also perform key confirmation, in a similar
fashion.) These three messages are always sent as the last messages fashion.) These three messages are always sent as the last messages
in their handshake flight. The Certificate and CertificateVerify in their handshake flight. The Certificate and CertificateVerify
messages are only sent under certain circumstances, as defined below. messages are only sent under certain circumstances, as defined below.
skipping to change at page 61, line 36 skipping to change at page 64, line 36
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 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,
skipping to change at page 62, line 31 skipping to change at page 66, line 5
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).
Structure of this message: Structure of this message:
enum {
X509(0),
RawPublicKey(2),
(255)
} 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 */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509: case X509:
opaque cert_data<1..2^24-1>; opaque cert_data<1..2^24-1>;
}; };
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} CertificateEntry; } CertificateEntry;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
skipping to change at page 63, line 11 skipping to change at page 66, line 39
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
include OCSP Status extensions ([RFC6066] and [RFC6961]) and include OCSP Status extension ([RFC6066]) and
SignedCertificateTimestamps ([RFC6962]). An extension MUST only SignedCertificateTimestamps ([RFC6962]). An extension MUST only
be present in a Certificate message if the corresponding be present in a Certificate message if the corresponding
ClientHello extension was presented in the initial handshake. If ClientHello extension was presented in the initial handshake. If
an extension applies to the entire chain, it SHOULD be included in an extension applies to the entire chain, it SHOULD be included in
the first CertificateEntry. the first CertificateEntry.
If the corresponding certificate type extension If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not used ("server_certificate_type" or "client_certificate_type") was not
or the X.509 certificate type was negotiated, then each negotiated in Encrypted Extensions, or the X.509 certificate type was
CertificateEntry contains an X.509 certificate. The sender's negotiated, then each CertificateEntry contains an X.509 certificate.
certificate MUST come in the first CertificateEntry in the list. The sender's certificate MUST come in the first CertificateEntry in
Each following certificate SHOULD directly certify one preceding it. the list. Each following certificate SHOULD directly certify one
Because certificate validation requires that trust anchors be preceding it. Because certificate validation requires that trust
distributed independently, a certificate that specifies a trust anchors be distributed independently, a certificate that specifies a
anchor MAY be omitted from the chain, provided that supported peers trust anchor MAY be omitted from the chain, provided that supported
are known to possess any omitted certificates. peers are known to 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 64, line 18 skipping to change at page 67, line 44
sending OCSP responses to the client. In TLS 1.2 and below, the sending OCSP responses to the client. In TLS 1.2 and below, the
server replies with an empty extension to indicate negotiation of server replies with an empty extension to indicate negotiation of
this extension and the OCSP information is carried in a this extension and the OCSP information is carried in a
CertificateStatus message. In TLS 1.3, the server's OCSP information CertificateStatus message. In TLS 1.3, the server's OCSP information
is carried in an extension in the CertificateEntry containing the is carried in an extension in the CertificateEntry containing the
associated certificate. Specifically: The body of the associated certificate. Specifically: The body of the
"status_request" extension from the server MUST be a "status_request" extension from the server MUST be a
CertificateStatus structure as defined in [RFC6066], which is CertificateStatus structure as defined in [RFC6066], which is
interpreted as defined in [RFC6960]. interpreted as defined in [RFC6960].
Note: status_request_v2 extension ([RFC6961]) is deprecated. TLS 1.3
servers MUST NOT act upon its presence or information in it when
processing Client Hello, in particular they MUST NOT send the
status_request_v2 extension in the Encrypted Extensions, Certificate
Request or the Certificate messages. TLS 1.3 servers MUST be able to
process Client Hello messages that include it, as it MAY be sent by
clients that wish to use it in earlier protocol versions.
A server MAY request that a client present an OCSP response with its A server MAY request that a client present an OCSP response with its
certificate by sending an empty "status_request" extension in its certificate by sending an empty "status_request" extension in its
CertificateRequest message. If the client opts to send an OCSP CertificateRequest message. If the client opts to send an OCSP
response, the body of its "status_request" extension MUST be a response, the body of its "status_request" extension MUST be a
CertificateStatus structure as defined in [RFC6066]. CertificateStatus structure as defined in [RFC6066].
Similarly, [RFC6962] provides a mechanism for a server to send a Similarly, [RFC6962] provides a mechanism for a server to send a
Signed Certificate Timestamp (SCT) as an extension in the ServerHello Signed Certificate Timestamp (SCT) as an extension in the ServerHello
in TLS 1.2 and below. In TLS 1.3, the server's SCT information is in TLS 1.2 and below. In TLS 1.3, the server's SCT information is
carried in an extension in CertificateEntry. carried in an extension in CertificateEntry.
skipping to change at page 64, line 45 skipping to change at page 68, line 32
- 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 (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" extension. "signature_algorithms" extension.
- The "server_name" and "certificate_authorities" extensions - The "server_name" [RFC6066] and "certificate_authorities"
[RFC6066] are used to guide certificate selection. As servers MAY extensions are used to guide certificate selection. As servers
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 that appears in the "signature_algorithms" extension algorithm that appears in the "signature_algorithms" extension
provided by the client, if they are able to provide such a chain (see provided by the client, if they are able to provide such a chain (see
Section 4.2.3). Certificates that are self-signed or certificates Section 4.2.3). Certificates that are self-signed or certificates
that are expected to be trust anchors are not validated as part of that are expected to be trust anchors are not validated as part of
the chain and therefore MAY be signed with any algorithm. 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
skipping to change at page 65, line 46 skipping to change at page 69, line 34
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 recognized by the client, as described in
Section 4.2.4.1. 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.
skipping to change at page 69, line 11 skipping to change at page 72, line 46
Recipients of Finished messages MUST verify that the contents are Recipients of Finished messages MUST verify that the contents are
correct and if incorrect MUST terminate the connection with a correct and if incorrect MUST terminate the connection with a
"decrypt_error" alert. "decrypt_error" alert.
Once a side has sent its Finished message and received and validated Once a side has sent its Finished message and received and validated
the Finished message from its peer, it may begin to send and receive the Finished message from its peer, it may begin to send and receive
application data over the connection. There are two settings in application data over the connection. There are two settings in
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 ending 0-RTT data as described in Section 4.2.9. 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:
skipping to change at page 70, line 38 skipping to change at page 74, line 25
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.
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.10). 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. For instance, the server might send a new ticket after post- events (see Appendix C.4). For instance, the server might send a new
handshake authentication in order to encapsulate the additional ticket after post-handshake authentication in order to encapsulate
client authentication state. Clients SHOULD attempt to use each the additional client authentication state. Multiple tickets are
ticket no more than once, with more recent tickets being used first. useful for clients for a variety of purposes, including:
- Opening multiple parallel HTTP connections.
- Performing connection racing across interfaces and address
families via, e.g., Happy Eyeballs [RFC6555] or related
techniques.
Any ticket MUST only be resumed with a cipher suite that has the same Any ticket MUST only be resumed with a cipher suite that has the same
KDF hash algorithm as that used to establish the original connection, KDF hash algorithm as that used to establish the original connection.
and only if the client provides the same SNI value as in the original
connection, as described in Section 3 of [RFC6066]. Clients MUST only resume if the new SNI value is valid for the server
certificate presented in the original session, and SHOULD only resume
if the SNI value matches the one used in the original session. The
latter is a performance optimization: normally, there is no reason to
expect that different servers covered by a single certificate would
be able to accept each other's tickets, hence attempting resumption
in that case would waste a single-use ticket. If such an indication
is provided (externally or by any other means), clients MAY resume
with a different SNI value.
On resumption, if reporting an SNI value to the calling application,
implementations MUST use the value sent in the resumption ClientHello
rather than the value sent in the previous session. Note that if a
server implementation declines all PSK identities with different SNI
values, these two values are always the same.
Note: Although the resumption master secret depends on the client's Note: Although the resumption master secret depends on the client's
second flight, servers which do not request client authentication MAY second flight, servers which do not request client authentication MAY
compute the remainder of the transcript independently and then send a compute the remainder of the transcript independently and then send a
NewSessionTicket immediately upon sending its Finished rather than NewSessionTicket immediately upon sending its Finished rather than
waiting for the client Finished. This might be appropriate in cases waiting for the client Finished. This might be appropriate in cases
where the client is expected to open multiple TLS connections in where the client is expected to open multiple TLS connections in
parallel and would benefit from the reduced overhead of a resumption parallel and would benefit from the reduced overhead of a resumption
handshake, for example. handshake, for example.
struct { struct {
uint32 ticket_lifetime; uint32 ticket_lifetime;
uint32 ticket_age_add; uint32 ticket_age_add;
opaque ticket_nonce<1..255>; opaque ticket_nonce<0..255>;
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
skipping to change at page 71, line 36 skipping to change at page 75, line 45
treat a ticket as valid for a shorter period of time than what is treat a ticket as valid for a shorter period of time than what is
stated in the ticket_lifetime. stated 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 unique per-ticket value. ticket_nonce A per-ticket value that is unique across all tickets
issued on this connection.
ticket The value of the ticket to be used as the PSK identity. The ticket The value of the ticket to be used as the PSK identity. The
ticket itself is an opaque label. It MAY either be a database ticket itself is an opaque label. It MAY either be a database
lookup key or a self-encrypted and self-authenticated value. lookup key or a self-encrypted and self-authenticated value.
Section 4 of [RFC5077] describes a recommended ticket construction Section 4 of [RFC5077] describes a recommended ticket construction
mechanism. mechanism.
extensions A set of extension values for the ticket. The extensions A set of extension values for the ticket. The
"Extension" format is defined in Section 4.2. Clients MUST ignore "Extension" format is defined in Section 4.2. Clients MUST ignore
unrecognized extensions. unrecognized extensions.
The sole extension currently defined for NewSessionTicket is The sole extension currently defined for NewSessionTicket is
"early_data", indicating that the ticket may be used to send 0-RTT "early_data", indicating that the ticket may be used to send 0-RTT
data (Section 4.2.9)). It contains the following value: data (Section 4.2.10)). It contains the following value:
max_early_data_size The maximum amount of 0-RTT data that the client max_early_data_size The maximum amount of 0-RTT data that the client
is allowed to send when using this ticket, in bytes. Only is allowed to send when using this ticket, in bytes. Only
Application Data payload (i.e., plaintext but not padding or the Application Data payload (i.e., plaintext but not padding or the
inner content type byte) is counted. A server receiving more than inner content type byte) is counted. A server receiving more than
max_early_data_size bytes of 0-RTT data SHOULD terminate the max_early_data_size bytes of 0-RTT data SHOULD terminate the
connection with an "unexpected_message" alert. Note that servers connection with an "unexpected_message" alert. Note that servers
that reject early data due to lack of cryptographic material will that reject early data due to lack of cryptographic material will
be unable to differentiate padding from content, so clients SHOULD be unable to differentiate padding from content, so clients SHOULD
NOT depend on being able to send large quantities of padding in NOT depend on being able to send large quantities of padding in
skipping to change at page 72, line 36 skipping to change at page 76, line 44
originally derived from an initial non-PSK handshake (which was most originally derived from an initial non-PSK handshake (which was most
likely tied to the peer's certificate). It is RECOMMENDED that likely tied to the peer's certificate). It is RECOMMENDED that
implementations place limits on the total lifetime of such keying implementations place limits on the total lifetime of such keying
material; these limits should take into account the lifetime of the material; these limits should take into account the lifetime of the
peer's certificate, the likelihood of intervening revocation, and the peer's certificate, the likelihood of intervening revocation, and the
time since the peer's online CertificateVerify signature. time since the peer's online CertificateVerify signature.
4.6.2. Post-Handshake Authentication 4.6.2. Post-Handshake Authentication
When the client has sent the "post_handshake_auth" extension (see When the client has sent the "post_handshake_auth" extension (see
Section 4.2.5), a server MAY request client authentication at any Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a time after the handshake has completed by sending a
CertificateRequest message. The client MUST respond with the CertificateRequest message. The client MUST respond with the
appropriate Authentication messages (see Section 4.4). If the client appropriate Authentication messages (see Section 4.4). If the client
chooses to authenticate, it MUST send Certificate, CertificateVerify, chooses to authenticate, it MUST send Certificate, CertificateVerify,
and Finished. If it declines, it MUST send a Certificate message and Finished. If it declines, it MUST send a Certificate message
containing no certificates followed by Finished. All of the client's containing no certificates followed by Finished. All of the client's
messages for a given response MUST appear consecutively on the wire messages for a given response MUST appear consecutively on the wire
with no intervening messages of other types. with no intervening messages of other types.
A client that receives a CertificateRequest message without having A client that receives a CertificateRequest message without having
skipping to change at page 74, line 22 skipping to change at page 78, line 28
5. Record Protocol 5. Record Protocol
The TLS record protocol takes messages to be transmitted, fragments The TLS record protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits
the result. Received data is verified, decrypted, reassembled, and the result. Received data is verified, decrypted, reassembled, and
then delivered to higher-level clients. then delivered to higher-level clients.
TLS records are typed, which allows multiple higher-level protocols TLS records are typed, which allows multiple higher-level protocols
to be multiplexed over the same record layer. This document to be multiplexed over the same record layer. This document
specifies three content types: handshake, application data, and specifies four content types: handshake, application data, alert, and
alert. Implementations MUST NOT send record types not defined in change_cipher_spec, with the latter being used only for compatibility
this document unless negotiated by some extension. If a TLS purposes (see Appendix D.4).
An implementation may receive an unencrypted record of type
change_cipher_spec consisting of the single byte value 0x01 at any
time during the handshake and MUST simply drop it without further
processing. Note that this record may appear at a point at the
handshake where the implementation is expecting protected records and
so it is necessary to detect this condition prior to attempting to
deprotect the record. An implementation which receives any other
change_cipher_spec value or which receives a protected
change_cipher_spec record MUST abort the handshake with an
"unexpected_message" alert. After the handshake is complete,
change_cipher_spec MUST be treated as an unexpected record type.
Implementations MUST NOT send record types not defined in this
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
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Message records carrying data in chunks of 2^14 bytes or less. Message
boundaries are handled differently depending on the underlying boundaries are handled differently depending on the underlying
skipping to change at page 75, line 18 skipping to change at page 79, line 40
types, even if those fragments contain padding. types, even if those fragments contain padding.
Alert messages (Section 6) MUST NOT be fragmented across records and Alert messages (Section 6) MUST NOT be fragmented across records and
multiple Alert messages MUST NOT be coalesced into a single multiple Alert messages MUST NOT be coalesced into a single
TLSPlaintext record. In other words, a record with an Alert type TLSPlaintext record. In other words, a record with an Alert type
MUST contain exactly one message. MUST contain exactly one message.
Application Data messages contain data that is opaque to TLS. Application Data messages contain data that is opaque to TLS.
Application Data messages are always protected. Zero-length Application Data messages are always protected. Zero-length
fragments of Application Data MAY be sent as they are potentially fragments of Application Data MAY be sent as they are potentially
useful as a traffic analysis countermeasure. useful as a traffic analysis countermeasure. Application Data
fragments MAY be split across multiple records or coalesced into a
single record.
enum { enum {
invalid(0), invalid(0),
change_cipher_spec(20),
alert(21), alert(21),
handshake(22), handshake(22),
application_data(23), application_data(23),
(255) (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type The higher-level protocol used to process the enclosed type The higher-level protocol used to process the enclosed
fragment. fragment.
legacy_record_version This value MUST be set to 0x0301 for all legacy_record_version This value MUST be set to 0x0303 for all
records generated by a TLS 1.3 implementation. This field is records generated by a TLS 1.3 implementation other than the
deprecated and MUST be ignored for all purposes. Previous ClientHello, where it MAY also be 0x0301 for compatibility
versions of TLS would use other values in this field under some purposes. This field is deprecated and MUST be ignored for all
circumstances. purposes. Previous versions of TLS would use other values in this
field under some circumstances.
length The length (in bytes) of the following TLSPlaintext.fragment. length The length (in bytes) of the following TLSPlaintext.fragment.
The length MUST NOT exceed 2^14 bytes. An endpoint that receives The length MUST NOT exceed 2^14 bytes. An endpoint that receives
a record that exceeds this length MUST terminate the connection a record that exceeds this length MUST terminate the connection
with a "record_overflow" alert. with a "record_overflow" alert.
fragment The data being transmitted. This value is transparent and fragment The data being transmitted. This value is transparent and
is treated as an independent block to be dealt with by the higher- is treated as an independent block to be dealt with by the higher-
level protocol specified by the type field. level protocol specified by the type field.
This document describes TLS 1.3, which uses the version 0x0304. This This document describes TLS 1.3, which uses the version 0x0304. This
version value is historical, deriving from the use of 0x0301 for TLS version value is historical, deriving from the use of 0x0301 for TLS
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, the record layer version identifies as simply TLS 1.0. compatibility, records containing the ClientHello MUST have version
Endpoints supporting multiple versions negotiate the version to use 0x0301 and records containing the ServerHello MUST have version
by following the procedure and requirements in Appendix D. 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively. When
negotiating prior versions of TLS, endpoints 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.
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
skipping to change at page 76, line 36 skipping to change at page 81, line 24
plaintext header followed by an encrypted body, which itself contains plaintext header followed by an encrypted body, which itself contains
a type and optional padding. a type and optional padding.
struct { struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
ContentType type; ContentType type;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} TLSInnerPlaintext; } TLSInnerPlaintext;
struct { struct {
ContentType opaque_type = 23; /* application_data */ ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length; uint16 length;
opaque encrypted_record[length]; opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext; } TLSCiphertext;
content The byte encoding of a handshake or an alert message, or the content The byte encoding of a handshake or an alert message, or the
raw bytes of the application's data to send. raw bytes of the application's data to send.
type The content type of the record. type 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
versions of TLS. The actual content type of the record is found versions of TLS. The actual content type of the record is found
in TLSInnerPlaintext.type after decryption. in TLSInnerPlaintext.type after decryption.
legacy_record_version The legacy_record_version field is always legacy_record_version The legacy_record_version field is always
0x0301. TLS 1.3 TLSCiphertexts are not generated until after TLS 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS
1.3 has been negotiated, so there are no historical compatibility 1.3 has been negotiated, so there are no historical compatibility
concerns where other values might be received. Implementations concerns where other values might be received. Implementations
MAY verify that the legacy_record_version field is 0x0301 and MAY verify that the legacy_record_version field is 0x0303 and
abort the connection if it is not. Note that the handshake abort the connection if it is not. Note that the handshake
protocol including the ClientHello and ServerHello messages protocol including the ClientHello and ServerHello messages
authenticates the protocol version, so this value is redundant. authenticates the protocol version, so this value is redundant.
length The length (in bytes) of the following length The length (in bytes) of the following
TLSCiphertext.encrypted_record, which is the sum of the lengths of TLSCiphertext.encrypted_record, which is the sum of the lengths of
the content and the padding, plus one for the inner content type, the content and the padding, plus one for the inner content type,
plus any expansion added by the AEAD algorithm. The length MUST plus any expansion added by the AEAD algorithm. The length MUST
NOT exceed 2^14 + 256 bytes. An endpoint that receives a record NOT exceed 2^14 + 256 bytes. An endpoint that receives a record
that exceeds this length MUST terminate the connection with a that exceeds this length MUST terminate the connection with a
skipping to change at page 79, line 46 skipping to change at page 84, line 37
size limits) without introducing new content types. The design also size limits) without introducing new content types. The design also
enforces all-zero padding octets, which allows for quick detection of enforces all-zero padding octets, which allows for quick detection of
padding errors. padding errors.
Implementations MUST limit their scanning to the cleartext returned Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption. If a receiving implementation does not from the AEAD decryption. If a receiving implementation does not
find a non-zero octet in the cleartext, it MUST terminate the find a non-zero octet in the cleartext, it MUST terminate the
connection with an "unexpected_message" alert. connection with an "unexpected_message" alert.
The presence of padding does not change the overall record size The presence of padding does not change the overall record size
limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14 limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14
octets. If the maximum fragment length is reduced, as for example by + 1 octets. If the maximum fragment length is reduced, as for
the max_fragment_length extension from [RFC6066], then the reduced example by the max_fragment_length extension from [RFC6066], then the
limit applies to the full plaintext, including the padding. reduced limit applies to the full plaintext, including the content
type and padding.
Selecting a padding policy that suggests when and how much to pad is Selecting a padding policy that suggests when and how much to pad is
a complex topic and is beyond the scope of this specification. If a complex topic and is beyond the scope of this specification. If
the application layer protocol on top of TLS has its own padding, it the application layer protocol on top of TLS has its own padding, it
may be preferable to pad application_data TLS records within the may be preferable to pad application_data TLS records within the
application layer. Padding for encrypted handshake and alert TLS application layer. Padding for encrypted handshake and alert TLS
records must still be handled at the TLS layer, though. Later records must still be handled at the TLS layer, though. Later
documents may define padding selection algorithms or define a padding documents may define padding selection algorithms or define a padding
policy request mechanism through TLS extensions or some other means. policy request mechanism through TLS extensions or some other means.
skipping to change at page 80, line 36 skipping to change at page 85, line 30
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. In TLS 1.3, the severity is implicit in the type of alert being
sent, and the 'level' field can safely be ignored. The sent, and the 'level' field can safely be ignored. The
"close_notify" alert is used to indicate orderly closure of the "close_notify" alert is used to indicate orderly closure of one
connection. Upon receiving such an alert, the TLS implementation direction of the connection. Upon receiving such an alert, the TLS
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 keys and secrets associated with a failed
connection. Stateful implementations of tickets (as in many clients) connection. Stateful implementations of tickets (as in many clients)
SHOULD discard tickets associated with failed connections. SHOULD discard tickets associated with failed connections.
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 as fatal and MUST
skipping to change at page 82, line 12 skipping to change at page 87, line 7
AlertDescription description; AlertDescription description;
} Alert; } Alert;
6.1. Closure Alerts 6.1. Closure Alerts
The client and the server must share knowledge that the connection is The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack. ending in order to avoid a truncation attack.
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 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 is generally a warning.
Either party MAY initiate a close by sending a "close_notify" alert. Either party MAY initiate a close of its write side of the connection
Any data received after a closure alert MUST be ignored. If a by sending a "close_notify" alert. Any data received after a closure
transport-level close is received prior to a "close_notify", the alert has been received MUST be ignored. If a transport-level close
receiver cannot know that all the data that was sent has been is received prior to a "close_notify", the receiver cannot know that
received. all the data that was sent has been received.
Each party MUST send a "close_notify" alert before closing the write Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless some other fatal alert has been side of the connection, unless it has already sent some other fatal
transmitted. The other party MUST respond with a "close_notify" alert. This does not have any effect on its read side of the
alert of its own and close down the connection immediately, connection. Note that this is a change from versions of TLS prior to
discarding any pending writes. The initiator of the close need not TLS 1.3 in which implementations were required to react to a
wait for the responding "close_notify" alert before closing the read "close_notify" by discarding pending writes and sending an immediate
side of the connection. "close_notify" alert of their own. That previous requirement could
cause truncation in the read side. Both parties need not wait to
receive a "close_notify" alert before closing their read side of the
connection.
If the application protocol using TLS provides that any data may be If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive the responding closed, the TLS implementation MUST receive a "close_notify" alert
"close_notify" alert before indicating to the application layer that before indicating end-of-data to the application-layer. No part of
the TLS connection has ended. If the application protocol will not this standard should be taken to dictate the manner in which a usage
transfer any additional data but will only close the underlying profile for TLS manages its data transport, including when
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding "close_notify". No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed. connections are opened or closed.
Note: It is assumed that closing a connection reliably delivers Note: It is assumed that closing the write side of a connection
pending data before destroying the transport. reliably delivers pending data before destroying the transport.
6.2. Error Alerts 6.2. Error Alerts
Error handling in the TLS Handshake Protocol is very simple. When an Error handling in the TLS Handshake Protocol is very simple. When an
error is detected, the detecting party sends a message to its peer. error is detected, the detecting party sends a message to its peer.
Upon transmission or receipt of a fatal alert message, both parties Upon transmission or receipt of a fatal alert message, both parties
MUST immediately close the connection. MUST immediately close the connection.
Whenever an implementation encounters a fatal error condition, it Whenever an implementation encounters a fatal error condition, it
SHOULD send an appropriate fatal alert and MUST close the connection SHOULD send an appropriate fatal alert and MUST close the connection
skipping to change at page 83, line 26 skipping to change at page 88, line 16
"abort the handshake" are used without a specific alert it means that "abort the handshake" are used without a specific alert it means that
the implementation SHOULD send the alert indicated by the the implementation SHOULD send the alert indicated by the
descriptions below. The phrases "terminate the connection with a X descriptions below. The phrases "terminate the connection with a X
alert" and "abort the handshake with a X alert" mean that the alert" and "abort the handshake with a X alert" mean that the
implementation MUST send alert X if it sends any alert. All alerts implementation MUST send alert X if it sends any alert. All alerts
defined in this section below, as well as all unknown alerts, are defined in this section below, as well as all unknown alerts, are
universally considered fatal as of TLS 1.3 (see Section 6). The universally considered fatal as of TLS 1.3 (see Section 6). The
implementation SHOULD provide a way to facilitate logging the sending implementation SHOULD provide a way to facilitate logging the sending
and receiving of alerts. and receiving of alerts.
The following error alerts are defined:
unexpected_message An inappropriate message (e.g., the wrong unexpected_message An inappropriate message (e.g., the wrong
handshake message, premature application data, etc.) was received. handshake message, premature application data, etc.) was received.
This alert should never be observed in communication between This alert should never be observed in communication between
proper implementations. proper implementations.
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,
skipping to change at page 85, line 41 skipping to change at page 90, line 31
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
"application_layer_protocol_negotiation" extension advertises "application_layer_protocol_negotiation" extension advertises only
protocols that the server does not support (see [RFC7301]). protocols that the server does not support (see [RFC7301]).
New Alert values are assigned by IANA as described in Section 11. New Alert values are assigned by IANA as described in Section 11.
7. Cryptographic Computations 7. Cryptographic Computations
The TLS handshake establishes one or more input secrets which are The TLS handshake establishes one or more input secrets which are
combined to create the actual working keying material, as detailed combined to create the actual working keying material, as detailed
below. The key derivation process incorporates both the input below. The key derivation process incorporates both the input
secrets and the handshake transcript. Note that because the secrets and the handshake transcript. Note that because the
handshake transcript includes the random values from the Hello handshake transcript includes the random values from the Hello
messages, any given handshake will have different traffic secrets, messages, any given handshake will have different traffic secrets,
even if the same input secrets are used, as is the case when the same even if the same input secrets are used, as is the case when the same
PSK is used for multiple connections PSK is used for multiple connections.
7.1. Key Schedule 7.1. Key Schedule
The key derivation process makes use of the HKDF-Extract and HKDF- The key derivation process makes use of the HKDF-Extract and HKDF-
Expand functions as defined for HKDF [RFC5869], as well as the Expand functions as defined for HKDF [RFC5869], as well as the
functions defined below: functions defined below:
HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length) HKDF-Expand(Secret, HkdfLabel, Length)
Where HkdfLabel is specified as: Where HkdfLabel is specified as:
struct { struct {
uint16 length = Length; uint16 length = Length;
opaque label<7..255> = "tls13 " + Label; opaque label<7..255> = "tls13 " + Label;
opaque hash_value<0..255> = HashValue; 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 are 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 HashValue (indicated by "") is passed to HKDF-Expand-Label. length Context (indicated by "") is passed to HKDF-Expand-Label. The
Labels specified in this document are all ASCII strings, and do not
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 Given a set of n InputSecrets, the final "master secret" is computed
by iteratively invoking HKDF-Extract with InputSecret_1, by iteratively invoking HKDF-Extract with InputSecret_1,
InputSecret_2, etc. The initial secret is simply a string of InputSecret_2, etc. The initial secret is simply a string of
Hash.length zero bytes. Concretely, for the present version of TLS Hash.length bytes set to zeros. Concretely, for the present version
1.3, secrets are added in the following order: of TLS 1.3, secrets are added in the following order:
- 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.
- 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.
skipping to change at page 88, line 29 skipping to change at page 93, line 23
The general pattern here is that the secrets shown down the left side The general pattern here is that the secrets shown down the left side
of the diagram are just raw entropy without context, whereas the of the diagram are just raw entropy without context, whereas the
secrets down the right side include handshake context and therefore secrets down the right side include handshake context and therefore
can be used to derive working keys without additional context. Note can be used to derive working keys without additional context. Note
that the different calls to Derive-Secret may take different Messages that the different calls to Derive-Secret may take different Messages
arguments, even with the same secret. In a 0-RTT exchange, Derive- arguments, even with the same secret. In a 0-RTT exchange, Derive-
Secret is called with four distinct transcripts; in a 1-RTT-only Secret is called with four distinct transcripts; in a 1-RTT-only
exchange with three distinct transcripts. exchange with three distinct transcripts.
If a given secret is not available, then the 0-value consisting of a If a given secret is not available, then the 0-value consisting of a
string of Hash.length zero bytes is used. Note that this does not string of Hash.length bytes set to zeros is used. Note that this
mean skipping rounds, so if PSK is not in use Early Secret will still does not mean skipping rounds, so if PSK is not in use Early Secret
be HKDF-Extract(0, 0). For the computation of the binder_secret, the will still be HKDF-Extract(0, 0). For the computation of the
label is "ext binder" for external PSKs (those provisioned outside of binder_secret, the label is "ext binder" for external PSKs (those
TLS) and "res binder" for resumption PSKs (those provisioned as the provisioned outside of TLS) and "res binder" for resumption PSKs
resumption master secret of a previous handshake). The different (those provisioned as the resumption master secret of a previous
labels prevent the substitution of one type of PSK for the other. handshake). The different labels prevent the substitution of one
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 Keys and IVs
skipping to change at page 91, line 17 skipping to change at page 96, line 16
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.
The exporter value is computed as: The exporter value is computed as:
HKDF-Expand-Label(Derive-Secret(Secret, label, ""), TLS-Exporter(label, context_value, key_length) =
"exporter", Hash(context_value), key_length) HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"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, especially on a
server where a single interface can make the early exporter server where a single interface can make the early exporter
inaccessible. inaccessible.
skipping to change at page 92, line 21 skipping to change at page 97, line 21
consistent server state. Specifically, if a server system has consistent server state. Specifically, if a server system has
multiple zones where tickets from zone A will not be accepted in multiple zones where tickets from zone A will not be accepted in
zone B, then an attacker can duplicate a ClientHello and early zone B, then an attacker can duplicate a ClientHello and early
data intended for A to both A and B. At A, the data will be data intended for A to both A and B. At A, the data will be
accepted in 0-RTT, but at B the server will reject 0-RTT data and accepted in 0-RTT, but at B the server will reject 0-RTT data and
instead force a full handshake. If the attacker blocks the instead force a full handshake. If the attacker blocks the
ServerHello from A, then the client will complete the handshake ServerHello from A, then the client will complete the handshake
with B and probably retry the request, leading to duplication on with B and probably retry the request, leading to duplication on
the server system as a whole. the server system as a whole.
The first class of attack can be prevented by the mechanism described The first class of attack can be prevented by sharing state to
in this section. Servers need not permit 0-RTT at all, but those guarantee that the 0-RTT data is accepted at most once. Servers
which do SHOULD implement either the single-use tickets or SHOULD provide that level of replay safety, by implementing one of
ClientHello recording techniques described in the following two the methods described in this section or by equivalent means. It is
sections. understood, however, that due to operational concerns not all
deployments will maintain state at that level. Therefore, in normal
operation, clients will not know which, if any, of these mechanisms
servers actually implement and hence MUST only send early data which
they deem safe to be replayed.
In addition to the direct effects of replays, there is a class of
attacks where even operations normally considered idempotent could be
exploited by a large number of replays (timing attacks, resource
limit exhaustion and others described in Appendix E.5). Those can be
mitigated by ensuring that every 0-RTT payload can be replayed only a
limited number of times. The server MUST ensure that any instance of
it (be it a machine, a thread or any other entity within the relevant
serving infrastructure) would accept 0-RTT for the same 0-RTT
handshake at most once; this limits the number of replays to the
number of server instances in the deployment. Such a guarantee can
be accomplished by locally recording data from recently-received
ClientHellos and rejecting repeats, or by any other method that
provides the same or a stronger guarantee. The "at most once per
server instance" guarantee is a minimum requirement; servers SHOULD
limit 0-RTT replays further when feasible.
The second class of attack cannot be prevented at the TLS layer and The second class of attack cannot be prevented at the TLS layer and
MUST be dealt with by any application. Note that any application MUST be dealt with by any application. Note that any application
whose clients implement any kind of retry behavior already needs to whose clients implement any kind of retry behavior already needs to
implement some sort of anti-replay defense. implement some sort of anti-replay defense.
In normal operation, clients will not know which, if any, of these
mechanisms servers actually implement and therefore MUST only send
early data which they are willing to have subject to the attacks
described in Appendix E.5.
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 security. This improves established using one PSK enjoy forward secrecy. This improves
security for all 0-RTT data and PSK usage when PSK is used without security 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
skipping to change at page 93, line 22 skipping to change at page 98, line 39
An alternative form of anti-replay is to record a unique value An alternative form of anti-replay is to record a unique value
derived from the ClientHello (generally either the random value or derived from the ClientHello (generally either the random value or
the PSK binder) and reject duplicates. Recording all ClientHellos the PSK binder) and reject duplicates. Recording all ClientHellos
causes state to grow without bound, but a server can instead record causes state to grow without bound, but a server can instead record
ClientHellos within a given time window and use the ClientHellos within a given time window and use the
"obfuscated_ticket_age" to ensure that tickets aren't reused outside "obfuscated_ticket_age" to ensure that tickets aren't reused outside
that window. that window.
In order to implement this, when a ClientHello is received, the In order to implement this, when a ClientHello is received, the
server first verifies the PSK binder as described Section 4.2.10. It server first verifies the PSK binder as described Section 4.2.11. It
then computes the expected_arrival_time as described in the next then computes the expected_arrival_time as described in the next
section and rejects 0-RTT if it is outside the recording window, section and rejects 0-RTT if it is outside the recording window,
falling back to the 1-RTT handshake. falling back to the 1-RTT handshake.
If the expected arrival time is in the window, then the server checks If the expected arrival time is in the window, then the server checks
to see if it has recorded a matching ClientHello. If one is found, to see if it has recorded a matching ClientHello. If one is found,
it either aborts the handshake with an "illegal_parameter" alert or it either aborts the handshake with an "illegal_parameter" alert or
accepts the PSK but reject 0-RTT. If no matching ClientHello is accepts the PSK but reject 0-RTT. If no matching ClientHello is
found, then it accepts 0-RTT and then stores the ClientHello for as found, then it accepts 0-RTT and then stores the ClientHello for as
long as the expected_arrival_time is inside the window. Servers MAY long as the expected_arrival_time is inside the window. Servers MAY
also implement data stores with false positives, such as Bloom also implement data stores with false positives, such as Bloom
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.10. 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. This will cause the ClientHello
to be accepted, and may casue side effects such as replay cache to be accepted, and may cause side effects such as replay cache
pollution, although any 0-RTT data will not be decryptable because it pollution, although any 0-RTT data will not be decryptable because it
will use different keys. If the validated binder or the will use different keys. If the validated binder or the
ClientHello.random are used as the storage key, then this attack is ClientHello.random are used as the storage key, then this attack is
not possible. 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,
skipping to change at page 96, line 17 skipping to change at page 101, line 33
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
- Supported Versions ("supported_versions"; Section 4.2.1) - Supported Versions ("supported_versions"; Section 4.2.1)
- Cookie ("cookie"; Section 4.2.2) - Cookie ("cookie"; Section 4.2.2)
- Signature Algorithms ("signature_algorithms"; Section 4.2.3) - Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- Negotiated Groups ("supported_groups"; Section 4.2.6) - Negotiated Groups ("supported_groups"; Section 4.2.7)
- Key Share ("key_share"; Section 4.2.7) - Key Share ("key_share"; Section 4.2.8)
- Server Name Indication ("server_name"; Section 3 of [RFC6066]) - Server Name Indication ("server_name"; Section 3 of [RFC6066])
All implementations MUST send and use these extensions when offering All implementations MUST send and use these extensions when offering
applicable features: applicable features:
- "supported_versions" is REQUIRED for all ClientHello messages. - "supported_versions" is REQUIRED for all ClientHello, ServerHello
and HelloRetryRequest messages.
- "signature_algorithms" is REQUIRED for certificate authentication. - "signature_algorithms" is REQUIRED for certificate authentication.
- "supported_groups" is REQUIRED for ClientHello messages using DHE - "supported_groups" is REQUIRED for ClientHello messages using DHE
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.
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 0x0304 the highest version number contained in its body. extension with 0x0304 as the highest version number contained in its
Such a ClientHello message MUST meet the following requirements: body. Such a ClientHello message MUST meet the following
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 97, line 46 skipping to change at page 103, line 16
Standards Action [RFC5226]. Standards Action [RFC5226].
- TLS Alert Registry: Future values are allocated via Standards - TLS Alert Registry: Future values are allocated via Standards
Action [RFC5226]. IANA [SHALL update/has updated] this registry Action [RFC5226]. IANA [SHALL update/has updated] this registry
to include values for "missing_extension" and to include values for "missing_extension" and
"certificate_required". "certificate_required".
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC5226]. IANA [SHALL update/has updated] this Standards Action [RFC5226]. IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the "hello_retry_request", "new_session_ticket" and to add the
"encrypted_extensions", "end_of_early_data", "key_update", and "hello_retry_request_RESERVED", "encrypted_extensions",
"handshake_hash" values. "end_of_early_data", "key_update", and "message_hash" values.
This document also uses the TLS ExtensionType Registry originally This document also uses the TLS ExtensionType Registry originally
created in [RFC4366]. IANA has updated it to reference this created in [RFC4366]. IANA has updated it to reference this
document. The registry and its allocation policy is listed below: document. The registry and its allocation policy is listed below:
- IANA [SHALL update/has updated] this registry to include the - IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes", "key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions", "early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", and "certificate_authorities", "oid_filters", and
"post_handshake_auth" extensions with the values defined in this "post_handshake_auth" extensions with the values defined in this
skipping to change at page 98, line 22 skipping to change at page 103, line 41
- 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 a new registry to be maintained by
IANA: IANA:
- TLS SignatureScheme Registry: Values with the first byte in the - TLS SignatureScheme Registry: Values with the first byte in the
range 0-254 (decimal) are assigned via Specification Required range 0-253 (decimal) are assigned via Specification Required
[RFC5226]. Values with the first byte 255 (decimal) are reserved [RFC5226]. Values with the first byte 254 or 255 (decimal) are
for Private Use [RFC5226]. Values with the first byte in the reserved for Private Use [RFC5226]. Values with the first byte in
range 0-6 or with the second byte in the range 0-3 that are not the range 0-6 or with the second byte in the range 0-3 that are
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_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 98, line 48 skipping to change at page 104, line 20
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.
[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, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[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,
<http://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, <http://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<http://www.rfc-editor.org/info/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<http://www.rfc-editor.org/info/rfc7507>. <https://www.rfc-editor.org/info/rfc7507>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<http://www.rfc-editor.org/info/rfc7539>. <https://www.rfc-editor.org/info/rfc7539>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)", Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016, RFC 7919, DOI 10.17487/RFC7919, August 2016,
<http://www.rfc-editor.org/info/rfc7919>. <https://www.rfc-editor.org/info/rfc7919>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<http://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[SHS] National Institute of Standards and Technology, U.S. [SHS] Dang, Q., "Secure Hash Standard", National Institute of
Department of Commerce, "Secure Hash Standard", NIST FIPS Standards and Technology report,
PUB 180-4, March 2012. DOI 10.6028/nist.fips.180-4, July 2015.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
skipping to change at page 102, line 5 skipping to change at page 107, line 27
<https://eprint.iacr.org/2015/394>. <https://eprint.iacr.org/2015/394>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of
Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings
of CRYPTO 2016 , 2016, <https://eprint.iacr.org/2016/564>. of CRYPTO 2016 , 2016, <https://eprint.iacr.org/2016/564>.
[CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-
Compromise Security", IEEE Computer Security Foundations Compromise Security", IEEE Computer Security Foundations
Symposium , 2015. Symposium , 2015.
[CHECKOWAY]
Checkoway, S., Shacham, H., Maskiewicz, J., Garman, C.,
Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann,
R., and E. Rescorla, "A Systematic Analysis of the Juniper
Dual EC Incident", Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security
- CCS'16, DOI 10.1145/2976749.2978395, 2016.
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T.,
and S. Scott, "Awkward Handshake: Possible mismatch of and S. Scott, "Awkward Handshake: Possible mismatch of
client/server view on client authentication in post- client/server view on client authentication in post-
handshake mode in Revision 18", 2017, handshake mode in Revision 18", 2017,
<https://www.ietf.org/mail-archive/web/tls/current/ <https://www.ietf.org/mail-archive/web/tls/current/
msg22382.html>. msg22382.html>.
[CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe,
"Automated Analysis and Verification of TLS 1.3: 0-RTT, "Automated Analysis and Verification of TLS 1.3: 0-RTT,
Resumption and Delayed Authentication", Proceedings of Resumption and Delayed Authentication", Proceedings of
skipping to change at page 103, line 31 skipping to change at page 109, line 11
identification using passive SSL/TLS fingerprinting", identification using passive SSL/TLS fingerprinting",
EURASIP Journal on Information Security Vol. 2016, EURASIP Journal on Information Security Vol. 2016,
DOI 10.1186/s13635-016-0030-7, February 2016. DOI 10.1186/s13635-016-0030-7, February 2016.
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
"Prying Open Pandora's Box: KCI Attacks against TLS", "Prying Open Pandora's Box: KCI Attacks against TLS",
Proceedings of USENIX Workshop on Offensive Technologies , Proceedings of USENIX Workshop on Offensive Technologies ,
2015. 2015.
[I-D.ietf-tls-iana-registry-updates] [I-D.ietf-tls-iana-registry-updates]
Salowey, J. and S. Turner, "D/TLS IANA Registry Updates", Salowey, J. and S. Turner, "IANA Registry Updates for TLS
draft-ietf-tls-iana-registry-updates-01 (work in and DTLS", draft-ietf-tls-iana-registry-updates-02 (work
progress), April 2017. in progress), October 2017.
[I-D.ietf-tls-tls13-vectors] [I-D.ietf-tls-tls13-vectors]
Thomson, M., "Example Handshake Traces for TLS 1.3", Thomson, M., "Example Handshake Traces for TLS 1.3",
draft-ietf-tls-tls13-vectors-01 (work in progress), June draft-ietf-tls-tls13-vectors-02 (work in progress), July
2017. 2017.
[IEEE1363] [IEEE1363]
IEEE, "Standard Specifications for Public Key IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363 , 2000. Cryptography", IEEE 1363 , 2000.
[KEYAGREEMENT] [KEYAGREEMENT]
Barker, E., Lily Chen, ., Roginsky, A., and M. Smid, Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special Using Discrete Logarithm Cryptography", National Institute
Publication 800-38D, May 2013. of Standards and Technology report,
DOI 10.6028/nist.sp.800-56ar2, May 2013.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,
2010, <https://eprint.iacr.org/2010/264>. 2010, <https://eprint.iacr.org/2010/264>.
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , Authentication in TLS 1.3", Proceedings of ACM CCS 2016 ,
2016, <https://eprint.iacr.org/2016/711>. 2016, <https://eprint.iacr.org/2016/711>.
skipping to change at page 104, line 35 skipping to change at page 110, line 18
allowed during PSK", 2015, <https://www.ietf.org/mail- allowed during PSK", 2015, <https://www.ietf.org/mail-
archive/web/tls/current/msg18215.html>. archive/web/tls/current/msg18215.html>.
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
Key: A Comparative Analysis of the Security of Re-keying Key: A Comparative Analysis of the Security of Re-keying
Techniques", ASIACRYPT2000 , October 2000. Techniques", ASIACRYPT2000 , October 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>. <https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<http://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006, DOI 10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>. <https://www.rfc-editor.org/info/rfc4492>.
[RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User
Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, Mapping Extension", RFC 4681, DOI 10.17487/RFC4681,
October 2006, <http://www.rfc-editor.org/info/rfc4681>. October 2006, <https://www.rfc-editor.org/info/rfc4681>.
[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, <http://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>. <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, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-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, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>. <https://www.rfc-editor.org/info/rfc5929>.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication", for Transport Layer Security (TLS) Authentication",
RFC 6091, DOI 10.17487/RFC6091, February 2011, RFC 6091, DOI 10.17487/RFC6091, February 2011,
<http://www.rfc-editor.org/info/rfc6091>. <https://www.rfc-editor.org/info/rfc6091>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <http://www.rfc-editor.org/info/rfc6176>. 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520, (DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012, DOI 10.17487/RFC6520, February 2012,
<http://www.rfc-editor.org/info/rfc6520>. <https://www.rfc-editor.org/info/rfc6520>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015, DOI 10.17487/RFC7465, February 2015,
<http://www.rfc-editor.org/info/rfc7465>. <https://www.rfc-editor.org/info/rfc7465>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015, DOI 10.17487/RFC7568, June 2015,
<http://www.rfc-editor.org/info/rfc7568>. <https://www.rfc-editor.org/info/rfc7568>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello
Padding Extension", RFC 7685, DOI 10.17487/RFC7685, Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
October 2015, <http://www.rfc-editor.org/info/rfc7685>. October 2015, <https://www.rfc-editor.org/info/rfc7685>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>. <https://www.rfc-editor.org/info/rfc7924>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM v. 21, n. 2, pp. Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
120-126., February 1978. 120-126., February 1978.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to
authenticated Diffie-Hellman and its use in the IKE authenticated Diffie-Hellman and its use in the IKE
protocols", Proceedings of CRYPTO 2003 , 2003. protocols", Proceedings of CRYPTO 2003 , 2003.
skipping to change at page 108, line 5 skipping to change at page 113, line 9
[TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are
practical", USENIX Security Symposium, 2003. practical", USENIX Security Symposium, 2003.
[X501] "Information Technology - Open Systems Interconnection - [X501] "Information Technology - Open Systems Interconnection -
The Directory: Models", ITU-T X.501, 1993. The Directory: Models", ITU-T X.501, 1993.
12.3. URIs 12.3. URIs
[1] mailto:tls@ietf.org [1] mailto:tls@ietf.org
[2] https://www.ietf.org/mailman/listinfo/tls
[3] https://www.ietf.org/mail-archive/web/tls/current/index.html
Appendix A. State Machine Appendix A. State Machine
This section provides a summary of the legal state transitions for This section provides a summary of the legal state transitions for
the client and server handshakes. State names (in all capitals, the client and server handshakes. State names (in all capitals,
e.g., START) have no formal meaning but are provided for ease of e.g., START) have no formal meaning but are provided for ease of
comprehension. Actions which are taken only in certain circumstances comprehension. Actions which are taken only in certain circumstances
are indicated in []. The notation "K_{send,recv} = foo" means "set are indicated in []. The notation "K_{send,recv} = foo" means "set
the send/recv key to the given key". the send/recv key to the given key".
A.1. Client A.1. Client
skipping to change at page 109, line 23 skipping to change at page 115, line 23
NEGOTIATED NEGOTIATED
| Send ServerHello | Send ServerHello
| K_send = handshake | K_send = handshake
| Send EncryptedExtensions | Send EncryptedExtensions
| [Send CertificateRequest] | [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify] Can send | [Send Certificate + CertificateVerify]
app data | Send Finished app data | Send Finished
after --> | K_send = application after --> | K_send = application
here +--------+--------+ here +--------+--------+
No 0-RTT | | 0-RTT No 0-RTT | | 0-RTT
K_recv = handshake | | K_recv = early_data
[Skip decrypt errors] | WAIT_EOED <---+
| Recv | | | Recv
| EndOfEarlyData | | | Early data
| K_recv = | +-----+
| handshake |
| | | |
+> WAIT_FLIGHT2 <-+ K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
| |
+--------+--------+ +--------+--------+
No auth | | Client auth No auth | | Client auth
| | | |
| v | v
| WAIT_CERT | WAIT_CERT
| Recv | | Recv Certificate | Recv | | Recv Certificate
| empty | v | empty | v
| Certificate | WAIT_CV | Certificate | WAIT_CV
| | | Recv | | | Recv
skipping to change at page 110, line 11 skipping to change at page 116, line 11
This section describes protocol types and constants. Values listed This section describes protocol types and constants. Values listed
as _RESERVED were used in previous versions of TLS and are listed as _RESERVED were used in previous versions of TLS and are listed
here for completeness. TLS 1.3 implementations MUST NOT send them here for completeness. TLS 1.3 implementations MUST NOT send them
but might receive them from older TLS implementations. 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_RESERVED(20), change_cipher_spec(20),
alert(21), alert(21),
handshake(22), handshake(22),
application_data(23), application_data(23),
(255) (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
struct { struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
ContentType type; ContentType type;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} TLSInnerPlaintext; } TLSInnerPlaintext;
struct { struct {
ContentType opaque_type = 23; /* application_data */ ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length; uint16 length;
opaque encrypted_record[length]; opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext; } TLSCiphertext;
B.2. Alert Messages B.2. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), unexpected_message(10),
bad_record_mac(20), bad_record_mac(20),
decryption_failed_RESERVED(21), decryption_failed_RESERVED(21),
skipping to change at page 112, line 14 skipping to change at page 118, line 14
B.3. Handshake Protocol B.3. Handshake Protocol
enum { enum {
hello_request_RESERVED(0), hello_request_RESERVED(0),
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
hello_verify_request_RESERVED(3), hello_verify_request_RESERVED(3),
new_session_ticket(4), new_session_ticket(4),
end_of_early_data(5), end_of_early_data(5),
hello_retry_request(6), hello_retry_request_RESERVED(6),
encrypted_extensions(8), encrypted_extensions(8),
certificate(11), certificate(11),
server_key_exchange_RESERVED(12), server_key_exchange_RESERVED(12),
certificate_request(13), certificate_request(13),
server_hello_done_RESERVED(14), server_hello_done_RESERVED(14),
certificate_verify(15), certificate_verify(15),
client_key_exchange_RESERVED(16), client_key_exchange_RESERVED(16),
finished(20), finished(20),
key_update(24), key_update(24),
message_hash(254), message_hash(254),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case hello_retry_request: HelloRetryRequest;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
} body; };
} Handshake; } Handshake;
B.3.1. Key Exchange Messages B.3.1. Key Exchange Messages
uint16 ProtocolVersion; uint16 ProtocolVersion;
opaque Random[32]; opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
struct { struct {
skipping to change at page 113, line 14 skipping to change at page 119, line 13
struct { struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion version; ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite; CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>; Extension extensions<6..2^16-1>;
} ServerHello; } ServerHello;
struct { struct {
ProtocolVersion server_version;
CipherSuite cipher_suite;
Extension extensions<2..2^16-1>;
} HelloRetryRequest;
struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
server_name(0), /* RFC 6066 */ server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */ max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */ status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 4492, 7919 */ supported_groups(10), /* RFC 4492, 7919 */
signature_algorithms(13), /* RFC 5246 */ signature_algorithms(13), /* [[this document]] */
use_srtp(14), /* RFC 5764 */ use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */ heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */ application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */ signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */ client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */ server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */ padding(21), /* RFC 7685 */
key_share(40), /* [[this document]] */ key_share(40), /* [[this document]] */
pre_shared_key(41), /* [[this document]] */ pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */ early_data(42), /* [[this document]] */
skipping to change at page 114, line 14 skipping to change at page 120, line 9
post_handshake_auth(49), /* [[this document]] */ post_handshake_auth(49), /* [[this document]] */
(65535) (65535)
} ExtensionType; } ExtensionType;
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
struct { struct {
select (Handshake.msg_type) { KeyShareEntry client_shares<0..2^16-1>;
case client_hello: } KeyShareClientHello;
KeyShareEntry client_shares<0..2^16-1>;
case hello_retry_request: struct {
NamedGroup selected_group; NamedGroup selected_group;
} KeyShareHelloRetryRequest;
case server_hello: struct {
KeyShareEntry server_share; KeyShareEntry server_share;
}; } KeyShareServerHello;
} KeyShare;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
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;
struct {} Empty; struct {} Empty;
struct { struct {
skipping to change at page 114, line 50 skipping to change at page 120, line 50
} EarlyDataIndication; } EarlyDataIndication;
struct { struct {
opaque identity<1..2^16-1>; opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
} PskIdentity; } PskIdentity;
opaque PskBinderEntry<32..255>; opaque PskBinderEntry<32..255>;
struct { struct {
select (Handshake.msg_type) { PskIdentity identities<7..2^16-1>;
case client_hello: PskBinderEntry binders<33..2^16-1>;
PskIdentity identities<7..2^16-1>; } OfferedPsks;
PskBinderEntry binders<33..2^16-1>;
case server_hello: struct {
uint16 selected_identity; select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
}; };
} PreSharedKeyExtension; } PreSharedKeyExtension;
B.3.1.1. Version Extension B.3.1.1. Version Extension
struct { struct {
ProtocolVersion versions<2..254>; select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello:
ProtocolVersion selected_version;
};
} SupportedVersions; } SupportedVersions;
B.3.1.2. Cookie Extension B.3.1.2. Cookie Extension
struct { struct {
opaque cookie<1..2^16-1>; opaque cookie<1..2^16-1>;
} Cookie; } Cookie;
B.3.1.3. Signature Algorithm Extension B.3.1.3. Signature Algorithm Extension
enum { enum {
skipping to change at page 117, line 5 skipping to change at page 123, line 5
private_use(0xFE00..0xFFFF), private_use(0xFE00..0xFFFF),
(0xFFFF) (0xFFFF)
} SignatureScheme; } SignatureScheme;
struct { struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>; SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList; } SignatureSchemeList;
B.3.1.4. Supported Groups Extension B.3.1.4. Supported Groups Extension
enum { enum {
unallocated_RESERVED(0x0000),
/* Elliptic Curve Groups (ECDHE) */ /* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016), obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C), obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E), x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */ /* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096 (0x0102), ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104), ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */ /* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF), ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF), ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02), obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
skipping to change at page 118, line 19 skipping to change at page 124, line 19
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;
struct {} PostHandshakeAuth;
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
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} 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 */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509: case X509:
opaque cert_data<1..2^24-1>; opaque cert_data<1..2^24-1>;
}; };
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} CertificateEntry; } CertificateEntry;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
skipping to change at page 119, line 35 skipping to change at page 125, line 42
struct { struct {
opaque verify_data[Hash.length]; opaque verify_data[Hash.length];
} Finished; } Finished;
B.3.4. Ticket Establishment B.3.4. Ticket Establishment
struct { struct {
uint32 ticket_lifetime; uint32 ticket_lifetime;
uint32 ticket_age_add; uint32 ticket_age_add;
opaque ticket_nonce<1..255>; opaque ticket_nonce<0..255>;
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;
B.3.5. Updating Keys B.3.5. Updating Keys
struct {} EndOfEarlyData; struct {} EndOfEarlyData;
enum { enum {
update_not_requested(0), update_requested(1), (255) update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest; } KeyUpdateRequest;
struct { struct {
KeyUpdateRequest request_update; KeyUpdateRequest request_update;
} KeyUpdate; } KeyUpdate;
skipping to change at page 121, line 26 skipping to change at page 127, line 38
TLS requires a cryptographically secure pseudorandom number generator TLS requires a cryptographically secure pseudorandom number generator
(CSPRNG). In most cases, the operating system provides an (CSPRNG). In most cases, the operating system provides an
appropriate facility such as /dev/urandom, which should be used appropriate facility such as /dev/urandom, which should be used
absent other (performance) concerns. It is RECOMMENDED to use an absent other (performance) concerns. It is RECOMMENDED to use an
existing CSPRNG implementation in preference to crafting a new one. existing CSPRNG implementation in preference to crafting a new one.
Many adequate cryptographic libraries are already available under Many adequate cryptographic libraries are already available under
favorable license terms. Should those prove unsatisfactory, favorable license terms. Should those prove unsatisfactory,
[RFC4086] provides guidance on the generation of random values. [RFC4086] provides guidance on the generation of random values.
TLS uses random values both in public protocol fields such as the
public Random values in the ClientHello and ServerHello and to
generate keying material. With a properly functioning CSPRNG, this
does not present a security problem as it is not feasible to
determine the CSPRNG state from its output. However, with a broken
CSPRNG, it may be possible for an attacker to use the public output
to determine the CSPRNG internal state and thereby predict the keying
material, as documented in [CHECKOWAY]. Implementations can provide
extra security against this form of attack by using separate CSPRNGs
to generate public and private values.
C.2. Certificates and Authentication C.2. Certificates and Authentication
Implementations are responsible for verifying the integrity of Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation certificates and should generally support certificate revocation
messages. Absent a specific indication from an application profile, messages. Absent a specific indication from an application profile,
Certificates should always be verified to ensure proper signing by a Certificates should always be verified to ensure proper signing by a
trusted Certificate Authority (CA). The selection and addition of trusted Certificate Authority (CA). The selection and addition of
trust anchors should be done very carefully. Users should be able to trust anchors should be done very carefully. Users should be able to
view information about the certificate and trust anchor. view information about the certificate and trust anchor.
Applications SHOULD also enforce minimum and maximum key sizes. For Applications SHOULD also enforce minimum and maximum key sizes. For
skipping to change at page 122, line 32 skipping to change at page 129, line 11
suitable certificate is available, do you correctly send an empty suitable certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see Certificate message, instead of omitting the whole message (see
Section 4.4.2.3)? Section 4.4.2.3)?
- When processing the plaintext fragment produced by AEAD-Decrypt - When processing the plaintext fragment produced by AEAD-Decrypt
and scanning from the end for the ContentType, do you avoid and scanning from the end for the ContentType, do you avoid
scanning past the start of the cleartext in the event that the scanning past the start of the cleartext in the event that the
peer has sent a malformed plaintext of all-zeros? peer has sent a malformed plaintext of all-zeros?
- Do you properly ignore unrecognized cipher suites (Section 4.1.2), - Do you properly ignore unrecognized cipher suites (Section 4.1.2),
hello extensions (Section 4.2), named groups (Section 4.2.6), key hello extensions (Section 4.2), named groups (Section 4.2.7), key
shares Section 4.2.7, supported versions Section 4.2.1, and shares (Section 4.2.8), supported versions (Section 4.2.1), and
signature algorithms (Section 4.2.3) in the ClientHello? signature algorithms (Section 4.2.3) in the ClientHello?
- As a server, do you send a HelloRetryRequest to clients which - As a server, do you send a HelloRetryRequest to clients which
support a compatible (EC)DHE group but do not predict it in the support a compatible (EC)DHE group but do not predict it in the
"key_share" extension? As a client, do you correctly handle a "key_share" extension? As a client, do you correctly handle a
HelloRetryRequest from the server? HelloRetryRequest from the server?
Cryptographic details: Cryptographic details:
- What countermeasures do you use to prevent timing attacks - What countermeasures do you use to prevent timing attacks
[TIMING]? [TIMING]?
- When using Diffie-Hellman key exchange, do you correctly preserve - When using Diffie-Hellman key exchange, do you correctly preserve
leading zero bytes in the negotiated key (see Section 7.4.1)? leading zero bytes in the negotiated key (see Section 7.4.1)?
- Does your TLS client check that the Diffie-Hellman parameters sent - Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable, (see Section 4.2.7.1)? by the server are acceptable, (see Section 4.2.8.1)?
- Do you use a strong and, most importantly, properly seeded random - Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix C.1) when generating Diffie-Hellman number generator (see Appendix C.1) when generating Diffie-Hellman
private values, the ECDSA "k" parameter, and other security- private values, the ECDSA "k" parameter, and other security-
critical values? It is RECOMMENDED that implementations implement critical values? It is RECOMMENDED that implementations implement
"deterministic ECDSA" as specified in [RFC6979]. "deterministic ECDSA" as specified in [RFC6979].
- Do you zero-pad Diffie-Hellman public key values to the group size - Do you zero-pad Diffie-Hellman public key values to the group size
(see Section 4.2.7.1)? (see Section 4.2.8.1)?
- Do you verify signatures after making them to protect against RSA- - Do you verify signatures after making them to protect against RSA-
CRT key leaks? [FW15] CRT key leaks? [FW15]
C.4. Client Tracking Prevention C.4. Client Tracking Prevention
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
a ticket allows passive observers to correlate different connections. a ticket allows passive observers to correlate different connections.
Servers that issue tickets SHOULD offer at least as many tickets as Servers that issue tickets SHOULD offer at least as many tickets as
the number of connections that a client might use; for example, a web the number of connections that a client might use; for example, a web
skipping to change at page 124, line 50 skipping to change at page 131, line 26
up to the server CertificateVerify, implementations which support up to the server CertificateVerify, implementations which support
both TLS 1.3 and earlier versions SHOULD indicate the use of the both TLS 1.3 and earlier versions SHOULD indicate the use of the
Extended Master Secret extension in their APIs whenever TLS 1.3 is Extended Master Secret extension in their APIs whenever TLS 1.3 is
used. used.
D.1. Negotiating with an older server D.1. Negotiating with an older server
A TLS 1.3 client who wishes to negotiate with servers that do not A TLS 1.3 client who wishes to negotiate with servers that do not
support TLS 1.3 will send a normal TLS 1.3 ClientHello containing support TLS 1.3 will send a normal TLS 1.3 ClientHello containing
0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct
version in the "supported_versions" extension. If the server does version(s) in the "supported_versions" extension. If the server does
not support TLS 1.3 it will respond with a ServerHello containing an not support TLS 1.3 it will respond with a ServerHello containing an
older version number. If the client agrees to use this version, the older version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol. negotiation will proceed as appropriate for the negotiated protocol.
A client using a ticket for resumption SHOULD initiate the connection A client using a ticket for resumption SHOULD initiate the connection
using the version that was previously negotiated. using the version that was previously negotiated.
Note that 0-RTT data is not compatible with older servers and SHOULD Note that 0-RTT data is not compatible with older servers and SHOULD
NOT be sent absent knowledge that the server supports TLS 1.3. See NOT be sent absent knowledge that the server supports TLS 1.3. See
Appendix D.3. Appendix D.3.
skipping to change at page 125, line 45 skipping to change at page 132, line 25
ServerHello. If the "supported_versions" extension is absent and the ServerHello. If the "supported_versions" extension is absent and the
server only supports versions greater than server only supports versions greater than
ClientHello.legacy_version, the server MUST abort the handshake with ClientHello.legacy_version, the server MUST abort the handshake with
a "protocol_version" alert. a "protocol_version" alert.
Note that earlier versions of TLS did not clearly specify the record Note that earlier versions of TLS did not clearly specify the record
layer version number value in all cases layer version number value in all cases
(TLSPlaintext.legacy_record_version). Servers will receive various (TLSPlaintext.legacy_record_version). Servers will receive various
TLS 1.x versions in this field, but its value MUST always be ignored. TLS 1.x versions in this field, but its value MUST always be ignored.
D.3. Zero-RTT backwards compatibility D.3. 0-RTT backwards compatibility
0-RTT data is not compatible with older servers. An older server 0-RTT data is not compatible with older servers. An older server
will respond to the ClientHello with an older ServerHello, but it will respond to the ClientHello with an older ServerHello, but it
will not correctly skip the 0-RTT data and will fail to complete the will not correctly skip the 0-RTT data and will fail to complete the
handshake. This can cause issues when a client attempts to use handshake. This can cause issues when a client attempts to use
0-RTT, particularly against multi-server deployments. For example, a 0-RTT, particularly against multi-server deployments. For example, a
deployment could deploy TLS 1.3 gradually with some servers deployment could deploy TLS 1.3 gradually with some servers
implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3
deployment could be downgraded to TLS 1.2. deployment could be downgraded to TLS 1.2.
A client that attempts to send 0-RTT data MUST fail a connection if A client that attempts to send 0-RTT data MUST fail a connection if
it receives a ServerHello with TLS 1.2 or older. A client that it receives a ServerHello with TLS 1.2 or older. A client that
attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello, attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello,
but instead send a TLS 1.3 ClientHello without 0-RTT data. but instead send a TLS 1.3 ClientHello without 0-RTT data.
To avoid this error condition, multi-server deployments SHOULD ensure To avoid this error condition, multi-server deployments SHOULD ensure
a uniform and stable deployment of TLS 1.3 without 0-RTT prior to a uniform and stable deployment of TLS 1.3 without 0-RTT prior to
enabling 0-RTT. enabling 0-RTT.
D.4. Backwards Compatibility Security Restrictions D.4. Middlebox Compatibility Mode
Field measurements have found that a significant number of
middleboxes misbehave when a TLS client/server pair negotiates TLS
1.3. Implementations can increase the chance of making connections
through those middleboxes by making the TLS 1.3 handshake look more
like a TLS 1.2 handshake:
- The client always provides a non-empty session ID in the
ClientHello.
- If not offering early data, the client sends a dummy
change_cipher_spec record immediately before its second flight.
This may either be before its second ClientHello or before its
encrypted handshake flight. If offering early data, the record is
placed immediately after the first ClientHello.
- The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a
ServerHello or a HelloRetryRequest.
When put together, these changes make the TLS 1.3 handshake resemble
TLS 1.2 session resumption, which improves the chance of successfully
connecting through middleboxes. This "compatibility mode" is not
explicitly negotiated. The client can opt to provide a session ID or
not and the server has to echo it. Either side can send
change_cipher_spec at any time during the handshake, as they must be
ignored by the peer.
D.5. Backwards Compatibility Security Restrictions
Implementations negotiating use of older versions of TLS SHOULD Implementations negotiating use of older versions of TLS SHOULD
prefer forward secret and AEAD cipher suites, when available. prefer forward secret and AEAD cipher suites, when available.
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
skipping to change at page 131, line 29 skipping to change at page 138, line 40
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.9 for one mechanism to limit the exposure to replay. See Section 4.2.10 for one mechanism 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 134, line 5 skipping to change at page 141, line 14
variable-length padding, which allows the application to produce variable-length padding, which allows the application to produce
arbitrary length encrypted records as well as padding-only cover arbitrary length encrypted records as well as padding-only cover
traffic to conceal the difference between periods of transmission and traffic to conceal the difference between periods of transmission and
periods of silence. Because the padding is encrypted alongside the periods of silence. Because the padding is encrypted alongside the
actual content, an attacker cannot directly determine the length of actual content, an attacker cannot directly determine the length of
the padding, but may be able to measure it indirectly by the use of the padding, but may be able to measure it indirectly by the use of
timing channels exposed during record processing (i.e., seeing how timing channels exposed during record processing (i.e., seeing how
long it takes to process a record or trickling in records to see long it takes to process a record or trickling in records to see
which ones elicit a response from the server). In general, it is not which ones elicit a response from the server). In general, it is not
known how to remove all of these channels because even a constant known how to remove all of these channels because even a constant
time padding removal function will then feed the content into data- time padding removal function will likely feed the content into data-
dependent functions. dependent functions. At minimum, a fully constant time server or
client would require close cooperation with the application layer
protocol implementation, including making that higher level protocol
constant time.
Note: Robust traffic analysis defences will likely lead to inferior Note: Robust traffic analysis defences will likely lead to inferior
performance due to delay in transmitting packets and increased performance due to delay in transmitting packets and increased
traffic volume. traffic volume.
E.4. Side Channel Attacks E.4. Side Channel Attacks
In general, TLS does not have specific defenses against side-channel In general, TLS does not have specific defenses against side-channel
attacks (i.e., those which attack the communications via secondary attacks (i.e., those which attack the communications via secondary
channels such as timing) leaving those to the implementation of the channels such as timing) leaving those to the implementation of the
skipping to change at page 135, line 23 skipping to change at page 142, line 35
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 the
speed of cryptographic operations. In addition, they may be able to speed of cryptographic operations. In addition, they may be able to
overload rate-limiting systems. For further description of these overload rate-limiting systems. For further description of these
attacks, see [Mac17]. attacks, see [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 do not provide complete protection against receiving multiple layer but do not provide complete protection against receiving
copies of client data. TLS 1.3 falls back to the 1-RTT handshake multiple copies of client data. TLS 1.3 falls back to the 1-RTT
when the server does not have any information about the client, e.g., handshake when the server does not have any information about the
because it is in a different cluster which does not share state or client, e.g., because it is in a different cluster which does not
because the ticket has been deleted as described in Section 8.1. If share state or because the ticket has been deleted as described in
the application layer protocol retransmits data in this setting, then Section 8.1. If the application layer protocol retransmits data in
it is possible for an attacker to induce message duplication by this setting, then it is possible for an attacker to induce message
sending the ClientHello to both the original cluster (which processes duplication by sending the ClientHello to both the original cluster
the data immediately) and another cluster which will fall back to (which processes the data immediately) and another cluster which will
1-RTT and process the data upon application layer replay. The scale fall back to 1-RTT and process the data upon application layer
of this attack is limited by the client's willingness to retry replay. The scale of this attack is limited by the client's
transactions and therefore only allows a limited amount of willingness to retry transactions and therefore only allows a limited
duplication, with each copy appearing as a new connection at the amount of duplication, with each copy appearing as a new connection
server. at the server.
If implemented correctly, the mechanisms described in Section 8.1 and If implemented correctly, the mechanisms described in Section 8.1 and
Section 8.2 prevent a replayed ClientHello and its associated 0-RTT Section 8.2 prevent a replayed ClientHello and its associated 0-RTT
data from being accepted multiple times by any cluster with data from being accepted multiple times by any cluster with
consistent state; for servers which limit the use of 0-RTT to one consistent state; for servers which limit the use of 0-RTT to one
cluster for a single ticket, then a given ClientHello and its cluster for a single ticket, then a given ClientHello and its
associated 0-RTT data will only be accepted once. However, if state associated 0-RTT data will only be accepted once. However, if state
is not completely consistent, then an attacker might be able to have is not completely consistent, then an attacker might be able to have
multiple copies of the data be accepted during the replication multiple copies of the data be accepted during the replication
window. Because clients do not know the exact details of server window. Because clients do not know the exact details of server
skipping to change at page 136, line 38 skipping to change at page 143, line 50
In addition, the early exporter SHOULD NOT be used to generate In addition, the early exporter SHOULD NOT be used to generate
server-to-client encryption keys because that would entail the reuse server-to-client encryption keys because that would entail the reuse
of those keys. This parallels the use of the early application of those keys. This parallels the use of the early application
traffic keys only in the client-to-server direction. traffic keys only in the client-to-server direction.
Appendix F. Working Group Information Appendix F. Working Group Information
The discussion list for the IETF TLS working group is located at the The discussion list for the IETF TLS working group is located at the
e-mail address tls@ietf.org [1]. Information on the group and e-mail address tls@ietf.org [1]. Information on the group and
information on how to subscribe to the list is at information on how to subscribe to the list is at
https://www.ietf.org/mailman/listinfo/tls https://www.ietf.org/mailman/listinfo/tls [2]
Archives of the list can be found at: https://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/tls/current/index.html archive/web/tls/current/index.html [3]
Appendix G. Contributors Appendix G. Contributors
- Martin Abadi - Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
- Christopher Allen (co-editor of TLS 1.0) - Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
- Richard Barnes
Cisco
rlb@ipv.sx
- Steven M. Bellovin - Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
- David Benjamin - David Benjamin
Google Google
davidben@google.com davidben@google.com
- Benjamin Beurdouche - Benjamin Beurdouche
INRIA & Microsoft Research INRIA & Microsoft Research
skipping to change at page 137, line 37 skipping to change at page 145, line 5
nelson@bolyard.com nelson@bolyard.com
- Ran Canetti - Ran Canetti
IBM IBM
canetti@watson.ibm.com canetti@watson.ibm.com
- Matt Caswell - Matt Caswell
OpenSSL OpenSSL
matt@openssl.org matt@openssl.org
- Stephen Checkoway
University of Illinois at Chicago
sfc@uic.edu
- Pete Chown - Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
- 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
skipping to change at page 141, line 32 skipping to change at page 149, line 4
- Kyle Rose - Kyle Rose
Akamai Technologies Akamai Technologies
krose@krose.org krose@krose.org
- Jim Roskind - Jim Roskind
Amazon Amazon
jroskind@amazon.com jroskind@amazon.com
- Michael Sabin - Michael Sabin
- Joe Salowey - Joe Salowey
Tableau Software Tableau Software
joe@salowey.net joe@salowey.net
- Rich Salz - Rich Salz
Akamai Akamai
rsalz@akamai.com rsalz@akamai.com
- David Schinazi
Apple Inc.
dschinazi@apple.com
- Sam Scott - Sam Scott
Royal Holloway, University of London Royal Holloway, University of London
me@samjs.co.uk me@samjs.co.uk
- Dan Simon - Dan Simon
Microsoft, Inc. Microsoft, Inc.
dansimon@microsoft.com dansimon@microsoft.com
- Brian Smith - Brian Smith
Independent Independent
skipping to change at page 142, line 29 skipping to change at page 150, line 5
ttaubert@mozilla.com ttaubert@mozilla.com
- Martin Thomson - Martin Thomson
Mozilla Mozilla
mt@mozilla.com mt@mozilla.com
- Sean Turner - Sean Turner
sn3rd sn3rd
sean@sn3rd.com sean@sn3rd.com
- Steven Valdez
Google
svaldez@google.com
- Filippo Valsorda - Filippo Valsorda
Cloudflare Inc. Cloudflare Inc.
filippo@cloudflare.com filippo@cloudflare.com
- Thyla van der Merwe - Thyla van der Merwe
Royal Holloway, University of London Royal Holloway, University of London
tjvdmerwe@gmail.com tjvdmerwe@gmail.com
- Victor Vasiliev
Google
vasilvv@google.com
- Tom Weinstein - Tom Weinstein
- Hoeteck Wee - Hoeteck Wee
Ecole Normale Superieure, Paris Ecole Normale Superieure, Paris
hoeteck@alum.mit.edu hoeteck@alum.mit.edu
- David Wong - David Wong
NCC Group NCC Group
david.wong@nccgroup.trust david.wong@nccgroup.trust
- Tim Wright - Tim Wright
Vodafone Vodafone
timothy.wright@vodafone.com timothy.wright@vodafone.com
- Peter Wu
Independent
peter@lekensteyn.nl
- Kazu Yamamoto - Kazu Yamamoto
Internet Initiative Japan Inc. Internet Initiative Japan Inc.
kazu@iij.ad.jp kazu@iij.ad.jp
Author's Address Author's Address
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
 End of changes. 256 change blocks. 
557 lines changed or deleted 829 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/