draft-ietf-tls-tls13-22.txt   draft-ietf-tls-tls13-23.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246 (if approved) November 29, 2017 Obsoletes: 5077, 5246 (if approved) January 05, 2018
Updates: 4492, 5705, 6066, 6961 (if Updates: 4492, 5705, 6066, 6961 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 2, 2018 Expires: July 9, 2018
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-22 draft-ietf-tls-tls13-23
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 https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 2, 2018. This Internet-Draft will expire on July 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 21 skipping to change at page 2, line 21
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6
1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21
2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 2, line 49 skipping to change at page 2, line 49
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44
4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 47 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 48
4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 48 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49
4.2.6. Post-Handshake Client Authentication . . . . . . . . 49 4.2.6. Post-Handshake Client Authentication . . . . . . . . 50
4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 49 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 50
4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 51 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52
4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 54 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55
4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 54 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56
4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 57 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 58
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 61 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 61 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 62 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 62 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 63
4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 64 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65
4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 65 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66
4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 70 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71
4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 72 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73
4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 73 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 75
4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 74 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75
4.6.1. New Session Ticket Message . . . . . . . . . . . . . 74 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75
4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 76 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 78
4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 77 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 78 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 79 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 81 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82
5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 83 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84
5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 83 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85
5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 85 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86
6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 85 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86
6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 86 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88
6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 87 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 90 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 91
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 90 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92
7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 93 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 95
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 94 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 95
7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 94 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 96
7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 95 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 96
7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 95 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 96
7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 96 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 97
8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 96 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98
8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 98 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 99
8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 98 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 99
8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 99 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 101 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 102
9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 101 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 102
9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 101 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 102
10. Security Considerations . . . . . . . . . . . . . . . . . . . 102 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 103
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 105
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
12.1. Normative References . . . . . . . . . . . . . . . . . . 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.2. Informative References . . . . . . . . . . . . . . . . . 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 106
Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 114 12.2. Informative References . . . . . . . . . . . . . . . . . 109
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 115 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 117
Appendix B. Protocol Data Structures and Constant Values . . . . 115 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 117
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 116 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 116 Appendix B. Protocol Data Structures and Constant Values . . . . 118
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 118 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 119
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 118 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 119
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 123 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 121
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 124 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 121
B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 125 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 126
B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 125 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 127
B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 126 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 128
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 127 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 128
C.1. Random Number Generation and Seeding . . . . . . . . . . 127 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 129
C.2. Certificates and Authentication . . . . . . . . . . . . . 128 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 130
C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 128 C.1. Random Number Generation and Seeding . . . . . . . . . . 130
C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 129 C.2. Certificates and Authentication . . . . . . . . . . . . . 131
C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 130 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 131
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 130 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 132
D.1. Negotiating with an older server . . . . . . . . . . . . 131 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 133
D.2. Negotiating with an older client . . . . . . . . . . . . 132 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 133
D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 132 D.1. Negotiating with an older server . . . . . . . . . . . . 134
D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 132 D.2. Negotiating with an older client . . . . . . . . . . . . 135
D.5. Backwards Compatibility Security Restrictions . . . . . . 133 D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 135
Appendix E. Overview of Security Properties . . . . . . . . . . 134 D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 135
E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 134 D.5. Backwards Compatibility Security Restrictions . . . . . . 136
E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 137 Appendix E. Overview of Security Properties . . . . . . . . . . 137
E.1.2. Client Authentication . . . . . . . . . . . . . . . . 138 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 137
E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 138 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 140
E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 138 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 141
E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 139 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 141
E.1.6. External References . . . . . . . . . . . . . . . . . 139 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 141
E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 139 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 142
E.2.1. External References . . . . . . . . . . . . . . . . . 140 E.1.6. External References . . . . . . . . . . . . . . . . . 142
E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 140 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 142
E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 141 E.2.1. External References . . . . . . . . . . . . . . . . . 143
E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 142 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 143
E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 143 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 144
Appendix F. Working Group Information . . . . . . . . . . . . . 143 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 145
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 144 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 146
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150 E.6. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 147
Appendix F. Working Group Information . . . . . . . . . . . . . 147
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 147
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 154
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 6, line 25 skipping to change at page 6, line 32
the protocol attributes used to negotiate Elliptic Curves. Because the protocol attributes used to negotiate Elliptic Curves. Because
TLS 1.3 changes the way keys are derived it updates [RFC5705] as TLS 1.3 changes the way keys are derived it updates [RFC5705] as
described in Section 7.5 it also changes how OCSP messages are described in Section 7.5 it also changes how OCSP messages are
carried and therefore updates [RFC6066] and obsoletes [RFC6961] as carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
described in section Section 4.4.2.1. described in section Section 4.4.2.1.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used: The following terms are used:
client: The endpoint initiating the TLS connection. client: The endpoint initiating the TLS connection.
connection: A transport-layer connection between two endpoints. connection: A transport-layer connection between two endpoints.
endpoint: Either the client or server of the connection. endpoint: Either the client or server of the connection.
handshake: An initial negotiation between client and server that handshake: An initial negotiation between client and server that
skipping to change at page 7, line 8 skipping to change at page 7, line 14
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-23 - Renumber key_share (*)
- Add a new extension and new code points to allow negotiating PSS
separately for certificates and CertificateVerify (*)
- Slightly restrict when CCS must be accepted to amke implementation
easier.
- Document protocol invariants
- Add some text on the security of static RSA.
draft-22 - Implement changes for improved middlebox penetration (*) draft-22 - Implement changes for improved middlebox penetration (*)
- Move server_certificate_type to encrypted extensions (*) - Move server_certificate_type to encrypted extensions (*)
- Allow resumption with a different SNI (*) - Allow resumption with a different SNI (*)
- Padding extension can change on HRR (*) - Padding extension can change on HRR (*)
- Allow an empty ticket_nonce (*) - Allow an empty ticket_nonce (*)
skipping to change at page 16, line 44 skipping to change at page 17, line 13
- RSASSA-PSS signature schemes are defined in Section 4.2.3. - RSASSA-PSS signature schemes are defined in Section 4.2.3.
- The "supported_versions" ClientHello extension can be used to - The "supported_versions" ClientHello extension can be used to
negotiate the version of TLS to use, in preference to the negotiate the version of TLS to use, in preference to the
legacy_version field of the ClientHello. legacy_version field of the ClientHello.
An implementation of TLS 1.3 that also supports TLS 1.2 might need to An implementation of TLS 1.3 that also supports TLS 1.2 might need to
include changes to support these changes even when TLS 1.3 is not in include changes to support these changes even when TLS 1.3 is not in
use. See the referenced sections for more details. use. See the referenced sections for more details.
Additionally, this document clarifies some compliance requirements
for earlier versions of TLS; see Section 9.3.
2. Protocol Overview 2. Protocol Overview
The cryptographic parameters used by the secure channel are produced The cryptographic parameters used by the secure channel are produced
by the TLS handshake protocol. This sub-protocol of TLS is used by by the TLS handshake protocol. This sub-protocol of TLS is used by
the client and server when first communicating with each other. The the client and server when first communicating with each other. The
handshake protocol allows peers to negotiate a protocol version, handshake protocol allows peers to negotiate a protocol version,
select cryptographic algorithms, optionally authenticate each other, select cryptographic algorithms, optionally authenticate each other,
and establish shared secret keying material. Once the handshake is and establish shared secret keying material. Once the handshake is
complete, the peers use the established keys to protect the complete, the peers use the established keys to protect the
application layer traffic. application layer traffic.
skipping to change at page 34, line 6 skipping to change at page 34, line 6
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). A client which has a Keys in this version (see Section 2.2). A client which has a
cached session ID set by a pre-TLS 1.3 server SHOULD set this cached session ID set by a pre-TLS 1.3 server SHOULD set this
field to that value. In compatibility mode (see Appendix D.4) field to that value. In compatibility mode (see Appendix D.4)
this field MUST be non-empty, so a client not offering a pre-TLS 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 1.3 session MUST generate a new 32-byte value. This value need
not be random but SHOULD be unpredictable to avoid ossification. not be random but SHOULD be unpredictable to avoid implementations
fixating on a specific value (also known as ossification).
Otherwise, it MUST be set as a zero length vector (i.e., a single Otherwise, it MUST be set as a zero length vector (i.e., a single
zero byte length field). 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
skipping to change at page 35, line 6 skipping to change at page 35, line 7
contain extensions (minimally "supported_versions", otherwise they contain extensions (minimally "supported_versions", otherwise they
will be interpreted as TLS 1.2 ClientHello messages). However, TLS will be interpreted as TLS 1.2 ClientHello messages). However, TLS
1.3 servers might receive ClientHello messages without an extensions 1.3 servers might receive ClientHello messages without an extensions
field from prior versions of TLS. The presence of extensions can be field from prior versions of TLS. The presence of extensions can be
detected by determining whether there are bytes following the detected by determining whether there are bytes following the
compression_methods field at the end of the ClientHello. Note that compression_methods field at the end of the ClientHello. Note that
this method of detecting optional data differs from the normal TLS this method of detecting optional data differs from the normal TLS
method of having a variable-length field, but it is used for method of having a variable-length field, but it is used for
compatibility with TLS before extensions were defined. TLS 1.3 compatibility with TLS before extensions were defined. TLS 1.3
servers will need to perform this check first and only attempt to servers will need to perform this check first and only attempt to
negotiate TLS 1.3 if a "supported_version" extension is present. If negotiate TLS 1.3 if the "supported_versions" extension is present.
negotiating a version of TLS prior to 1.3, a server MUST check that If negotiating a version of TLS prior to 1.3, a server MUST check
the message either contains no data after legacy_compression_methods that the message either contains no data after
or that it contains a valid extensions block with no data following. legacy_compression_methods or that it contains a valid extensions
If not, then it MUST abort the handshake with a "decode_error" alert. block with no data following. 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.
skipping to change at page 35, line 38 skipping to change at page 35, line 40
struct { struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id_echo<0..32>; opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite; CipherSuite cipher_suite;
uint8 legacy_compression_method = 0; uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>; Extension extensions<6..2^16-1>;
} ServerHello; } ServerHello;
version In previous versions of TLS, this field was used for version legacy_version In previous versions of TLS, this field was used for
negotiation and represented the selected version number for the version negotiation and represented the selected version number
connection. Unfortunately, some middleboxes fail when presented for the connection. Unfortunately, some middleboxes fail when
with new values. In TLS 1.3, the TLS server indicates its version presented with new values. In TLS 1.3, the TLS server indicates
using the "supported_versions" extension (Section 4.2.1), and the its version using the "supported_versions" extension
legacy_version field MUST be set to 0x0303, which is the version (Section 4.2.1), and the legacy_version field MUST be set to
number for TLS 1.2. (See Appendix D for details about backward 0x0303, which is the version number for TLS 1.2. (See Appendix D
compatibility.) 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_echo The contents of the client's
legacy_session_id field. Note that this field is echoed even if legacy_session_id field. Note that this field is echoed even if
skipping to change at page 39, line 23 skipping to change at page 39, line 23
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), /* [[this document]] */ 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]] */
pre_shared_key(41), /* [[this document]] */ pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */ early_data(42), /* [[this document]] */
supported_versions(43), /* [[this document]] */ supported_versions(43), /* [[this document]] */
cookie(44), /* [[this document]] */ cookie(44), /* [[this document]] */
psk_key_exchange_modes(45), /* [[this document]] */ psk_key_exchange_modes(45), /* [[this document]] */
certificate_authorities(47), /* [[this document]] */ certificate_authorities(47), /* [[this document]] */
oid_filters(48), /* [[this document]] */ oid_filters(48), /* [[this document]] */
post_handshake_auth(49), /* [[this document]] */ post_handshake_auth(49), /* [[this document]] */
signature_algorithms_cert(50), /* [[this document]] */
key_share(51), /* [[this document]] */
(65535) (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
skipping to change at page 41, line 49 skipping to change at page 41, line 49
| | | | | |
| cookie [[this document]] | CH, HRR | | cookie [[this document]] | CH, HRR |
| | | | | |
| supported_versions [[this document]] | CH, SH, HRR | | 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 |
| | |
| signature_algorithms_cert [[this document]] | CH, CR |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
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.11 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
skipping to change at page 42, line 43 skipping to change at page 42, line 46
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 {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
ProtocolVersion versions<2..254>; ProtocolVersion versions<2..254>;
case server_hello: case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version; ProtocolVersion selected_version;
}; };
} SupportedVersions; } SupportedVersions;
The "supported_versions" extension is used by the client to indicate The "supported_versions" extension is used by the client to indicate
which versions of TLS it supports and by the server to indicate which which versions of TLS it supports and by the server to indicate which
version it is using. The extension contains a list of supported version it is using. The extension contains a list of supported
versions in preference order, with the most preferred version first. versions in preference order, with the most preferred version first.
Implementations of this specification MUST send this extension Implementations of this specification MUST send this extension
containing all versions of TLS which they are prepared to negotiate containing all versions of TLS which they are prepared to negotiate
(for this specification, that means minimally 0x0304, but if previous (for this specification, that means minimally 0x0304, but if previous
versions of TLS are allowed to be negotiated, they MUST be present as versions of TLS are allowed to be negotiated, they MUST be present as
well). 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
skipping to change at page 43, line 47 skipping to change at page 43, line 48
preferences. If the "supported_versions" extension contains a preferences. If the "supported_versions" extension contains a
version not offered by the client, the client MUST abort the version not offered by the client, the client MUST abort the
handshake with an "illegal_parameter" alert. 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 the
ServerHello.version, and HelloRetryRequest.server_version. For ServerHello and HelloRetryRequest "supported_versions" extension.
instance, draft-17 would be encoded as the 0x7f11. This allows pre- For instance, draft-17 would be encoded as the 0x7f11. This allows
RFC implementations to safely negotiate with each other, even if they pre-RFC implementations to safely negotiate with each other, even if
would otherwise be incompatible. they would otherwise be incompatible.
4.2.2. Cookie 4.2.2. Cookie
struct { struct {
opaque cookie<1..2^16-1>; opaque cookie<1..2^16-1>;
} Cookie; } Cookie;
Cookies serve two primary purposes: Cookies serve two primary purposes:
- Allowing the server to force the client to demonstrate - Allowing the server to force the client to demonstrate
skipping to change at page 44, line 33 skipping to change at page 44, line 35
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 their initial ClientHello in subsequent connections. cookies in their initial ClientHello in subsequent connections.
When a server is operating statelessly it may receive an unprotected
record of type change_cipher_spec between the first and second
ClientHello (see Section 5). Since the server is not storing any
state this will appear as if it were the first message to be
received. Servers operating statelessly MUST ignore these records.
4.2.3. Signature Algorithms 4.2.3. Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to TLS 1.3 provides two extensions for indicating which signature
the server which signature algorithms may be used in digital algorithms may be used in digital signatures. The
signatures. Clients which desire the server to authenticate itself "signature_algorithms_cert" extension applies to signatures in
via a certificate MUST send this extension. If a server is certificates and the "signature_algorithms" extension, which
authenticating via a certificate and the client has not sent a originally appeared in TLS 1.2, applies to signatures in
"signature_algorithms" extension, then the server MUST abort the CertificateVerify messages. The keys found in certificates MUST also
handshake with a "missing_extension" alert (see Section 9.2). be of appropriate type for the signature algorithms they are used
with. This is a particular issue for RSA keys and PSS signatures, as
described below. If no "signature_algorithms_cert" extension is
present, then the "signature_algorithms" extension also applies to
signatures appearing in certificates. Clients which desire the
server to authenticate itself via a certificate MUST send
"signature_algorithms". If a server is authenticating via a
certificate and the client has not sent a "signature_algorithms"
extension, then the server MUST abort the handshake with a
"missing_extension" alert (see Section 9.2).
The "extension_data" field of this extension in a ClientHello The "signature_algorithms_cert" extension was added to allow
contains a SignatureSchemeList value: implementatations which supported different sets of algorithms for
certificates and in TLS itself to clearly signal their capabilities.
TLS 1.2 implementations SHOULD also process this extension.
The "extension_data" field of these extension contains a
SignatureSchemeList value:
enum { enum {
/* RSASSA-PKCS1-v1_5 algorithms */ /* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401), rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501), rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601), rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */ /* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403), ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503), ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603), ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms */ /* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_sha256(0x0804), rsa_pss_rsae_sha256(0x0804),
rsa_pss_sha384(0x0805), rsa_pss_rsae_sha384(0x0805),
rsa_pss_sha512(0x0806), rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */ /* EdDSA algorithms */
ed25519(0x0807), ed25519(0x0807),
ed448(0x0808), ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */ /* Legacy algorithms */
rsa_pkcs1_sha1(0x0201), rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203), ecdsa_sha1(0x0203),
/* Reserved Code Points */ /* Reserved Code Points */
private_use(0xFE00..0xFFFF), private_use(0xFE00..0xFFFF),
(0xFFFF) (0xFFFF)
} SignatureScheme; } SignatureScheme;
struct { struct {
skipping to change at page 46, line 6 skipping to change at page 47, line 11
takes as input an arbitrary-length message, rather than a digest. takes as input an arbitrary-length message, rather than a digest.
Algorithms which traditionally act on a digest should be defined in Algorithms which traditionally act on a digest should be defined in
TLS to first hash the input with a specified hash algorithm and then TLS to first hash the input with a specified hash algorithm and then
proceed as usual. The code point groups listed above have the proceed as usual. The code point groups listed above have the
following meanings: following meanings:
RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using
RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
as defined in [SHS]. These values refer solely to signatures as defined in [SHS]. These values refer solely to signatures
which appear in certificates (see Section 4.4.2.2) and are not which appear in certificates (see Section 4.4.2.2) and are not
defined for use in signed TLS handshake messages. defined for use in signed TLS handshake messages, although they
MAY appear in "signature_algorithms" and
"signature_algorithms_cert" for backward compatibility with TLS
1.2,
ECDSA algorithms Indicates a signature algorithm using ECDSA ECDSA algorithms Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure. [X690] ECDSA-Sig-Value structure.
RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- RSASSA-PSS RSAE algorithms Indicates a signature algorithm using
PSS [RFC8017] with mask generation function 1. The digest used in RSASSA-PSS [RFC8017] with mask generation function 1. The digest
the mask generation function and the digest being signed are both used in the mask generation function and the digest being signed
the corresponding hash algorithm as defined in [SHS]. When used are both the corresponding hash algorithm as defined in [SHS].
in signed TLS handshake messages, the length of the salt MUST be The length of the salt MUST be equal to the length of the digest
equal to the length of the digest output. This codepoint is new algorithm. If the public key is carried in an X.509 certificate,
in this document and is also defined for use with TLS 1.2. it MUST use the rsaEncryption OID [RFC5280].
EdDSA algorithms Indicates a signature algorithm using EdDSA as EdDSA algorithms Indicates a signature algorithm using EdDSA as
defined in [RFC8032] or its successors. Note that these defined in [RFC8032] or its successors. Note that these
correspond to the "PureEdDSA" algorithms and not the "prehash" correspond to the "PureEdDSA" algorithms and not the "prehash"
variants. variants.
RSASSA-PSS PSS algorithms Indicates a signature algorithm using
RSASSA-PSS [RFC8017] with mask generation function 1. The digest
used in the mask generation function and the digest being signed
are both the corresponding hash algorithm as defined in [SHS].
The length of the salt MUST be equal to the length of the digest
algorithm. If the public key is carried in an X.509 certificate,
it MUST use the RSASSA-PSS OID [RFC5756]. When used in
certificate signatures, the algorithm parameters MUST be DER
encoded. If the corresponding public key's parameters present,
then the parameters in the signature MUST be identical to those in
the public key.
Legacy algorithms Indicates algorithms which are being deprecated Legacy algorithms Indicates algorithms which are being deprecated
because they use algorithms with known weaknesses, specifically because they use algorithms with known weaknesses, specifically
SHA-1 which is used in this context with either with RSA using SHA-1 which is used in this context with either with RSA using
RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to
signatures which appear in certificates (see Section 4.4.2.2) and signatures which appear in certificates (see Section 4.4.2.2) and
are not defined for use in signed TLS handshake messages. are not defined for use in signed TLS handshake messages, even if
Endpoints SHOULD NOT negotiate these algorithms but are permitted they appear in the "signature_algorithms" list (this is necessary
to do so solely for backward compatibility. Clients offering for backward compatibility with TLS 1.2). Endpoints SHOULD NOT
these values MUST list them as the lowest priority (listed after negotiate these algorithms but are permitted to do so solely for
all other algorithms in SignatureSchemeList). TLS 1.3 servers backward compatibility. Clients offering these values MUST list
MUST NOT offer a SHA-1 signed certificate unless no valid them as the lowest priority (listed after all other algorithms in
certificate chain can be produced without it (see SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1
Section 4.4.2.2). signed certificate unless no valid certificate chain can be
produced without it (see Section 4.4.2.2).
The signatures on certificates that are self-signed or certificates The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a that are trust anchors are not validated since they begin a
certification path (see [RFC5280], Section 3.2). A certificate that certification path (see [RFC5280], Section 3.2). A certificate that
begins a certification path MAY use a signature algorithm that is not begins a certification path MAY use a signature algorithm that is not
advertised as being supported in the "signature_algorithms" advertised as being supported in the "signature_algorithms"
extension. extension.
Note that TLS 1.2 defines this extension differently. TLS 1.3 Note that TLS 1.2 defines this extension differently. TLS 1.3
implementations willing to negotiate TLS 1.2 MUST behave in implementations willing to negotiate TLS 1.2 MUST behave in
skipping to change at page 66, line 39 skipping to change at page 67, 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 extension ([RFC6066]) and for server certificates include OCSP Status extension ([RFC6066])
SignedCertificateTimestamps ([RFC6962]). An extension MUST only and SignedCertificateTimestamps ([RFC6962]). Extensions in the
be present in a Certificate message if the corresponding Certificate message from the server MUST correspond to one from
ClientHello extension was presented in the initial handshake. If the ClientHello message. Extensions in the Certificate from the
an extension applies to the entire chain, it SHOULD be included in client MUST correspond with an extension in the CertificateRequest
the first CertificateEntry. message from the server. If an extension applies to the entire
chain, it SHOULD be included in the first CertificateEntry.
If the corresponding certificate type extension If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not ("server_certificate_type" or "client_certificate_type") was not
negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated in Encrypted Extensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains an X.509 certificate. negotiated, then each CertificateEntry contains a DER-encoded X.509
The sender's certificate MUST come in the first CertificateEntry in certificate. The sender's certificate MUST come in the first
the list. Each following certificate SHOULD directly certify one CertificateEntry in the list. Each following certificate SHOULD
preceding it. Because certificate validation requires that trust directly certify one preceding it. Because certificate validation
anchors be distributed independently, a certificate that specifies a requires that trust anchors be distributed independently, a
trust anchor MAY be omitted from the chain, provided that supported certificate that specifies a trust anchor MAY be omitted from the
peers are known to possess any omitted certificates. chain, provided that supported 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 74, line 35 skipping to change at page 75, line 45
(Section 4.2.11). Servers MAY send multiple tickets on a single (Section 4.2.11). Servers MAY send multiple tickets on a single
connection, either immediately after each other or after specific connection, either immediately after each other or after specific
events (see Appendix C.4). For instance, the server might send a new events (see Appendix C.4). For instance, the server might send a new
ticket after post-handshake authentication in order to encapsulate ticket after post-handshake authentication in order to encapsulate
the additional client authentication state. Multiple tickets are the additional client authentication state. Multiple tickets are
useful for clients for a variety of purposes, including: useful for clients for a variety of purposes, including:
- Opening multiple parallel HTTP connections. - Opening multiple parallel HTTP connections.
- Performing connection racing across interfaces and address - Performing connection racing across interfaces and address
families via, e.g., Happy Eyeballs [RFC6555] or related families via, e.g., Happy Eyeballs [RFC8305] or related
techniques. 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.
Clients MUST only resume if the new SNI value is valid for the server Clients MUST only resume if the new SNI value is valid for the server
certificate presented in the original session, and SHOULD only resume certificate presented in the original session, and SHOULD only resume
if the SNI value matches the one used in the original session. The if the SNI value matches the one used in the original session. The
latter is a performance optimization: normally, there is no reason to latter is a performance optimization: normally, there is no reason to
expect that different servers covered by a single certificate would expect that different servers covered by a single certificate would
skipping to change at page 78, line 29 skipping to change at page 79, line 42
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 four content types: handshake, application data, alert, and specifies four content types: handshake, application data, alert, and
change_cipher_spec, with the latter being used only for compatibility change_cipher_spec. The change_cipher_spec record is used only for
purposes (see Appendix D.4). compatibility purposes (see Appendix D.4).
An implementation may receive an unencrypted record of type An implementation may receive an unencrypted record of type
change_cipher_spec consisting of the single byte value 0x01 at any change_cipher_spec consisting of the single byte value 0x01 at any
time during the handshake and MUST simply drop it without further time after the first ClientHello message has been sent or received
processing. Note that this record may appear at a point at the and before the peer's Finished message has been received and MUST
handshake where the implementation is expecting protected records and simply drop it without further processing. Note that this record may
so it is necessary to detect this condition prior to attempting to appear at a point at the handshake where the implementation is
deprotect the record. An implementation which receives any other expecting protected records and so it is necessary to detect this
change_cipher_spec value or which receives a protected condition prior to attempting to deprotect the record. An
change_cipher_spec record MUST abort the handshake with an implementation which receives any other change_cipher_spec value or
"unexpected_message" alert. After the handshake is complete, which receives a protected change_cipher_spec record MUST abort the
change_cipher_spec MUST be treated as an unexpected record type. handshake with an "unexpected_message" alert. A change_cipher_spec
record received before the first ClientHello message or after the
peer's Finished message MUST be treated as an unexpected record type.
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST terminate implementation receives an unexpected record type, it MUST terminate
the connection with an "unexpected_message" alert. New record the connection with an "unexpected_message" alert. New record
content type values are assigned by IANA in the TLS Content Type content type values are assigned by IANA in the TLS Content Type
Registry as described in Section 11. Registry as described in Section 11.
5.1. Record Layer 5.1. Record Layer
skipping to change at page 101, line 16 skipping to change at page 102, line 30
9.1. Mandatory-to-Implement Cipher Suites 9.1. Mandatory-to-Implement Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the otherwise, a TLS-compliant application MUST implement the
TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
[RFC7539] cipher suites. (see Appendix B.4) [RFC7539] cipher suites. (see Appendix B.4)
A TLS-compliant application MUST support digital signatures with A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1 TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
9.2. Mandatory-to-Implement Extensions 9.2. Mandatory-to-Implement Extensions
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
skipping to change at page 102, line 30 skipping to change at page 103, line 44
requirements MUST abort the handshake with a "missing_extension" requirements MUST abort the handshake with a "missing_extension"
alert. alert.
Additionally, all implementations MUST support use of the Additionally, all implementations MUST support use of the
"server_name" extension with applications capable of using it. "server_name" extension with applications capable of using it.
Servers MAY require clients to send a valid "server_name" extension. Servers MAY require clients to send a valid "server_name" extension.
Servers requiring this extension SHOULD respond to a ClientHello Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension by terminating the connection with lacking a "server_name" extension by terminating the connection with
a "missing_extension" alert. a "missing_extension" alert.
9.3. Protocol Invariants
This section describes invariants that TLS endpoints and middleboxes
MUST follow. It also applies to earlier versions, which assumed
these rules but did not document them.
TLS is designed to be securely and compatibly extensible. Newer
clients or servers, when communicating with newer peers, SHOULD
negotiate the most preferred common parameters. The TLS handshake
provides downgrade protection: Middleboxes passing traffic between a
newer client and newer server without terminating TLS should be
unable to influence the handshake (see Appendix E.1). At the same
time, deployments update at different rates, so a newer client or
server MAY continue to support older parameters, which would allow it
to interoperate with older endpoints.
For this to work, implementations MUST correctly handle extensible
fields:
- A client sending a ClientHello MUST support all parameters
advertised in it. Otherwise, the server may fail to interoperate
by selecting one of those parameters.
- A server receiving a ClientHello MUST correctly ignore all
unrecognized cipher suites, extensions, and other parameters.
Otherwise, it may fail to interoperate with newer clients. In TLS
1.3, a client receiving a CertificateRequest or NewSessionTicket
MUST also ignore all unrecognized extensions.
- A middlebox which terminates a TLS connection MUST behave as a
compliant TLS server (to the original client), including having a
certificate which the client is willing to accept, and as a
compliant TLS client (to the original server), including verifying
the original server's certificate. In particular, it MUST
generate its own ClientHello containing only parameters it
understands, and it MUST generate a fresh ServerHello random
value, rather than forwarding the endpoint's value.
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately. Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.
- An middlebox which forwards ClientHello parameters it does not
understand MUST NOT process any messages beyond that ClientHello.
It MUST forward all subsequent traffic unmodified. Otherwise, it
may fail to interoperate with newer clients and servers.
Forwarded ClientHellos may contain advertisements for features not
supported by the middlebox, so the response may include future TLS
additions the middlebox does not recognize. These additions MAY
change any message beyond the ClientHello arbitrarily. In
particular, the values sent in the ServerHello might change, the
ServerHello format might change, and the TLSCiphertext format
might change.
The design of TLS 1.3 was constrained by widely-deployed non-
compliant TLS middleboxes (see Appendix D.4), however it does not
relax the invariants. Those middleboxes continue to be non-
compliant.
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendix C, Appendix D, and Appendix E. Appendix C, Appendix D, and Appendix E.
11. IANA Considerations 11. IANA Considerations
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA has updated these to reference this document. The [RFC4346]. IANA has updated these to reference this document. The
registries and their allocation policies are below: registries and their allocation policies are below:
- TLS Cipher Suite Registry: values with the first byte in the range - TLS Cipher Suite Registry: values with the first byte in the range
0-254 (decimal) are assigned via Specification Required [RFC5226]. 0-254 (decimal) are assigned via Specification Required [RFC8126].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
Use [RFC5226]. Use [RFC8126].
IANA [SHALL add/has added] the cipher suites listed in IANA [SHALL add/has added] the cipher suites listed in
Appendix B.4 to the registry. The "Value" and "Description" Appendix B.4 to the registry. The "Value" and "Description"
columns are taken from the table. The "DTLS-OK" and "Recommended" columns are taken from the table. The "DTLS-OK" and "Recommended"
columns are both marked as "Yes" for each new cipher suite. columns are both marked as "Yes" for each new cipher suite.
[[This assumes [I-D.ietf-tls-iana-registry-updates] has been [[This assumes [I-D.ietf-tls-iana-registry-updates] has been
applied.]] applied.]]
- TLS ContentType Registry: Future values are allocated via - TLS ContentType Registry: Future values are allocated via
Standards Action [RFC5226]. Standards Action [RFC8126].
- 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 [RFC8126]. 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 [RFC8126]. 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 "new_session_ticket" and to add the
"hello_retry_request_RESERVED", "encrypted_extensions", "hello_retry_request_RESERVED", "encrypted_extensions",
"end_of_early_data", "key_update", and "message_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", "post_handshake_auth",
"post_handshake_auth" extensions with the values defined in this and "signature_algorithms_certs", extensions with the values
document and the Recommended value of "Yes". defined in this document and the Recommended value of "Yes".
- IANA [SHALL update/has updated] this registry to include a "TLS - IANA [SHALL update/has updated] this registry to include a "TLS
1.3" column which lists the messages in which the extension may 1.3" column which lists the messages in which the extension may
appear. This column [SHALL be/has been] initially populated from appear. This column [SHALL be/has been] initially populated from
the table in Section 4.2 with any extension not listed there the table in Section 4.2 with any extension not listed there
marked as "-" to indicate that it is not used by TLS 1.3. marked as "-" to indicate that it is not used by TLS 1.3.
In addition, this document defines a new registry to be maintained by In addition, this document defines 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-253 (decimal) are assigned via Specification Required range 0-253 (decimal) are assigned via Specification Required
[RFC5226]. Values with the first byte 254 or 255 (decimal) are [RFC8126]. Values with the first byte 254 or 255 (decimal) are
reserved for Private Use [RFC5226]. Values with the first byte in reserved for Private Use [RFC8126]. Values with the first byte in
the range 0-6 or with the second byte in the range 0-3 that are the range 0-6 or with the second byte in the range 0-3 that are
not currently allocated are reserved for backwards compatibility. not currently allocated are reserved for backwards compatibility.
This registry SHALL have a "Recommended" column. The registry This registry SHALL have a "Recommended" column. The registry
[shall be/ has been] initially populated with the values described [shall be/ has been] initially populated with the values described
in Section 4.2.3. The following values SHALL be marked as in Section 4.2.3. The following values SHALL be marked as
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.
12. References 12. References
skipping to change at page 104, line 19 skipping to change at page 106, line 47
[DH] Diffie, W. and M. Hellman, "New Directions in [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977. V.IT-22 n.6 , June 1977.
[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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<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,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/info/rfc5756>.
[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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5869>. 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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6066>. 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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6655>. 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,
<https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6961>. 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,
<https://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, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
skipping to change at page 106, line 12 skipping to change at page 108, line 44
RFC 7919, DOI 10.17487/RFC7919, August 2016, RFC 7919, DOI 10.17487/RFC7919, August 2016,
<https://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,
<https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8032>. editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHS] Dang, Q., "Secure Hash Standard", National Institute of [SHS] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015. 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.
skipping to change at page 107, line 14 skipping to change at page 109, line 49
[BDFKPPRSZZ16] [BDFKPPRSZZ16]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy,
N., Zanella-Beguelin, S., and J. Zinzindohoue, N., Zanella-Beguelin, S., and J. Zinzindohoue,
"Implementing and Proving the TLS 1.3 Record Layer", "Implementing and Proving the TLS 1.3 Record Layer",
Proceedings of IEEE Symposium on Security and Privacy Proceedings of IEEE Symposium on Security and Privacy
(Oakland) 2017 , December 2016, (Oakland) 2017 , December 2016,
<https://eprint.iacr.org/2016/1178>. <https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF
100", 2017,
<https://datatracker.ietf.org/meeting/100/materials/
slides-100-tls-sessa-tls13/>.
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome",
2017, <https://www.ietf.org/mail-archive/web/tls/current/
msg25168.html>.
[BMMT15] Badertscher, C., Matt, C., Maurer, U., and B. Tackmann, [BMMT15] Badertscher, C., Matt, C., Maurer, U., and B. Tackmann,
"Augmented Secure Channels and the Goal of the TLS 1.3 "Augmented Secure Channels and the Goal of the TLS 1.3
Record Layer", ProvSec 2015 , September 2015, Record Layer", ProvSec 2015 , September 2015,
<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-
skipping to change at page 109, line 12 skipping to change at page 112, line 7
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, "IANA Registry Updates for TLS Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", draft-ietf-tls-iana-registry-updates-02 (work and DTLS", draft-ietf-tls-iana-registry-updates-03 (work
in progress), October 2017. in progress), January 2018.
[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-02 (work in progress), July draft-ietf-tls-tls13-vectors-03 (work in progress),
2017. December 2017.
[IEEE1363] [IEEE1363]
IEEE, "Standard Specifications for Public Key IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363 , 2000. Cryptography", IEEE 1363 , 2000.
[JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of ACM CCS 2015 , 2015,
<https://www.nds.rub.de/media/nds/
veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf>.
[KEYAGREEMENT] [KEYAGREEMENT]
Barker, E., Chen, L., 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", National Institute Using Discrete Logarithm Cryptography", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.sp.800-56ar2, May 2013. 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>.
skipping to change at page 110, line 15 skipping to change at page 113, line 15
[PSK-FINISHED] [PSK-FINISHED]
Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
"Revision 10: possible attack if client authentication is "Revision 10: possible attack if client authentication is
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.
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3
Middlebox experiment", 2017, <https://www.ietf.org/mail-
archive/web/tls/current/msg25091.html>.
[Res17b] Rescorla, E., "More compatibility measurement results",
2017, <https://www.ietf.org/mail-archive/web/tls/current/
msg25179.html>.
[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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3552>. 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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4086>. 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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4346>. 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,
<https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4492>. 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, <https://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, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [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,
<https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5764>. 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,
<https://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,
<https://www.rfc-editor.org/info/rfc6091>. <https://www.rfc-editor.org/info/rfc6091>.
skipping to change at page 111, line 36 skipping to change at page 114, line 45
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://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, <https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6520>. 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,
<https://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, <https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7465>. 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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7568>. 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,
<https://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, <https://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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7924>. editor.org/info/rfc7924>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, <https://www.rfc-
editor.org/info/rfc8305>.
[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 113, line 9 skipping to change at page 117, line 5
[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 119, line 39 skipping to change at page 122, line 39
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), /* [[this document]] */ 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]] */ RESERVED(40), /* Used but never assigned */
pre_shared_key(41), /* [[this document]] */ pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */ early_data(42), /* [[this document]] */
supported_versions(43), /* [[this document]] */ supported_versions(43), /* [[this document]] */
cookie(44), /* [[this document]] */ cookie(44), /* [[this document]] */
psk_key_exchange_modes(45), /* [[this document]] */ psk_key_exchange_modes(45), /* [[this document]] */
certificate_authorities(47), /* [[this document]] */ certificate_authorities(47), /* [[this document]] */
oid_filters(48), /* [[this document]] */ oid_filters(48), /* [[this document]] */
post_handshake_auth(49), /* [[this document]] */ post_handshake_auth(49), /* [[this document]] */
signature_algorithms_cert(50), /* [[this document]] */
key_share(51), /* [[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 {
KeyShareEntry client_shares<0..2^16-1>; KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello; } KeyShareClientHello;
struct { struct {
skipping to change at page 121, line 21 skipping to change at page 124, line 21
}; };
} PreSharedKeyExtension; } PreSharedKeyExtension;
B.3.1.1. Version Extension B.3.1.1. Version Extension
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
ProtocolVersion versions<2..254>; ProtocolVersion versions<2..254>;
case server_hello: case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version; 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;
skipping to change at page 122, line 15 skipping to change at page 125, line 15
/* RSASSA-PKCS1-v1_5 algorithms */ /* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401), rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501), rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601), rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */ /* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403), ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503), ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603), ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms */ /* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_sha256(0x0804), rsa_pss_rsae_sha256(0x0804),
rsa_pss_sha384(0x0805), rsa_pss_rsae_sha384(0x0805),
rsa_pss_sha512(0x0806), rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */ /* EdDSA algorithms */
ed25519(0x0807), ed25519(0x0807),
ed448(0x0808), ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */ /* Legacy algorithms */
rsa_pkcs1_sha1(0x0201), rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203), ecdsa_sha1(0x0203),
/* Reserved Code Points */ /* Reserved Code Points */
obsolete_RESERVED(0x0000..0x0200), obsolete_RESERVED(0x0000..0x0200),
dsa_sha1_RESERVED(0x0202), dsa_sha1_RESERVED(0x0202),
obsolete_RESERVED(0x0204..0x0400), obsolete_RESERVED(0x0204..0x0400),
dsa_sha256_RESERVED(0x0402), dsa_sha256_RESERVED(0x0402),
obsolete_RESERVED(0x0404..0x0500), obsolete_RESERVED(0x0404..0x0500),
skipping to change at page 130, line 37 skipping to change at page 133, line 37
application profile. application profile.
Appendix D. Backward Compatibility Appendix D. Backward Compatibility
The TLS protocol provides a built-in mechanism for version The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different negotiation between endpoints potentially supporting different
versions of TLS. versions of TLS.
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and the client supports the the ClientHello format remains compatible and and there is at least
highest protocol version available in the server. one protocol version supported by both the client and the server.
Prior versions of TLS used the record layer version number for Prior versions of TLS used the record layer version number for
various purposes. (TLSPlaintext.legacy_record_version and various purposes. (TLSPlaintext.legacy_record_version and
TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is
deprecated. The value of TLSPlaintext.legacy_record_version MUST be deprecated. The value of TLSPlaintext.legacy_record_version MUST be
ignored by all implementations. The value of ignored by all implementations. The value of
TLSCiphertext.legacy_record_version MAY be ignored, or MAY be TLSCiphertext.legacy_record_version MAY be ignored, or MAY be
validated to match the fixed constant value. Version negotiation is validated to match the fixed constant value. Version negotiation is
performed using only the handshake versions performed using only the handshake versions
(ClientHello.legacy_version, ClientHello "supported_versions" (ClientHello.legacy_version, ServerHello.legacy_version, as well as
extension, and ServerHello.version). In order to maximize the ClientHello, HelloRetryRequest and ServerHello
"supported_versions" extensions). In order to maximize
interoperability with older endpoints, implementations that negotiate interoperability with older endpoints, implementations that negotiate
the use of TLS 1.0-1.2 SHOULD set the record layer version number to the use of TLS 1.0-1.2 SHOULD set the record layer version number to
the negotiated version for the ServerHello and all records the negotiated version for the ServerHello and all records
thereafter. thereafter.
For maximum compatibility with previously non-standard behavior and For maximum compatibility with previously non-standard behavior and
misconfigured deployments, all implementations SHOULD support misconfigured deployments, all implementations SHOULD support
validation of certification paths based on the expectations in this validation of certification paths based on the expectations in this
document, even when handling prior TLS versions' handshakes. (see document, even when handling prior TLS versions' handshakes. (see
Section 4.4.2.2) Section 4.4.2.2)
skipping to change at page 132, line 47 skipping to change at page 135, line 47
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. Middlebox Compatibility Mode D.4. Middlebox Compatibility Mode
Field measurements have found that a significant number of Field measurements [Ben17a], [Ben17b], [Res17a], [Res17b] have found
middleboxes misbehave when a TLS client/server pair negotiates TLS that a significant number of middleboxes misbehave when a TLS client/
1.3. Implementations can increase the chance of making connections server pair negotiates TLS 1.3. Implementations can increase the
through those middleboxes by making the TLS 1.3 handshake look more chance of making connections through those middleboxes by making the
like a TLS 1.2 handshake: TLS 1.3 handshake look more like a TLS 1.2 handshake:
- The client always provides a non-empty session ID in the - The client always provides a non-empty session ID in the
ClientHello. ClientHello, as described in the legacy_session_id section of
Section 4.1.2.
- If not offering early data, the client sends a dummy - If not offering early data, the client sends a dummy
change_cipher_spec record immediately before its second flight. change_cipher_spec record change_cipher_spec record (see the third
paragraph of Section 5.1) immediately before its second flight.
This may either be before its second ClientHello or before its This may either be before its second ClientHello or before its
encrypted handshake flight. If offering early data, the record is encrypted handshake flight. If offering early data, the record is
placed immediately after the first ClientHello. placed immediately after the first ClientHello.
- The server sends a dummy change_cipher_spec record immediately - The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a after its first handshake message. This may either be after a
ServerHello or a HelloRetryRequest. ServerHello or a HelloRetryRequest.
When put together, these changes make the TLS 1.3 handshake resemble When put together, these changes make the TLS 1.3 handshake resemble
TLS 1.2 session resumption, which improves the chance of successfully TLS 1.2 session resumption, which improves the chance of successfully
connecting through middleboxes. This "compatibility mode" is not connecting through middleboxes. This "compatibility mode" is
explicitly negotiated. The client can opt to provide a session ID or partially negotiated: The client can opt to provide a session ID or
not and the server has to echo it. Either side can send 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 change_cipher_spec at any time during the handshake, as they must be
ignored by the peer. ignored by the peer, but if the client sends a non-empty session ID,
the server MUST send the change_cipher_spec as described in this
section.
D.5. Backwards Compatibility Security Restrictions 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.
skipping to change at page 134, line 6 skipping to change at page 137, line 9
reasons enumerated in [RFC6176], and MUST NOT be negotiated for any reasons enumerated in [RFC6176], and MUST NOT be negotiated for any
reason. reason.
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS. order to negotiate older versions of TLS.
Implementations MUST NOT send a ClientHello.legacy_version or Implementations MUST NOT send a ClientHello.legacy_version or
ServerHello.version set to 0x0300 or less. Any endpoint receiving a ServerHello.legacy_version set to 0x0300 or less. Any endpoint
Hello message with ClientHello.legacy_version or ServerHello.version receiving a Hello message with ClientHello.legacy_version or
set to 0x0300 MUST abort the handshake with a "protocol_version" ServerHello.legacy_version set to 0x0300 MUST abort the handshake
alert. with a "protocol_version" alert.
Implementations MUST NOT send any records with a version less than Implementations MUST NOT send any records with a version less than
0x0300. Implementations SHOULD NOT accept any records with a version 0x0300. Implementations SHOULD NOT accept any records with a version
less than 0x0300 (but may inadvertently do so if the record version less than 0x0300 (but may inadvertently do so if the record version
number is ignored completely). number is ignored completely).
Implementations MUST NOT use the Truncated HMAC extension, defined in Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066], as it is not applicable to AEAD algorithms Section 7 of [RFC6066], as it is not applicable to AEAD algorithms
and has been shown to be insecure in some scenarios. and has been shown to be insecure in some scenarios.
skipping to change at page 137, line 5 skipping to change at page 140, line 7
(e.g., PSK). If this restriction were to be relaxed in future, the (e.g., PSK). If this restriction were to be relaxed in future, the
client's signature would not cover the server's certificate directly. client's signature would not cover the server's certificate directly.
However, if the PSK was established through a NewSessionTicket, the However, if the PSK was established through a NewSessionTicket, the
client's signature would transitively cover the server's certificate client's signature would transitively cover the server's certificate
through the PSK binder. [PSK-FINISHED] describes a concrete attack through the PSK binder. [PSK-FINISHED] describes a concrete attack
on constructions that do not bind to the server's certificate (see on constructions that do not bind to the server's certificate (see
also [Kraw16]). It is unsafe to use certificate-based client also [Kraw16]). It is unsafe to use certificate-based client
authentication when the client might potentially share the same PSK/ authentication when the client might potentially share the same PSK/
key-id pair with two different endpoints. Implementations MUST NOT key-id pair with two different endpoints. Implementations MUST NOT
combine external PSKs with certificate-based authentication of either combine external PSKs with certificate-based authentication of either
the client or the server. the client or the server unless negotiated by some extension.
If an exporter is used, then it produces values which are unique and If an exporter is used, then it produces values which are unique and
secret (because they are generated from a unique session key). secret (because they are generated from a unique session key).
Exporters computed with different labels and contexts are Exporters computed with different labels and contexts are
computationally independent, so it is not feasible to compute one computationally independent, so it is not feasible to compute one
from another or the session secret from the exported value. Note: from another or the session secret from the exported value. Note:
exporters can produce arbitrary-length values. If exporters are to exporters can produce arbitrary-length values. If exporters are to
be used as channel bindings, the exported value MUST be large enough be used as channel bindings, the exported value MUST be large enough
to provide collision resistance. The exporters provided in TLS 1.3 to provide collision resistance. The exporters provided in TLS 1.3
are derived from the same handshake contexts as the early traffic are derived from the same handshake contexts as the early traffic
skipping to change at page 143, line 45 skipping to change at page 147, line 5
In particular, if these exporters are used as an authentication In particular, if these exporters are used as an authentication
channel binding (e.g., by signing the output of the exporter) an channel binding (e.g., by signing the output of the exporter) an
attacker who compromises the PSK can transplant authenticators attacker who compromises the PSK can transplant authenticators
between connections without compromising the authentication key. between connections without compromising the authentication key.
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.
E.6. Attacks on Static RSA
Although TLS 1.3 does not use RSA key transport and so is not
directly susceptible to Bleichenbacher-type attacks, if TLS 1.3
servers also support static RSA in the context of previous versions
of TLS, then it may be possible to impersonate the server for TLS 1.3
connections [JSS15]. TLS 1.3 implementations can prevent this attack
by disabling support for static RSA across all versions of TLS. In
principle, implementations might also be able to separate
certificates with different keyUsage bits for static RSA decryption
and RSA signature, but this technique relies on clients refusing to
accept signatures using keys in certificates that do not have the
digitalSignature bit set, and many clients do not enforce this
restriction.
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 [2] https://www.ietf.org/mailman/listinfo/tls
Archives of the list can be found at: https://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/tls/current/index.html [3] archive/web/tls/current/index.html
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
skipping to change at page 150, line 31 skipping to change at page 154, line 5
- 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
- Christopher A. Wood
Apple Inc.
cawood@apple.com
- Tim Wright - Tim Wright
Vodafone Vodafone
timothy.wright@vodafone.com timothy.wright@vodafone.com
- Peter Wu - Peter Wu
Independent Independent
peter@lekensteyn.nl peter@lekensteyn.nl
- Kazu Yamamoto - Kazu Yamamoto
Internet Initiative Japan Inc. Internet Initiative Japan Inc.
 End of changes. 89 change blocks. 
270 lines changed or deleted 459 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/