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