idnits 2.17.1 draft-vvv-tls-alps-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 : ---------------------------------------------------------------------------- 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 (21 September 2020) is 1311 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-30 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group D. Benjamin 3 Internet-Draft V. Vasiliev 4 Intended status: Standards Track Google 5 Expires: 25 March 2021 21 September 2020 7 TLS Application-Layer Protocol Settings Extension 8 draft-vvv-tls-alps-01 10 Abstract 12 This document describes a Transport Layer Security (TLS) extension 13 for negotiating application-layer protocol settings (ALPS) within the 14 TLS handshake. Any application-layer protocol operating over TLS can 15 use this mechanism to indicate its settings to the peer in parallel 16 with the TLS handshake completion. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the TLS Working Group 23 mailing list (tls@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/tls/ 25 (https://mailarchive.ietf.org/arch/browse/tls/). 27 Source for this draft and an issue tracker can be found at 28 https://github.com/vasilvv/tls-alps (https://github.com/vasilvv/tls- 29 alps). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 25 March 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 66 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Client Encrypted Extensions . . . . . . . . . . . . . . . 6 69 4.2. 0-RTT Handshakes . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 An application-layer protocol often starts with both parties 81 negotiating parameters under which the protocol operates; for 82 instance, HTTP/2 [RFC7540] uses a SETTINGS frame to exchange the list 83 of protocol parameters supported by each endpoint. This is usually 84 achieved by waiting for TLS handshake [RFC8446] to complete and then 85 performing the application-layer handshake within the application 86 protocol itself. This approach, despite its apparent simplicity at 87 first, has multiple drawbacks: 89 1. While the server is technically capable of sending configuration 90 to the peer as soon as it sends its Finished message, most TLS 91 implementations do not allow any application data to be sent 92 until the Finished message is received from the client. This 93 adds an extra round-trip to the time of when the server settings 94 are available to the client. 96 2. In QUIC, any settings delivered within the application layer can 97 arrive after other application data; thus, the application has to 98 operate under the assumption that peer's settings are not always 99 available. 101 3. If the application needs to be aware of the server settings in 102 order to send 0-RTT data, the application has to manually 103 integrate with the TLS stack to associate the settings with TLS 104 session tickets. 106 This document introduces a new TLS extension, "application_settings", 107 that allows applications to exchange settings within the TLS 108 handshake. Through doing that, the settings can be made available to 109 the application as soon as the handshake completes, and can be 110 associated with TLS session tickets automatically at the TLS layer. 111 This approach allows the application protocol to be designed with the 112 assumption that it has access to the peer's settings whenever it is 113 able to send data. 115 2. Conventions and Definitions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Semantics 125 Settings are defined to be an opaque blob that is specified by the 126 application when initiating a TLS connection. The settings are meant 127 to be a _declaration_ of the protocol parameters supported by the 128 sender. While in this version of the extension the server settings 129 are always sent first, this may change in future versions; thus, the 130 application MUST NOT vary client settings based on the ones received 131 from the server. 133 ALPS is _not_ a negotiation mechanism: there is no notion of 134 rejecting peer's settings, and the settings are not responses to one 135 another. Nevertheless, it is possible for parties to coordinate 136 behavior by, for instance, requiring a certain parameter to be 137 present in both client and server settings. This makes ALPS 138 mechanism similar to QUIC transport parameters 139 [I-D.ietf-quic-transport] or HTTP/2 SETTINGS frame [RFC7540], but 140 puts it in contrast to similar mechanisms in TLS. 142 Settings are exchanged as a part of the TLS handshake that is 143 encrypted with the handshake keys. When the server settings are 144 sent, the identity of the client has not been yet established; 145 therefore, an application MUST NOT use ALPS if it requires the 146 settings to be available only to the authenticated clients. 148 The ALPS model provides applications with a guarantee that the 149 settings are available before any application data can be written. 150 Note that this implies that when the full handshake is performed, the 151 server can no longer send data immediately after sending its Finished 152 message; it has to wait for the client to respond with its settings. 153 This may negatively impact the latency of the protocols where the 154 server sends the first message, however it should be noted that 155 sending application data before receiving has not been widely 156 supported by TLS implementations, nor has it been allowed in 157 situations when establishing client identity through TLS is required. 159 ALPS can only be used in conjunction with Application-Layer Protocol 160 Negotiation: the client MUST offer ALPN [RFC7301] if advertising ALPS 161 support, and the server MUST NOT reply with ALPS unless it is also 162 negotiating ALPN. The ALPS payload is protocol-dependent, and as 163 such it MUST be specified with respect to a selected ALPN. 165 4. Wire Protocol 167 ALPS is only supported in TLS version 1.3 or later, as the earlier 168 versions do not provide any confidentiality protections for the 169 handshake data. The exchange is performed in three steps: 171 1. The client sends an extension in ClientHello that enumerates all 172 ALPN values for which ALPS is supported. 174 2. The server sends an encrypted extension containing the server 175 settings. 177 3. The client sends an encrypted extension containing the client 178 settings. 180 Client Server 182 ClientHello 183 + alpn 184 + alps --------> 186 ServerHello 187 {EncryptedExtensions} 188 + alpn 189 + alps 190 ... 191 <-------- {Finished} 193 {EncryptedExtensions} 194 + alps 195 {Certificate*} 196 {CertificateVerify*} 197 {Finished} --------> 199 + Indicates extensions sent in the 200 previously noted message. 202 {} Indicates messages protected using 203 the handshake keys. 205 * Indicates optional messages that are 206 not related to ALPS. 208 Figure 1: ALPS exchange in a full TLS handshake 210 A TLS client can enable ALPS by specifying an "application_settings" 211 extension in the ClientHello message. The value of the 212 "extension_data" field for this extension SHALL be a 213 ApplicationSettingsSupport struct: 215 struct { 216 ProtocolName supported_protocols<2..2^16-1>; 217 } ApplicationSettingsSupport; 219 Here, the "supported_protocols" field indicates the names of the 220 protocols (as defined in [RFC7301]) for which ALPS exchange is 221 supported; this is necessary for the situations when the client 222 offers multiple ALPN values but only supports ALPS in some of them. 224 If the server chooses an ALPN value for which the client has offered 225 ALPS support, the server MAY negotiate ALPS by sending an 226 "application_settings" extension in its EncryptedExtensions message. 227 The value of the "extension_data" field in that case SHALL be an 228 opaque blob containing the server settings as specified by the 229 application protocol. 231 If the client receives an EncryptedExtensions message containing an 232 "application_settings" extension from the server, it MUST send an 233 EncryptedExtensions message (see Section 4.1) containing an 234 "application_extensions" extension. The value of the 235 "extension_data" in this extension SHALL be an opaque blob containing 236 the client settings as specified by the application protocol. A 237 server which negotiates ALPS MUST abort the handshake with a 238 "missing_extension" alert if the client's EncryptedExtensions is 239 missing this extension. 241 4.1. Client Encrypted Extensions 243 This specification introduces the client EncryptedExtensions message. 244 The format and HandshakeType code point match the server 245 EncryptedExtensions message. When sent, it is encrypted with 246 handshake traffic keys and sent by the client after receiving the 247 server Finished message and before the client sends the Certificate, 248 CertificateVerify (if any), and Finished messages. It SHALL be 249 appended to the Client Handshake Context, as defined Section 4.4 of 250 [RFC8446]. It additionally SHALL be inserted after the server 251 Finished in the Post-Handshake Handshake Context. 253 The client MUST send the EncryptedExtensions message if any extension 254 sent in the server EncryptedExtension message contains the CEE token 255 in the TLS 1.3 column of the TLS ExtensionType Values registry. 256 Otherwise, the client MUST NOT send the message. The server MUST 257 abort the handshake with a "unexpected_message" alert if the message 258 was sent or omitted incorrectly. 260 The client MAY send an extension in the client EncryptedExtension 261 message if that extension's entry in the registry contains a CEE 262 token and the server EncryptedExtensions message included the 263 extension. Otherwise, the client MUST NOT send the extension. If a 264 server receives an extension which does not meet this criteria, it 265 MUST abort the handshake with an "unsupported_extension" alert. 267 Future extensions MAY use the client EncryptedExtensions message by 268 including the CEE token in the TLS 1.3 registry. The above rules 269 ensure clients will not send EncryptedExtensions messages to older 270 servers, but will send EncryptedExtensions when some negotiated 271 extension uses it. 273 [[TODO: Section 4.6.1 of RFC8446 allows the server to predict the 274 client Finished flight and send a ticket early. This is still 275 possible with 0-RTT handshakes here because we omit rather than 276 repeat the redudant ALPS information, but, in the general extension 277 case, client EncryptedExtensions breaks this. Extension order is 278 unpredictable. We should resolve this conflict, either by dropping 279 that feature or removing flexibility here.]] 281 4.2. 0-RTT Handshakes 283 ALPS ensures settings are available before reading and writing 284 application data, so handshakes which negotiate early data instead 285 use application settings from the PSK. To use early data with a PSK, 286 the TLS implementation MUST associate both client and server 287 application settings, if any, with the PSK. For a resumption PSK, 288 these values are determined from the original connection. For an 289 external PSK, this values should be configured with it. Existing 290 PSKs are considered to not have application settings. 292 If the server accepts early data, the server SHALL NOT send an 293 "application_settings" extension, and thus the client SHALL NOT send 294 a "application_settings" extension in its EncryptedExtensions 295 message. Unless the server has sent some other extension which uses 296 client EncryptedExtensions, the client SHALL NOT send an 297 EncryptedExtensions message. Instead, the connection implicitly uses 298 the PSK's application settings, if any. 300 If the server rejects early data, application settings are negotiated 301 independently of the PSK, as if early data were not offered. 303 If the client wishes to send different client settings for the 304 connection, it MUST NOT offer 0-RTT. Conversely, if the server 305 wishes to use send different server settings, it MUST reject 0-RTT. 306 Note that the ALPN itself is similarly required to match the one in 307 the original connection, thus the settings only need to be remembered 308 or checked for a single application protocol. Implementations are 309 RECOMMENDED to first determine the desired application protocol and 310 settings independent of early data, and then decline to offer or 311 accept early data if the values do not match the PSK. This preserves 312 any ALPN and ALPS configuration specified by the calling application. 314 5. Security Considerations 316 ALPS is protected using the handshake keys, which are the secret keys 317 derived as a result of (EC)DHE between the client and the server. 319 In order to ensure that the ALPS values are authenticated, the TLS 320 implementation MUST NOT reveal the contents of peer's ALPS until 321 peer's Finished message is received, with exception of cases where 322 the ALPS has been carried over from the previous connection. 324 6. IANA Considerations 326 IANA will update the "TLS ExtensionType Values" registry to include 327 "application_settings" with the value of TBD; the list of messages in 328 which this extension may appear is "CH, EE, CEE". 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 340 "Transport Layer Security (TLS) Application-Layer Protocol 341 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 342 July 2014, . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 349 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 350 . 352 7.2. Informative References 354 [I-D.ietf-quic-transport] 355 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 356 and Secure Transport", Work in Progress, Internet-Draft, 357 draft-ietf-quic-transport-30, 9 September 2020, 358 . 361 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 362 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 363 DOI 10.17487/RFC7540, May 2015, 364 . 366 Acknowledgments 368 This document has benefited from contributions and suggestions from 369 Nick Harper, David Schinazi, Renjie Tang and many others. 371 Authors' Addresses 373 David Benjamin 374 Google 376 Email: davidben@google.com 378 Victor Vasiliev 379 Google 381 Email: vasilvv@google.com