draft-ietf-tls-tls13-23.txt   draft-ietf-tls-tls13-24.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246 (if approved) January 05, 2018 Obsoletes: 5077, 5246 (if approved) February 15, 2018
Updates: 4492, 5705, 6066, 6961 (if Updates: 4492, 5705, 6066, 6961 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 9, 2018 Expires: August 19, 2018
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-23 draft-ietf-tls-tls13-24
Abstract Abstract
This document specifies version 1.3 of the Transport Layer Security This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping, over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. tampering, and message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2018. This Internet-Draft will expire on August 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . 15
1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 16 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 17
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21
2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28
3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44
4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 48 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 48
4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49
4.2.6. Post-Handshake Client Authentication . . . . . . . . 50 4.2.6. Post-Handshake Client Authentication . . . . . . . . 50
4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 50 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 50
4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52
4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55
4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56
4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 58 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 58
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 63 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 64
4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65
4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66
4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71
4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73
4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 75 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 75
4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75
4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75
4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 78 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 78
4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82
5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84
5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85
5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86
6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86
6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88
6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 91 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 92
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92
7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 95 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 95
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 95 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 96
7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 96 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 96
7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 96 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 97
7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 96 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 97
7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 97 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 98
8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98
8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 99 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 100
8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 99 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 100
8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 102 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 103
9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 102 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 103
9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 102 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 103
9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 103 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 104
10. Security Considerations . . . . . . . . . . . . . . . . . . . 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 106
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.1. Normative References . . . . . . . . . . . . . . . . . . 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 107
12.2. Informative References . . . . . . . . . . . . . . . . . 109 12.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 117 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 118
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix B. Protocol Data Structures and Constant Values . . . . 118 Appendix B. Protocol Data Structures and Constant Values . . . . 119
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 119 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 119 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 121 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 121 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 126 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 127 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128
B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 128 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129
B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 128 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 129
B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 129 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 130 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131
C.1. Random Number Generation and Seeding . . . . . . . . . . 130 C.1. Random Number Generation and Seeding . . . . . . . . . . 131
C.2. Certificates and Authentication . . . . . . . . . . . . . 131 C.2. Certificates and Authentication . . . . . . . . . . . . . 132
C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 131 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132
C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 132 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 133
C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 133 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 134
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 133 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 134
D.1. Negotiating with an older server . . . . . . . . . . . . 134 D.1. Negotiating with an older server . . . . . . . . . . . . 135
D.2. Negotiating with an older client . . . . . . . . . . . . 135 D.2. Negotiating with an older client . . . . . . . . . . . . 136
D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 135 D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 136
D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 135 D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 136
D.5. Backwards Compatibility Security Restrictions . . . . . . 136 D.5. Backwards Compatibility Security Restrictions . . . . . . 137
Appendix E. Overview of Security Properties . . . . . . . . . . 137 Appendix E. Overview of Security Properties . . . . . . . . . . 138
E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 137 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 138
E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 140 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 141
E.1.2. Client Authentication . . . . . . . . . . . . . . . . 141 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 142
E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 141 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 142
E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 141 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 142
E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 142 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 143
E.1.6. External References . . . . . . . . . . . . . . . . . 142 E.1.6. External References . . . . . . . . . . . . . . . . . 143
E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 142 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 143
E.2.1. External References . . . . . . . . . . . . . . . . . 143 E.2.1. External References . . . . . . . . . . . . . . . . . 144
E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 143 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 144
E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 144 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 145
E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 145 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 146
E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 146 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 147
E.6. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 147 E.6. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 148
Appendix F. Working Group Information . . . . . . . . . . . . . 147 Appendix F. Working Group Information . . . . . . . . . . . . . 148
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 147 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 148
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 154 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 155
1. Introduction 1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/tlswg/tls13-spec. as pull requests at https://github.com/tlswg/tls13-spec.
Instructions are on that page as well. Editorial changes can be Instructions are on that page as well. Editorial changes can be
managed in GitHub, but any substantive change should be discussed on managed in GitHub, but any substantive change should be discussed on
the TLS mailing list. the TLS mailing list.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Change Log 1.2. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
(*) indicates changes to the wire protocol which may require (*) indicates changes to the wire protocol which may require
implementations to update. implementations to update.
draft-24
- Require that CH2 have version 0303 (*)
- 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 amke 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 (*)
skipping to change at page 36, line 25 skipping to change at page 36, line 25
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. Currently the only such extensions are "key_share" and context and negotiate the protocol version. All TLS 1.3
"pre_shared_key". All current TLS 1.3 ServerHello messages will ServerHello messages MUST contain the "supported_versions"
contain one of these two extensions, or both when using a PSK with extension. Current ServerHello messages contain either the
(EC)DHE key establishment. The remaining extensions are sent "pre_shared_key" or "key_share" extensions, or both when using a
separately in the EncryptedExtensions message. PSK with (EC)DHE key establishment. The remaining extensions are
sent separately in the EncryptedExtensions message.
For backward compatibility reasons with middleboxes (see For backward compatibility reasons 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
skipping to change at page 38, line 46 skipping to change at page 38, line 46
ClientHello. A client which receives a cipher suite that was not ClientHello. A client which receives a cipher suite that was not
offered MUST abort the handshake. Servers MUST ensure that they offered MUST abort the handshake. Servers MUST ensure that they
negotiate the same cipher suite when receiving a conformant updated negotiate the same cipher suite when receiving a conformant updated
ClientHello (if the server selects the cipher suite as the first step ClientHello (if the server selects the cipher suite as the first step
in the negotiation, then this will happen automatically). Upon in the negotiation, then this will happen automatically). Upon
receiving the ServerHello, clients MUST check that the cipher suite receiving the ServerHello, clients MUST check that the cipher suite
supplied in the ServerHello is the same as that in the supplied in the ServerHello is the same as that in the
HelloRetryRequest and otherwise abort the handshake with an HelloRetryRequest and otherwise abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
The value of selected_version in the HelloRetryRequest
"supported_versions" extension MUST be retained in the ServerHello,
and a client MUST abort the handshake with an "illegal_parameter"
alert if the value changes.
4.2. Extensions 4.2. Extensions
A number of TLS messages contain tag-length-value encoded extensions A number of TLS messages contain tag-length-value encoded extensions
structures. structures.
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
skipping to change at page 45, line 13 skipping to change at page 45, line 13
described below. If no "signature_algorithms_cert" extension is described below. If no "signature_algorithms_cert" extension is
present, then the "signature_algorithms" extension also applies to present, then the "signature_algorithms" extension also applies to
signatures appearing in certificates. Clients which desire the signatures appearing in certificates. Clients which desire the
server to authenticate itself via a certificate MUST send server to authenticate itself via a certificate MUST send
"signature_algorithms". If a server is authenticating via a "signature_algorithms". If a server is authenticating via a
certificate and the client has not sent a "signature_algorithms" certificate and the client has not sent a "signature_algorithms"
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
implementatations 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
"signature_algorithms_cert" extension.
The "extension_data" field of these extension contains a The "extension_data" field of these extension 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),
skipping to change at page 63, line 39 skipping to change at page 63, line 39
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" extension. The latter is expressed by the "signature_algorithms" and "signature_algorithms_cert"
sending the "certificate_authorities" extension (see Section 4.2.4). extensions. The latter is expressed by sending the
"certificate_authorities" extension (see Section 4.2.4).
Servers which are authenticating with a PSK MUST NOT send the Servers which are authenticating with a PSK MUST NOT send the
CertificateRequest message in the main handshake, though they MAY CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see Section 4.6.2) provided send it in post-handshake authentication (see Section 4.6.2) provided
that the client has sent the "post_handshake_auth" extension (see that the client has sent the "post_handshake_auth" extension (see
Section 4.2.6). Section 4.2.6).
4.4. Authentication Messages 4.4. Authentication Messages
As discussed in Section 2, TLS generally uses a common set of As discussed in Section 2, TLS generally uses a common set of
skipping to change at page 69, line 32 skipping to change at page 69, line 32
- 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 (currently RSA, ECDSA, or EdDSA).
- The certificate MUST allow the key to be used for signing (i.e., - The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme indicated in the client's present) with a signature scheme indicated in the client's
"signature_algorithms" extension. "signature_algorithms"/"signature_algorithms_cert" extensions (see
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 that appears in the "signature_algorithms" extension algorithm advertised by the client, if they are able to provide such
provided by the client, if they are able to provide such a chain (see a chain (see Section 4.2.3). Certificates that are self-signed or
Section 4.2.3). Certificates that are self-signed or certificates certificates that are expected to be trust anchors are not validated
that are expected to be trust anchors are not validated as part of as part of the chain and therefore MAY be signed with any algorithm.
the chain and therefore MAY be signed with any algorithm.
If the server cannot produce a certificate chain that is signed only If the server cannot produce a certificate chain that is signed only
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 "signature_algorithms" algorithm in general, but MAY do so if the client's advertisement
extension provided by the client permits it, and MUST NOT do so permits it, and MUST NOT do so otherwise.
otherwise.
If the client cannot construct an acceptable chain using the provided If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort certificates and decides to abort the handshake, then it MUST abort
the handshake with an appropriate certificate-related alert (by the handshake with an appropriate certificate-related alert (by
default, "unsupported_certificate"; see Section 6.2 for more). default, "unsupported_certificate"; see Section 6.2 for more).
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences). as transport layer endpoint, local configuration and preferences).
skipping to change at page 81, line 29 skipping to change at page 81, line 29
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type The higher-level protocol used to process the enclosed type The higher-level protocol used to process the enclosed
fragment. fragment.
legacy_record_version This value MUST be set to 0x0303 for all legacy_record_version This value MUST be set to 0x0303 for all
records generated by a TLS 1.3 implementation other than the records generated by a TLS 1.3 implementation other than an
ClientHello, where it MAY also be 0x0301 for compatibility initial ClientHello (i.e., one not generated after a
HelloRetryRequest), where it MAY also be 0x0301 for compatibility
purposes. This field is deprecated and MUST be ignored for all purposes. This field is deprecated and MUST be ignored for all
purposes. Previous versions of TLS would use other values in this purposes. Previous versions of TLS would use other values in this
field under some circumstances. field under some circumstances.
length The length (in bytes) of the following TLSPlaintext.fragment. length The length (in bytes) of the following TLSPlaintext.fragment.
The length MUST NOT exceed 2^14 bytes. An endpoint that receives The length MUST NOT exceed 2^14 bytes. An endpoint that receives
a record that exceeds this length MUST terminate the connection a record that exceeds this length MUST terminate the connection
with a "record_overflow" alert. with a "record_overflow" alert.
fragment The data being transmitted. This value is transparent and fragment The data being transmitted. This value is transparent and
is treated as an independent block to be dealt with by the higher- is treated as an independent block to be dealt with by the higher-
level protocol specified by the type field. level protocol specified by the type field.
This document describes TLS 1.3, which uses the version 0x0304. This This document describes TLS 1.3, which uses the version 0x0304. This
version value is historical, deriving from the use of 0x0301 for TLS version value is historical, deriving from the use of 0x0301 for TLS
1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards
compatibility, records containing the ClientHello MUST have version compatibility, records containing an initial ClientHello MUST have
0x0301 and records containing the ServerHello MUST have version version 0x0301 and a record containing a second ClientHello or a
0x0303, reflecting TLS 1.0 and TLS 1.2 respectively. When ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
negotiating prior versions of TLS, endpoints follow the procedure and respectively. When negotiating prior versions of TLS, endpoints
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.
5.2. Record Payload Protection 5.2. Record Payload Protection
The record protection functions translate a TLSPlaintext structure The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext. The deprotection functions reverse the into a TLSCiphertext. The deprotection functions reverse the
skipping to change at page 102, line 30 skipping to change at page 103, line 16
9.1. Mandatory-to-Implement Cipher Suites 9.1. Mandatory-to-Implement Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the otherwise, a TLS-compliant application MUST implement the
TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
[RFC7539] cipher suites. (see Appendix B.4) [RFC7539] cipher suites. (see Appendix B.4)
A TLS-compliant application MUST support digital signatures with A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1 TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
9.2. Mandatory-to-Implement Extensions 9.2. Mandatory-to-Implement Extensions
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
- Supported Versions ("supported_versions"; Section 4.2.1) - Supported Versions ("supported_versions"; Section 4.2.1)
- Cookie ("cookie"; Section 4.2.2) - Cookie ("cookie"; Section 4.2.2)
- Signature Algorithms ("signature_algorithms"; Section 4.2.3) - Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- Signature Algorithms Certificate ("signature_algorithms_cert";
Section 4.2.3)
- Negotiated Groups ("supported_groups"; Section 4.2.7) - Negotiated Groups ("supported_groups"; Section 4.2.7)
- Key Share ("key_share"; Section 4.2.8) - Key Share ("key_share"; Section 4.2.8)
- Server Name Indication ("server_name"; Section 3 of [RFC6066]) - Server Name Indication ("server_name"; Section 3 of [RFC6066])
All implementations MUST send and use these extensions when offering All implementations MUST send and use these extensions when offering
applicable features: applicable features:
- "supported_versions" is REQUIRED for all ClientHello, ServerHello - "supported_versions" is REQUIRED for all ClientHello, ServerHello
and HelloRetryRequest messages. and HelloRetryRequest messages.
- "signature_algorithms" is REQUIRED for certificate authentication. - "signature_algorithms" is REQUIRED for certificate authentication.
- "supported_groups" is REQUIRED for ClientHello messages using DHE - "supported_groups" is REQUIRED for ClientHello messages using DHE
or ECDHE key exchange. or ECDHE key exchange.
skipping to change at page 103, line 19 skipping to change at page 104, line 9
- "signature_algorithms" is REQUIRED for certificate authentication. - "signature_algorithms" is REQUIRED for certificate authentication.
- "supported_groups" is REQUIRED for ClientHello messages using DHE - "supported_groups" is REQUIRED for ClientHello messages using DHE
or ECDHE key exchange. or ECDHE key exchange.
- "key_share" is REQUIRED for DHE or ECDHE key exchange. - "key_share" is REQUIRED for DHE or ECDHE key exchange.
- "pre_shared_key" is REQUIRED for PSK key agreement. - "pre_shared_key" is REQUIRED for PSK key agreement.
- "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 as the highest version number contained in its
body. Such a ClientHello message MUST meet the following body. Such a ClientHello 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.
skipping to change at page 106, line 9 skipping to change at page 106, line 51
"end_of_early_data", "key_update", and "message_hash" values. "end_of_early_data", "key_update", and "message_hash" values.
This document also uses the TLS ExtensionType Registry originally This document also uses the TLS ExtensionType Registry originally
created in [RFC4366]. IANA has updated it to reference this created in [RFC4366]. IANA has updated it to reference this
document. The registry and its allocation policy is listed below: document. The registry and its allocation policy is listed below:
- IANA [SHALL update/has updated] this registry to include the - IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes", "key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions", "early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", "post_handshake_auth", "certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_certs", 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 a new registry to be maintained by
IANA: IANA:
skipping to change at page 122, line 45 skipping to change at page 123, line 45
signed_certificate_timestamp(18), /* RFC 6962 */ signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */ client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */ server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */ padding(21), /* RFC 7685 */
RESERVED(40), /* Used but never assigned */ RESERVED(40), /* Used but never assigned */
pre_shared_key(41), /* [[this document]] */ pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */ early_data(42), /* [[this document]] */
supported_versions(43), /* [[this document]] */ supported_versions(43), /* [[this document]] */
cookie(44), /* [[this document]] */ cookie(44), /* [[this document]] */
psk_key_exchange_modes(45), /* [[this document]] */ psk_key_exchange_modes(45), /* [[this document]] */
RESERVED(46), /* Used but never assigned */
certificate_authorities(47), /* [[this document]] */ certificate_authorities(47), /* [[this document]] */
oid_filters(48), /* [[this document]] */ oid_filters(48), /* [[this document]] */
post_handshake_auth(49), /* [[this document]] */ post_handshake_auth(49), /* [[this document]] */
signature_algorithms_cert(50), /* [[this document]] */ signature_algorithms_cert(50), /* [[this document]] */
key_share(51), /* [[this document]] */ key_share(51), /* [[this document]] */
(65535) (65535)
} ExtensionType; } ExtensionType;
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
struct { struct {
KeyShareEntry client_shares<0..2^16-1>; KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello; } KeyShareClientHello;
struct { struct {
skipping to change at page 136, line 10 skipping to change at page 137, line 10
that a significant number of middleboxes misbehave when a TLS client/ that a significant number of middleboxes misbehave when a TLS client/
server pair negotiates TLS 1.3. Implementations can increase the server pair negotiates TLS 1.3. Implementations can increase the
chance of making connections through those middleboxes by making the chance of making connections through those middleboxes by making the
TLS 1.3 handshake look more like a TLS 1.2 handshake: TLS 1.3 handshake look more like a TLS 1.2 handshake:
- The client always provides a non-empty session ID in the - The client always provides a non-empty session ID in the
ClientHello, as described in the legacy_session_id section of ClientHello, as described in the legacy_session_id section of
Section 4.1.2. Section 4.1.2.
- If not offering early data, the client sends a dummy - If not offering early data, the client sends a dummy
change_cipher_spec record change_cipher_spec record (see the third change_cipher_spec record (see the third paragraph of Section 5.1)
paragraph of Section 5.1) immediately before its second flight. immediately before its second flight. This may either be before
This may either be before its second ClientHello or before its its second ClientHello or before its encrypted handshake flight.
encrypted handshake flight. If offering early data, the record is If offering early data, the record is placed immediately after the
placed immediately after the first ClientHello. first ClientHello.
- The server sends a dummy change_cipher_spec record immediately - The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a after its first handshake message. This may either be after a
ServerHello or a HelloRetryRequest. ServerHello or a HelloRetryRequest.
When put together, these changes make the TLS 1.3 handshake resemble When put together, these changes make the TLS 1.3 handshake resemble
TLS 1.2 session resumption, which improves the chance of successfully TLS 1.2 session resumption, which improves the chance of successfully
connecting through middleboxes. This "compatibility mode" is connecting through middleboxes. This "compatibility mode" is
partially negotiated: The client can opt to provide a session ID or partially negotiated: The client can opt to provide a session ID or
not and the server has to echo it. Either side can send not and the server has to echo it. Either side can send
skipping to change at page 149, line 21 skipping to change at page 150, line 21
- Cedric Fournet - Cedric Fournet
Microsoft Microsoft
fournet@microsoft.com fournet@microsoft.com
- Anil Gangolli - Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
- David M. Garrett - David M. Garrett
dave@nulldereference.com dave@nulldereference.com
- Illya Gerasymchuk
Independent
illya@iluxonchik.me
- Alessandro Ghedini - Alessandro Ghedini
Cloudflare Inc. Cloudflare Inc.
alessandro@cloudflare.com alessandro@cloudflare.com
- Daniel Kahn Gillmor - Daniel Kahn Gillmor
ACLU ACLU
dkg@fifthhorseman.net dkg@fifthhorseman.net
- Matthew Green - Matthew Green
Johns Hopkins University Johns Hopkins University
 End of changes. 35 change blocks. 
98 lines changed or deleted 126 lines changed or added

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