idnits 2.17.1 draft-duke-quic-protected-initial-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 May 2021) is 1078 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 (-18) exists of draft-ietf-tls-esni-10 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-08 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-03 == Outdated reference: A later version (-10) exists of draft-duke-quic-version-aliasing-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 quic M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Standards Track 4 May 2021 5 Expires: 5 November 2021 7 Protected QUIC Initial Packets 8 draft-duke-quic-protected-initial-00 10 Abstract 12 QUIC encrypts its Initial Packets using keys derived from well-known 13 constants, meaning that observers can inspect the contents of these 14 packets and successfully spoof them. This document proposes a new 15 version of QUIC that encrypts Initial Packets more securely by 16 leveraging a Public Key distributed via the Domain Name System (DNS) 17 or other out-of-band system. 19 Discussion of this work is encouraged to happen on the QUIC IETF 20 mailing list quic@ietf.org or on the GitHub repository which contains 21 the draft: https://github.com/martinduke/quic-version-aliasing. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 November 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Version Number . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Key Derivation Labels . . . . . . . . . . . . . . . . . . . . 4 61 6. Initial Packet Header . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Encryption Context . . . . . . . . . . . . . . . . . . . 5 63 7. Client Packet Protection Procedure . . . . . . . . . . . . . 5 64 8. Server Packet Protection Procedure . . . . . . . . . . . . . 6 65 9. Retry Integrity Tag . . . . . . . . . . . . . . . . . . . . . 6 66 10. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 7 67 11. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 7 68 12. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 69 13. Security and Privacy Considerations . . . . . . . . . . . . . 7 70 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 15.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 15.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 DISCLAIMER: This draft is a preliminary proposal with insufficient 79 security analysis. It should not be used in production systems. 81 The QUIC Initial Packet [QUIC-TRANSPORT] is encrypted using a key 82 derived from the Destination Connection ID in the packet cleartext 83 and a well-known salt (see Section 5.2 of [QUIC-TLS]). Section 7 of 84 that draft describes security vulnerabilities resulting from the 85 resulting lack of authentication. 87 This also has privacy implications, as observers can decrypt the 88 packet and inspect the contents, which contain the TLS Client Hello 89 and Server Hello Messages ([RFC8446]). The former contains QUIC 90 Transport Parameters, which reveal even more information about the 91 traffic. 93 Furthermore, packets vulnerable to deep inspection create an 94 ossification vector. Intermediaries that expect the contents of 95 these messages to match a certain format and template might drop 96 packets that do not, preventing the use of new protocol extensions or 97 improved security protocols. 99 This document proposes a new version of QUIC where the client obtains 100 a public key generated by the server and uses it to encrypt a shared 101 secret, sent in the Initial packet header, that both endpoints can 102 then use to protect Initial packets. 104 This mechanism leverages the public key that would be distributed via 105 DNS (or other out-of-band mechanism) to support Encrypted Client 106 Hello [ECHO]. That design uses Hybrid Public Key Exchange (HPKE) 107 ([HPKE] to authenticate some HPKE configuration information and the 108 "outer client hello" that is in plaintext, while encrypting the 109 "inner client hello" that contains privacy-sensitive information. 110 This document uses the widespread configuration that will exist if 111 ECHO is widely deployed, but only sends the subset of information 112 necessary to seed the QUIC key generation process. 114 This design is meant to be complimentary with QUIC Version Aliasing 115 [VERSION-ALIASING]. Version Aliasing does not require coordination 116 with DNS or costly asymmetric encryption, and also hinders 117 ossification of the QUIC version field. However, it does not protect 118 the first connection between the client and server, and can be 119 difficult to coordinate with intermediaries like client-facing load 120 balancers. This document addresses those use cases. 122 Unlike [ECHO], Protected Initial Packets protect the entire packet 123 payloads that contain the Client Hello and Server Hello, instead of 124 just part of the Client Hello. 126 The version of QUIC described in this specification is identical to 127 QUIC version 1 [QUIC-TRANSPORT] except where described in this 128 document. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 3. Key Configuration 138 The client obtains the Encrypted ClientHello Configuration 139 (ECHConfig) described in Section 4 of [ECHO], which provides the 140 context that allows protection of Initial packets. The ECHConfig is 141 available via a DNS record or other out-of- band system. 143 4. Version Number 145 The version field in long headers is TBD. Note: for interoperability 146 exercises, use the provisional value 0xff454900. 148 5. Key Derivation Labels 150 The labels used to derive keying material in [QUIC-TLS] change from 151 "quic key", "quic iv", "quic hp", and "quic ku" to "quicpi key", 152 "quicpi iv", "quicpi hp", and "quicpi ku", respectively. 154 6. Initial Packet Header 156 The figure below is presented in the format from [QUIC-TRANSPORT], 157 and adds a variable-length Encryption Context preceded by a length 158 field: 160 Initial Packet { 161 Header From (1) = 1, 162 Fixed Big (1) = 1, 163 Long Packet Type (2) = 0, 164 Reserved Bits (2), 165 Packet Number Length (2), 166 Version (32), 167 Destination Connection ID Length (8), 168 Destination Connection ID (0..160), 169 Source Connection ID Length (8), 170 Source Connection ID (0..160), 171 Encryption Context Length (8), 172 Encryption Context (..), 173 Token Length (i), 174 Token (..), 175 Length (i), 176 Packet Number (8..32), 177 } 179 Encryption Context Length: A variable-length integer specifying the 180 length of the encryption context, in bytes. Servers MUST set this 181 field to zero; a client that receives a non-zero length MUST either 182 discard the packet or generate a connection error of type 183 PROTOCOL_VIOLATION. 185 If a client has received a valid Server Initial packet, it SHOULD set 186 this field to zero. Until then, clients MUST use a nonzero value. 187 If a client Initial packet has a zero Encryption Context Length, and 188 the server has not sent an Initial Packet, the server MUST either 189 discard the packet or generate a connection error of type 190 PROTOCOL_VIOLATION. 192 6.1. Encryption Context 194 The encryption context, if nonzero length, has the following format: 196 Encryption Context { 197 Config ID (8), 198 Encapsulated Secret (..), 199 } 201 The client obtains the Config ID (an 8-bit unsigned integer) from the 202 ECHConfig. It corresponds to a public key and Key Encapsulation 203 Mechanism (KEM) that are not sent over the wire. 205 The Encapsulated Secret is HPKE encapsulated. Its length is inferred 206 from the Encryption Context Length field. 208 7. Client Packet Protection Procedure 210 An client extracts the public key pkR and uses it to generate a 211 shared_secret: 213 pkR = Deserialize(ECHConfig.contents.public_key) 214 shared_secret, enc = Encap(pkR) 215 initial_secret = HKDF-Extract(shared_secret, 216 client_dst_connection_id || ECHConfig) 218 enc is the Encapsulated Secret, and is written into that subfield of 219 the Encryption Context Field. 221 The initial_secret above is used to generate client_initial_secret 222 and server_initial_secret as described in Section 5.2 of [QUIC-TLS]. 224 When applying header protection, the Context Length and Encryption 225 Context are not Protected. 227 Additionally, the client bitwise-XORs the first eight octets of the 228 Destination Connection ID with the first eight octets of the public 229 key to form a 64 bit unsigned integer. This integer is added to the 230 packet length, modulo 2^62, and written into the packet length field 231 instead of the actual packet length. 233 This derivation is performed once per connection. Subsequent Initial 234 Packets use the same keys and the same offset to the packet number, 235 regardless of additional Encryption Context fields or changed 236 connection IDs. 238 8. Server Packet Protection Procedure 240 The server reads the Config ID and Encapsulated Secret (enc) from the 241 Initial Packet. It looks up its private key (skR) associated with 242 the Config ID. 244 Prior to any other operations, including sending any Retry packet, 245 the server bitwise-XORs the first eight octets of its public key and 246 the destination connection ID and subtracts this from the value in 247 the packet length field, modulo 2^62, to find the true packet length. 249 Any result that exceeds the size of the received datagram indicates 250 with high assurance that the client's received ECHConfig does not 251 match the server's state, possibly due to a misconfiguration. The 252 probability this test results in a false negative, when an incorrect 253 key generates a result less than the datagram size, is typically less 254 than 1 in 2^51. The server MUST discard the packet and SHOULD send a 255 Version Negotiation packet that does not advertise the current QUIC 256 version, as the endpoints do not have the necessary shared state to 257 use QUIC Protected Initials. 259 Otherwise, the server generates the Initial secrets: 261 shared_secret = Decap(enc, skR) 262 initial_secret = HKDF-Extract(shared_secret, 263 client_dst_connection_id || ECHConfig) 265 The server now has sufficient context to send a Retry packet and MAY 266 choose to do so at this point (see Section 9). If not, it decrypts 267 the Initial packet. 269 The remainder is identical to the client procedure. 271 9. Retry Integrity Tag 273 The Retry packet is identical to QUIC version 1, except that the 274 secret key K and nonce N (see Sec 5.8 of [QUIC-TLS]) are derived from 275 the shared_secret instead of the secret provided there. Also, the 276 labels are as described in Section 5. 278 10. Version Negotiation 280 Endpoints that support QUIC Protected Initials MUST support at least 281 one other version of QUIC (in case the endpoints cannot agree on the 282 ECHConfig), and therefore MUST also support 283 [I-D.ietf-quic-version-negotiation]. 285 In contrast to Section 5 of that document, clients MUST be prepared 286 to receive a version negotiation packet that contains QUIC Protected 287 Initial, and then receive a second version negotiation packet that 288 does not, should the attempt to identify a common ECHConfig fail. 290 Servers MAY continue to advertise QUIC Protected Initials in its 291 Server Handshake Version Information, even if shared secret 292 extraction failed, to avoid tracking state as to which clients have 293 failed such extraction. This does not effect the Version Downgrade 294 mechanism, which is executed by servers. 296 Note that QUIC version 1 is not compatible with QUIC Protected 297 Initials, as it does not contain the information necessary to 298 generate subsequent Initial packets correctly. Conversely, QUIC 299 Protected Initials are compatible with QUIC version 1. However, 300 since the versions have identical properties after the Initial packet 301 exchange, there is little value in such a trasition. 303 11. Intermediaries 305 Intermediaries that rely on the contents of the Client Hello (e.g., a 306 load balancer that routes between servers with the same IP address 307 based on the SNI field in the Client Hello) MUST have access to the 308 ECHConfig and the corresponding Private Keys, as described in 309 Section 3.1 of [ECHO], to function properly. 311 12. Applicability 313 This version of QUIC provides no change from QUIC version 1 relating 314 to the capabilities available to applications. Therefore, all 315 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 316 specified to operate over QUICv1 can also operate over this version 317 of QUIC. 319 13. Security and Privacy Considerations 321 Sections 10.2, 10.3, 10.4, and 10.6 of [ECHO] apply to QUIC Protected 322 Initials as well. 324 Sections 7.2, 7.3, 7.7, and 7.8 of [VERSION-ALIASING] are also 325 applicable. 327 14. IANA Considerations 329 This document request that IANA add the following entry to the QUIC 330 version registry: 332 Value: TBD 334 Status: permanent 336 Specification: This document 338 Change Controller: IETF 340 Contact: QUIC WG 342 15. References 344 15.1. Normative References 346 [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 347 Encrypted Client Hello", Work in Progress, Internet-Draft, 348 draft-ietf-tls-esni-10, 8 March 2021, 349 . 352 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 353 "Hybrid Public Key Encryption", Work in Progress, 354 Internet-Draft, draft-irtf-cfrg-hpke-08, 15 February 2021, 355 . 358 [I-D.ietf-quic-version-negotiation] 359 Schinazi, D. and E. Rescorla, "Compatible Version 360 Negotiation for QUIC", Work in Progress, Internet-Draft, 361 draft-ietf-quic-version-negotiation-03, 4 February 2021, 362 . 365 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 366 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 367 14 January 2021, . 370 [QUIC-TRANSPORT] 371 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 372 and Secure Transport", Work in Progress, Internet-Draft, 373 draft-ietf-quic-transport-34, 14 January 2021, 374 . 377 15.2. Informative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 385 "Transport Layer Security (TLS) Application-Layer Protocol 386 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 387 July 2014, . 389 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 390 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 391 . 393 [VERSION-ALIASING] 394 Duke, M., "QUIC Version Aliasing", Work in Progress, 395 Internet-Draft, draft-duke-quic-version-aliasing-04, 30 396 October 2020, . 399 Author's Address 401 Martin Duke 402 F5 Networks, Inc. 404 Email: martin.h.duke@gmail.com