idnits 2.17.1 draft-ietf-httpbis-http2-tls13-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7540, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2019) is 1680 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 200 -- Looks like a reference, but probably isn't: '2' on line 202 -- Looks like a reference, but probably isn't: '3' on line 204 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP D. Benjamin 3 Internet-Draft Google LLC 4 Updates: 7540 (if approved) September 13, 2019 5 Intended status: Standards Track 6 Expires: March 16, 2020 8 Using TLS 1.3 with HTTP/2 9 draft-ietf-httpbis-http2-tls13-01 11 Abstract 13 This document updates HTTP/2 to prohibit TLS 1.3 post-handshake 14 authentication, as an analog to existing TLS 1.2 renegotiation 15 restriction. 17 Note to Readers 19 _RFC EDITOR: please remove this section before publication_ 21 Discussion of this draft takes place on the HTTP working group 22 mailing list (ietf-http-wg@w3.org), which is archived at 23 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 25 Working Group information can be found at https://httpwg.org/ [2]; 26 source code and issues list for this draft can be found at 27 https://github.com/httpwg/http-extensions/labels/http2-tls13 [3]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 16, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Post-Handshake Authentication in HTTP/2 . . . . . . . . . . . 3 66 4. Other Post-Handshake TLS Messages in HTTP/2 . . . . . . . . . 3 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 7.2. Informative References . . . . . . . . . . . . . . . . . 5 72 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 TLS 1.2 [RFC5246] and earlier support renegotiation, a mechanism for 78 changing parameters and keys partway through a connection. This was 79 sometimes used to implement reactive client authentication in 80 HTTP/1.1 [RFC7230], where the server decides whether to request a 81 client certificate based on the HTTP request. 83 HTTP/2 [RFC7540] multiplexes multiple HTTP requests over a single 84 connection, which is incompatible with the mechanism above. Clients 85 cannot correlate the certificate request with the HTTP request which 86 triggered it. Thus, section 9.2.1 of [RFC7540] forbids 87 renegotiation. 89 TLS 1.3 [RFC8446] updates TLS 1.2 to remove renegotiation in favor of 90 separate post-handshake authentication and key update mechanisms. 91 The former shares the same problems with multiplexed protocols, but 92 the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. 94 This document updates HTTP/2 to similarly forbid TLS 1.3 post- 95 handshake authentication. 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. Post-Handshake Authentication in HTTP/2 107 HTTP/2 servers MUST NOT send post-handshake TLS 1.3 108 CertificateRequest messages. HTTP/2 clients MUST treat TLS 1.3 post- 109 handshake authentication as a connection error (see section 5.4.1 of 110 [RFC7540]) of type PROTOCOL_ERROR. 112 [RFC7540] permitted renegotiation before the HTTP/2 connection 113 preface to provide confidentiality of the client certificate. TLS 114 1.3 encrypts the client certificate in the initial handshake, so this 115 is no longer necessary. HTTP/2 servers MUST NOT send post-handshake 116 TLS 1.3 CertificateRequest messages before the connection preface. 118 The above applies even if the client offered the 119 "post_handshake_auth" TLS extension. This extension is advertised 120 independently of the selected ALPN protocol [RFC7301], so it is not 121 sufficient to resolve the conflict with HTTP/2. HTTP/2 clients that 122 also offer other ALPN protocols, notably HTTP/1.1, in a TLS 123 ClientHello MAY include the "post_handshake_auth" extension to 124 support those other protocols. This does not indicate support in 125 HTTP/2. 127 4. Other Post-Handshake TLS Messages in HTTP/2 129 [RFC8446] defines two other messages that are exchanged after the 130 handshake is complete, KeyUpdate and NewSessionTicket. 132 KeyUpdate messages only affect TLS itself and do not require any 133 interaction with the application protocol. HTTP/2 implementations 134 MUST support key updates when TLS 1.3 is negotiated. 136 NewSessionTicket messages are also permitted. Though these interact 137 with HTTP when early data is enabled, these interactions are defined 138 in [RFC8470] and allowed for in the design of HTTP/2. 140 Unless the use of a new type of TLS message depends on an interaction 141 with the application layer protocol, that TLS message can be sent 142 after the handshake completes. 144 5. Security Considerations 146 This document resolves a compatibility concern between HTTP/2 and TLS 147 1.3 when supporting post-handshake authentication with HTTP/1.1. 148 This lowers the barrier for deploying TLS 1.3, a major security 149 improvement over TLS 1.2. 151 6. IANA Considerations 153 This document has no IANA actions. 155 7. References 157 7.1. Normative References 159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, 161 DOI 10.17487/RFC2119, March 1997, 162 . 164 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 165 (TLS) Protocol Version 1.2", RFC 5246, 166 DOI 10.17487/RFC5246, August 2008, 167 . 169 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 170 Protocol (HTTP/1.1): Message Syntax and Routing", 171 RFC 7230, DOI 10.17487/RFC7230, June 2014, 172 . 174 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 175 "Transport Layer Security (TLS) Application-Layer Protocol 176 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 177 July 2014, . 179 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 180 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 181 DOI 10.17487/RFC7540, May 2015, 182 . 184 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 185 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 186 May 2017, . 188 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 189 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 190 . 192 7.2. Informative References 194 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 195 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 196 2018, . 198 7.3. URIs 200 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 202 [2] https://httpwg.org/ 204 [3] https://github.com/httpwg/http-extensions/labels/http2-tls13 206 Author's Address 208 David Benjamin 209 Google LLC 211 Email: davidben@google.com