idnits 2.17.1 draft-davidben-tls-alps-half-rtt-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 December 2020) is 1239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-davidben-http-client-hint-reliability-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-32 == Outdated reference: A later version (-01) exists of draft-vvv-httpbis-alps-00 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS D. Benjamin 3 Internet-Draft Google LLC 4 Intended status: Informational 3 December 2020 5 Expires: 6 June 2021 7 Comparing ALPS and Half-RTT Data 8 draft-davidben-tls-alps-half-rtt-00 10 Abstract 12 This document compares the Application Layer Protocols Settings 13 extension with the half-RTT feature in TLS 1.3. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 6 June 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Using Half-RTT Data . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Half-RTT Delimiter . . . . . . . . . . . . . . . . . . . 3 51 2.2. Non-Integer HTTP Settings . . . . . . . . . . . . . . . . 4 52 2.3. Early Data and Session Tickets . . . . . . . . . . . . . 4 53 2.4. Client Certificates . . . . . . . . . . . . . . . . . . . 5 54 2.5. TLS Terminators . . . . . . . . . . . . . . . . . . . . . 6 55 2.6. TCP Flow Control . . . . . . . . . . . . . . . . . . . . 7 56 3. Using ALPS . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Half-RTT Delimiter . . . . . . . . . . . . . . . . . . . 8 58 3.2. Non-Integer HTTP Settings . . . . . . . . . . . . . . . . 8 59 3.3. Early Data and Session Tickets . . . . . . . . . . . . . 8 60 3.4. Client Certificates . . . . . . . . . . . . . . . . . . . 8 61 3.5. TLS Terminators . . . . . . . . . . . . . . . . . . . . . 8 62 3.6. TCP Flow Control . . . . . . . . . . . . . . . . . . . . 9 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6. Informative References . . . . . . . . . . . . . . . . . . . 9 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 An application-layer protocol often starts with both parties 72 negotiating parameters under which the protocol operates; for 73 instance, HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http] use a 74 SETTINGS frame to exchange the list of protocol parameters supported 75 by each endpoint. This can achieved by waiting for TLS handshake 76 [RFC8446] to complete and then performing the application-layer 77 handshake within the application protocol itself. 79 This approach, however, means application protocols must wait for a 80 secondary negotiation to complete, often incurring network round- 81 trip. HTTP/2 and HTTP/3 mitigate this with a best-effort negotiation 82 scheme: clients do not wait for server SETTINGS before sending a 83 request. But then, by the time the client applies the setting, it 84 has already sent the first request based on the default values. This 85 limits the kinds of extensions possible. For example, the SETTINGS 86 frame cannot support negotiate header compression [QUIC-3622] or a 87 different static table [HTTP2-788] without changing the protocol to 88 disable compression by default and switch partway through. 90 Protocol selection is another example of application-level 91 negotiation with these trade-offs. The Application Layer Protocol 92 Negotiation (ALPN) extension [RFC7301] adds protocol selection into 93 the TLS handshake. ALPN is instead consistently ordered before all 94 application data, including TLS 1.3 early data, without either a 95 round-trip penalty or the need to send initial pre-negotiation data 96 (see Section 3.2 of [RFC7540]). 98 The Application Layer Protocol Settings (ALPS) extension 99 [I-D.vvv-tls-alps] implements [QUIC-3086-COMMENT] and adds a similar 100 mechanism for settings within the protocol. It sends ALPN-specific 101 protocol settings strings in the handshake, which can be ordered 102 correctly relative to application data and integrated with TLS 1.3 103 early data negotiation. 105 As an alternative, Section 4.4.4 of [RFC8446] allows a server to send 106 application data after the server Finished message, often referred to 107 as half-RTT data. Half-RTT data is not a complete solution to the 108 settings problem, however. This document describes the other changes 109 necessary and compares the approach to ALPS. 111 2. Using Half-RTT Data 113 Although not currently widely-implemented, half-RTT data can be used 114 to deliver HTTP/2 SETTINGS and other values at the right round-trip. 115 This would result in a handshake flow like the following. 117 Client Server 119 ClientHello --------> 120 ServerHello 121 ... 122 {Finished} 123 <-------- [HTTP/2 SETTINGS] 124 ... 125 {Finished} 126 [HTTP/2 SETTINGS] --------> 127 [HTTP/2 requests] <-------> [HTTP/2 responses] 129 The approach, however, requires a number of additional changes and 130 protocol interactions to work correctly. 132 2.1. Half-RTT Delimiter 134 In this design, the client waits to receive the HTTP/2 SETTINGS frame 135 before sending requests. However, HTTP/2 servers are not required to 136 send SETTINGS in half-data today, and most existing ones do not. 137 [[TODO: Did I ever write this down anywhere I can link to? When I 138 probed TLS 1.3 HTTP/2 servers, I found none that send half-RTT 139 data.]] Without a new signal to the client, waiting would add a 140 latency penalty to existing servers. TLS 1.3 does not include a 141 delimiter between half-RTT data and the rest of the server 142 application stream, so the client does not know a priori when it is 143 done reading. 145 One option would be a TLS extension that adds a delimiter between 146 half-RTT and normal server application data. The client would then 147 wait for that delimiter without round-trip penalty and proceed. This 148 would not work in QUIC because QUIC does not use TLS for application 149 data at all. Instead, half-RTT data would need to be lifted into the 150 handshake, which is the ALPS extension. 152 Alternatively, the client could rely on application protocol 153 semantics, and assume the protocol defines exactly what is sent in 154 half-RTT. However, HTTP/2 does not do this today. This would 155 require defining new HTTP/2.1 and HTTP/3.1 protocols with a MUST- 156 level requirement to send half-RTT SETTINGS. HTTP/2.1 and HTTP/3.1 157 would be negotiated via ALPN. Note both HTTP/2 and HTTP/3 must be 158 updated because, per Section 3.2 of [I-D.ietf-quic-http], 159 connectivity problems can break QUIC and clients are encouraged to 160 fall back to a TCP-based version of HTTP. 162 2.2. Non-Integer HTTP Settings 164 The HTTP/2 and HTTP/3 SETTINGS frame can only carry integer values, 165 but extensions may need to carry variable-length data. For example, 166 [I-D.davidben-http-client-hint-reliability] uses a string value. 168 [I-D.bishop-httpbis-extended-settings] proposes an EXTENDED_SETTINGS 169 frame to fix this. If defining HTTP/2.1 and HTTP/3.1, 170 EXTENDED_SETTINGS can be added as a mandatory component of the new 171 protocols. 173 If EXTENDED_SETTINGS is left optional, the client needs to know 174 whether to expect a half-RTT EXTENDED_SETTINGS frame after half-RTT 175 SETTINGS, to avoid the issues discussed in Section 2.1. Thus 176 SETTINGS would need to contain a SETTINGS_EXTENDED_SETTINGS setting 177 to indicate more half-RTT frames are coming. 179 [HTTPWG-COMMENT] suggested tabling EXTENDED_SETTINGS in favor of 180 extensions defining new HTTP frames. That would not work here, 181 absent each extension additionally defining an analog to 182 SETTINGS_EXTENDED_SETTINGS, to signal to the client to expect a new 183 frame. 185 2.3. Early Data and Session Tickets 187 TLS 1.3 introduces early data, which allows clients to send 188 application data before receiving a ServerHello from the server. 189 [RFC8470] describes how to use it in HTTP. 191 Application-level connection properties additionally must be 192 established before the client sends early data. Otherwise if, for 193 instance, HPACK static tables are negotiated, the client will not be 194 able to encode the early request. Note Section 2 of [RFC8470] says 195 early data in HTTP is conceptually concatenated with other 196 application data, so early data and 1-RTT data in HTTP must share 197 decoding rules. 199 Early data is sent before any response from the server, so connection 200 properties are typically carried over from the ticket. 201 Section 4.2.10 of [RFC8446] describes the mechanism for the ALPN 202 extension: Each PSK has an associated ALPN protocol, determined from 203 the previous connection. The client sends early data assuming that 204 protocol was used. If the server negotiates a different value, it 205 rejects early data. 207 Reliably-ordered protocol settings would require a similar 208 construction. However TLS does not define ALPN's early data behavior 209 generally, so every application protocol would need to define it 210 themselves and, when implementing, rely on various callback 211 interfaces in the TLS implementation. 213 This also introduces a dependency between NewSessionTicket and the 214 server application data stream: the NewSessionTicket is not 215 meaningful without part of the server application data (here, the 216 SETTINGS and EXTENDED_SETTINGS frames). Moreover, in QUIC and DTLS, 217 post-handshake messages are not ordered relative to application data, 218 so the client may receive NewSessionTicket messages in the wrong 219 order. The client then cannot store sessions in the TLS session 220 until some application-defined point. This requires further 221 integration between TLS and the application protocol. 223 See related discussion in [QUIC-436], [QUIC-2790], and [QUIC-2945]. 224 Note HTTP/3 addressed the ordering issue by making associating 225 settings with the ticket optional on the client [QUIC-2972], while a 226 solution to this problem makes it mandatory. 228 2.4. Client Certificates 230 TLS APIs are often structured around the following sequence of 231 operations: 233 1. The calling application configures TLS parameters. This may 234 include preferred cipher suites, client certificate requirements, 235 callbacks to defer some configuration, etc. 237 2. The calling application runs the handshake to some notion of 238 completion. Before the handshake completes, connection 239 properties are not established, the peer is not authenticated, 240 and the application does not read or write data. 242 3. The calling application queries handshake properties. It may 243 query the negotiated ALPN protocol to determine how to proceed in 244 the application protocol. It may query the peer certificate for 245 application-level access checks. 247 4. The calling application reads and writes data according to the 248 application protocol. 250 This is analogous to many TCP socket APIs, where there is a "connect" 251 or "accept" operation that completes before "recv" and "send" 252 operations are available. 254 In server connections that do not resume a session, the TLS 1.3 half- 255 RTT point has different semantics from a complete TLS handshake. The 256 client's identity has not been established yes, so TLS 257 implementations cannot transparently report the connection as ready 258 to the calling application. Doing so risks security issues (the 259 application's client certificate requirements are not yet checked) 260 and compatibility breaks (the application cannot usefully query the 261 peer certificate). 263 Instead, the TLS implementation might expose a separate interface for 264 an earlier partial completion state. The application would then 265 write half-RTT data, knowing that client authentication requirements 266 are not yet met. This complicates the interface and the above 267 structure. Alternatively, the TLS implementation may require the 268 application configure a byte string to send as half-RTT data during 269 the handshake, but note this risks the deadlocks described in 270 Section 2.6. 272 2.5. TLS Terminators 274 Some server deployments use a TLS terminator which then makes a TCP 275 connection to some backend application server. These deployments 276 would need to preserve any MUST-level requirements to send SETTINGS 277 in half-RTT data. A TLS terminator which completes the handshake and 278 then proxies data from the backend server would inadvertently add a 279 round-trip delay to the SETTINGS frame, delaying HTTP requests. 280 However, a TLS terminator which begins proxying data at the half-RTT 281 point instead risks skipping client certificate authentication. 283 Instead, the TLS terminator must coordinate with the backend server 284 to determine what data may be sent early to unauthenticated clients, 285 and what data is bulk application traffic. 287 2.6. TCP Flow Control 289 If not implemented properly, this design risks deadlocks with TCP 290 flow control [TCP-TLS]. It is possible for both the client Finished 291 flight and the server half-RTT data to exceed transport buffers. The 292 server must read the client Finished flight and complete the 293 handshake, even if the half-RTT data has not been written to the 294 wire. 296 In particular, a TLS implementation may try to avoid the issues in 297 Section 2.4 by treating half-RTT as a configured string sent as part 298 of the handshake, rather than exposing a writable stream to the 299 calling application. This strategy must still write half-RTT data in 300 parallel with completing the handshake to avoid a deadlock. Many TLS 301 implementations are layered on top of non-blocking TCP socket APIs, 302 which means the calling application would still be responsible for 303 driving these parallel operations. This changes the I/O patterns the 304 application expects from TLS. 306 3. Using ALPS 308 The ALPS strategy is described in [I-D.vvv-tls-alps] and 309 [I-D.vvv-httpbis-alps]. It implements [QUIC-3086-COMMENT], sending 310 application settings in the EncryptedExtensions on both client and 311 server. The client half is not strictly necessary (TLS 1.3 is always 312 writable on the client first), but simplifies server implementations 313 in QUIC, where application data streams are not ordered relative to 314 each other. 316 Client Server 318 ClientHello --------> 319 ServerHello 320 {EncryptedExtensions} 321 + alps(HTTP/2 SETTINGS) 322 ... 323 <-------- {Finished} 324 {EncryptedExtensions} 325 + alps(HTTP/2 SETTINGS) 326 ... 327 {Finished} 328 [HTTP/2 requests] <-------> [HTTP/2 responses] 330 3.1. Half-RTT Delimiter 332 ALPS does not require a half-RTT delimiter. The entire payload is 333 sent in the EncryptedExtensions message, which includes a common 334 framing for extension values. 336 3.2. Non-Integer HTTP Settings 338 As in half-RTT data, an ALPS mechanism for HTTP/2 and HTTP/3 must 339 handle the SETTINGS frame limitations. [I-D.vvv-httpbis-alps] allows 340 the ALPS payload to contain multiple frames, so either the 341 [I-D.bishop-httpbis-extended-settings] or [HTTPWG-COMMENT] strategies 342 may be used. The payload is already framed in EncryptedExtensions, 343 so there is no need for an indicator value like 344 SETTINGS_EXTENDED_SETTINGS. 346 3.3. Early Data and Session Tickets 348 As in the half-RTT strategy, ALPS requires early data and session 349 ticket integration. However, this behavior is part of the extension 350 itself, so, like ALPN, there is no need to specify and implement this 351 additional logic for each application protocol. 353 Unlike the application-level integration for half-RTT data, this TLS- 354 level integration for ALPS does not have ordering issues with 355 NewSessionTicket. NewSessionTicket messages are ordered relative to 356 the handshake, so the ALPS values will always be available before a 357 NewSessionTicket. 359 3.4. Client Certificates 361 As in ALPN and the half-RTT strategy, the server ALPS value is sent 362 before receiving the client certificate. In ALPS, this would be part 363 of the extension semantics exposed to application protocols, just as 364 ALPN configuration is not protected by client certificates. 366 3.5. TLS Terminators 368 As in the half-RTT solution, ALPS requires a TLS terminator 369 deployment to coordinate with its backend server to separate the 370 early, unauthenticated SETTINGS data from the rest of the stream. 371 However, the payload is already naturally kept separate from the rest 372 of the application stream. Instead, the settings values are an 373 analog of the ALPN value, which already requires coordination. 375 3.6. TCP Flow Control 377 ALPS sends the settings values in-band in the TLS handshake, rather 378 than afterwards, so the deadlock risks described in [TCP-TLS] do not 379 apply. The client will read the entire EncryptedExtensions message 380 (and more) before trying to send the client Certificate, 381 CertificateVerify, and Finished. 383 4. Security Considerations 385 Any server information delivered in time for the client's first 386 application data records must be sent before checking client 387 certificates. Section 2.4 and Section 3.4 discuss strategies for 388 ensuring the calling application does not inadvertently reveal 389 sensitive information to unauthenticated clients. 391 5. IANA Considerations 393 This document has no IANA considerations. 395 6. Informative References 397 [HTTP2-788] 398 "Update the HPACK static table", November 2020, 399 . 401 [HTTPWG-COMMENT] 402 Thomson, M., "draft-bishop-httpbis-extended-settings-00 403 comments", 13 July 2016, 404 . 407 [I-D.bishop-httpbis-extended-settings] 408 Bishop, M., "HTTP/2 Extended SETTINGS Extension", Work in 409 Progress, Internet-Draft, draft-bishop-httpbis-extended- 410 settings-01, 15 November 2016, . 414 [I-D.davidben-http-client-hint-reliability] 415 Benjamin, D., "Client Hint Reliability", Work in Progress, 416 Internet-Draft, draft-davidben-http-client-hint- 417 reliability-02, 30 November 2020, . 421 [I-D.ietf-quic-http] 422 Bishop, M., "Hypertext Transfer Protocol Version 3 423 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 424 quic-http-32, 20 October 2020, . 427 [I-D.vvv-httpbis-alps] 428 Vasiliev, V., "Using TLS Application-Layer Protocol 429 Settings (ALPS) in HTTP", Work in Progress, Internet- 430 Draft, draft-vvv-httpbis-alps-00, 6 July 2020, 431 . 434 [I-D.vvv-tls-alps] 435 Benjamin, D. and V. Vasiliev, "TLS Application-Layer 436 Protocol Settings Extension", Work in Progress, Internet- 437 Draft, draft-vvv-tls-alps-01, 21 September 2020, 438 . 441 [QUIC-2790] 442 Thomson, M., "Binding settings into session tickets", July 443 2019, . 445 [QUIC-2945] 446 Oku, K., "When to send the SETTINGS frame", July 2019, 447 . 449 [QUIC-2972] 450 Bishop, M., "Send complete SETTINGS", August 2019, 451 . 453 [QUIC-3086-COMMENT] 454 Bishop, M., "Add application parameters to QUIC handshake 455 and use it for H3 SETTINGS (comment)", 17 October 2019, 456 . 459 [QUIC-3622] 460 "Make using static table and Huffman encoding in QPACK 461 opt-in", May 2020, 462 . 464 [QUIC-436] Rescorla, E., "Move SETTINGS into TLS Handshake", April 465 2017, . 467 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 468 "Transport Layer Security (TLS) Application-Layer Protocol 469 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 470 July 2014, . 472 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 473 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 474 DOI 10.17487/RFC7540, May 2015, 475 . 477 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 478 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 479 . 481 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 482 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 483 2018, . 485 [TCP-TLS] Benjamin, D., "TLS 1.3 and TCP interactions", 29 May 2020, 486 . 489 Acknowledgments 491 This document has benefited from contributions and suggestions from 492 Victor Vasiliev. 494 Author's Address 496 David Benjamin 497 Google LLC 499 Email: davidben@google.com