idnits 2.17.1 draft-kazuho-quic-authenticated-handshake-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2018) is 1953 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC8446' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-16 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-16 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC K. Oku 3 Internet-Draft Fastly 4 Intended status: Experimental C. Huitema 5 Expires: June 17, 2019 Private Octopus Inc. 6 December 14, 2018 8 Authenticated Handshake for QUIC 9 draft-kazuho-quic-authenticated-handshake-00 11 Abstract 13 This document explains a variant of QUIC protocol version 1 that uses 14 the ESNI Keys to authenticate the Initial packets thereby making the 15 entire handshake tamper-proof. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 17, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 53 2. Differences from QUIC version 1 . . . . . . . . . . . . . . . 3 54 2.1. Protocol Version Number . . . . . . . . . . . . . . . . . 3 55 2.2. The "QUIC-ESNI" TLS Extension . . . . . . . . . . . . . . 3 56 2.3. Initial Packet Protection . . . . . . . . . . . . . . . . 3 57 2.4. Version Negotiation Packet . . . . . . . . . . . . . . . 4 58 2.5. Connection Close Packet . . . . . . . . . . . . . . . . . 4 59 2.6. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Using GCM to Authenticate Initial Packets . . . . . . . . 5 62 3.2. Use of Different QUIC Version Number . . . . . . . . . . 6 63 3.2.1. Trial Decryption . . . . . . . . . . . . . . . . . . 6 64 3.2.2. Rekeying at the Server's First Flight . . . . . . . . 6 65 3.3. No Support for Split Mode . . . . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 As defined in Secure Using TLS to Secure QUIC [QUIC-TLS], QUIC 75 version 1 [QUIC-TRANSPORT] protects the payload of every QUIC packet 76 using AEAD making the protocol injection- and tamper-proof, with the 77 exception being the Initial packets. Initial packets are merely 78 obfuscated because there is no shared secret between the endpoints 79 when they start sending the Initial packets against each other. 81 However, when Encrypted Server Name Indication for TLS 1.3 [TLS-ESNI] 82 is used, a shared secret between the endpoints can be used for 83 authentication from the very first packet of the connection. 85 This document defines a Packet Protection method for Initial packets 86 that incorporates the ESNI shared secret, so that spoofed Initial 87 packets will be detected and droped. 89 1.1. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Differences from QUIC version 1 97 The document describes the changes from QUIC version 1. 99 Implementations MUST conform to the specifications of QUIC version 1 100 unless a different behavior is defined in this document. 102 2.1. Protocol Version Number 104 The long header packets exchanged using this specification carry the 105 QUIC version number of 0xXXXXXXXX (TBD). 107 2.2. The "QUIC-ESNI" TLS Extension 109 The QUIC-ESNI TLS Extension indicates the versions of the QUIC 110 protocol that the server supports. The values in the extension 111 SHOULD be identical to what would be included in the Version 112 Negotiation packet. 114 struct { 115 uint32 supported_versions<4..2^16-4>; 116 } QUIC_ESNI; 118 A server willing to accept QUIC connections using this specification 119 MUST publish ESNI Resource Records that contain the QUIC_ESNI 120 extension including the QUIC version number 0xXXXXXXXX. 122 A client MUST NOT initiate a connection establishment attempt 123 specified in this document unless it sees a compatible version number 124 in the QUIC_ESNI extension of the ESNI Resource Record advertised by 125 the server. 127 2.3. Initial Packet Protection 129 Initial packets are encrypted and authenticated differently from QUIC 130 version 1. 132 AES [AES] in counter (CTR) mode is used for encrypting the payload. 133 The key and iv being used are identical to that of QUIC version 1. 135 HMAC [RFC2104] is used for authenticating the header. The message 136 being authenticated is the concatenation of the packet header without 137 Header Protection and the payload in cleartext. The underlying hash 138 function being used is the one selected for encrypting the Encrypted 139 SNI extension. The HMAC key is calculated using the following 140 formula: 142 hmac_key = HKDF-Expand-Label(Zx, "quic initial auth", Hash(ESNIContents), 143 digest_size) 145 The first sixteen (16) octets of the HMAC output replaces the 146 authentication tag of QUIC version 1. 148 Other types of packets are protected using the Packet Protection 149 method defined in QUIC version 1. 151 2.4. Version Negotiation Packet 153 A client MUST ignore Version Negotiation packets. When the client 154 gives up of establishing a connection, it MAY report the failure 155 differently based on the receipt of (or lack of) Version Negotiation 156 packets. 158 2.5. Connection Close Packet 160 A Connection Close packet shares a long packet header with a type 161 value of 0x3 with the Retry packet. The two types of packets are 162 identified by the lower 4-bits of the first octet. The packet is a 163 Connection Close packet if all the bits are set to zero. Otherwise, 164 the packet is a Retry packet. 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+ 169 |1|1| 3 | 0 | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Version (32) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |DCIL(4)|SCIL(4)| 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Destination Connection ID (0/32..144) ... 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Source Connection ID (0/32..144) ... 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Error Code (16) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 (: #connection-close-format title="Connection Close Packet") 184 A Connection Close packet is sent by a server when a connection error 185 occurs prior to deriving the HMAC key. In all other conditions, 186 connection close MUST be signalled using the CONNECTION_CLOSE frame. 188 A client that receives a Connection Close packet before an Initial 189 packet SHOULD retain the error code, and continue the connection 190 establishment attempt as if it did not see the packet. When the 191 attempt times out, it MAY assume that the error code was a legitimate 192 value sent by the server. A client MAY ignore Connection Close 193 packets. 195 2.6. Retry Packet 197 A client SHOULD send an Initial packet in response to each Retry 198 packet it receives. Payload of the CRYPTO frame contained in the 199 resent Initial packets MUST be identical to that of the Initial 200 packet that triggered the retry. When the client does not receive a 201 valid Initial packet after a handshake timeout, it SHOULD send at 202 least one Initial packet containing one of the tokens that it has 203 received. Unless the packet gets lost, the retransmission would 204 trigger the server to send either a valid Initial packet or a Retry 205 packet. 207 To a server, the behavior of a client under attack would look like it 208 is aggressively retransmitting Initial packets, some of them 209 containing invalid tokens. 211 Therefore, a server MUST NOT terminate the connection when it 212 receives an Initial packet that contains an invalid token. Instead, 213 it SHOULD either process the packet as if it did not contain a token, 214 or send a Retry. 216 A client MUST ignore Retry packets received anterior to an Initial 217 packet that successfully authenticates. 219 3. Considerations 221 3.1. Using GCM to Authenticate Initial Packets 223 An alternative approach to using the combination of AES-CTR and HMAC 224 is to continue using AES-GCM. In such approach, the additional 225 authenticated data (AAD) will incorporate the ESNI shared secret to 226 detect spoofed or broken packets. 228 A server that receives an Initial packet for a new connection will at 229 first decrypt the payload using AES-CTR, derive ESNI shared secret 230 from the Hello message being contained, then use that to verify the 231 GCM tag. 233 The benefit of the approach is that we will have less divergence from 234 QUIC version 1. The downside is that the authentication algorithm 235 would be hard-coded to GCM, and that some AEAD APIs might not provide 236 an interface to handle input in this particular way. 238 We can also consider adding a small checksum to the Initial packets 239 so that the server can determine if the packet is corrupt. The 240 downside is that the endpoints would be required to calculate the 241 checksum for Initial packets that carry server's messages and ACKs as 242 well, even though the correctness of the packet can be verified using 243 the ordinary procedure of AEAD. 245 3.2. Use of Different QUIC Version Number 247 For this specification, use of a different QUIC version number is not 248 expected to have negative impact on user-experience by raising the 249 chance of version negotiation, because version negotiation finishes 250 before the client sends it's first packet. 252 Use of Encrypted SNI will stick out more, because it can be 253 identified by observing a different version number in the long header 254 packet rather than by decrypting the Initial packet to see if the 255 Encrypted SNI extension is in use. 257 The subsections below discuss alternative approaches that do not 258 change the version number of QUIC. 260 3.2.1. Trial Decryption 262 It is possible to use the proposed Packet Protection method without 263 changing the version number. The difference from the recommended 264 method is that the server would be required to do "trial decryption." 266 However, it is not as bad as it sounds, because authentication 267 failure in AES-GCM decryption is typically reported after the 268 ciphertext is decrypted. 270 When accepting a new connection, a QUIC server can at first decrypt 271 the Initial packet using AES-GCM. The packet is a ordinary QUIC 272 version 1 packet if it is successfully authenticated. Otherwise, the 273 server will feed the decrypted payload (which would be available 274 anyways) assuming that it contains a ClientHello message, and if the 275 TLS stack successfully processes the message returning the handshake 276 keys and the ESNI shared key, verify the HMAC to see if the packet 277 authenticates. If it does, the server creates a new connection 278 context and responds with an Initial packet. 280 3.2.2. Rekeying at the Server's First Flight 282 Another approach is to use the Packet Protection method of QUIC 283 version 1 for client's first flight, while using the proposed method 284 for all other Initial packets. 286 The benefit of this approach is that trial decryption can be avoided. 288 The downside is that a man-on-the-side attacker can stitch the 289 Encrypted SNI extension that the client has sent with anything it 290 wants to construct a spoofed packet, then race it to the server. 292 The server would be required to consider Initial packets containing 293 non-identical ClientHello messages as belonging to different 294 connection establishment attempts. 296 The design will also have negative performance impact on connections 297 with high latency. This is because QUIC expects clients to 298 retransmit the Initial packets when the latency is above 250 299 milliseconds. However, the requirement that the server rekeys the 300 Initial secret when receiving the first Initial packet means that the 301 retransmitted Initial packets would become undecryptable and 302 therefore be deemed lost by the client, reducing the client's 303 congestion window size. 305 3.3. No Support for Split Mode 307 Under the design discussed in this document, it is impossible to use 308 an unmodified QUIC server as a backend server in "Split Mode" 309 ([TLS-ESNI]; section 3) due to the following two reasons: 311 o Access to initial_auth_secret is required for generating and 312 validating Initial packets. However, the backend server, not 313 knowing the ESNI private key, cannot calculate the secret. 315 o The client-facing server cannot continue forwarding packets to the 316 correct destination when there is a change in Connection ID mid- 317 connection. 319 To address the issues, we might consider specifying a protocol that 320 will be used between the client-facing server and the backend server 321 for communicating the initial_auth_secret and the spare Connection 322 IDs. Note that such protocol can be lightweight, assuming the 323 communication between the two servers will be over a virtual private 324 network. Such assumption can be made because the backend server 325 cannot operate QUIC without access to the source address-port tuple 326 of the packets that the client has sent. 328 4. Security Considerations 330 TBD 332 5. IANA Considerations 334 TBD 336 6. Acknowledgements 338 TBD 340 7. Normative References 342 [AES] "Advanced encryption standard (AES)", National Institute 343 of Standards and Technology report, 344 DOI 10.6028/nist.fips.197, November 2001. 346 [QUIC-TLS] 347 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 348 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 349 tls-16 (work in progress), October 2018. 351 [QUIC-TRANSPORT] 352 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 353 Multiplexed and Secure Transport", draft-ietf-quic- 354 transport-16 (work in progress), October 2018. 356 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 357 Hashing for Message Authentication", RFC 2104, 358 DOI 10.17487/RFC2104, February 1997, . 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, . 366 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 367 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 368 . 370 [TLS-ESNI] 371 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 372 "Encrypted Server Name Indication for TLS 1.3", draft- 373 ietf-tls-esni-02 (work in progress), October 2018. 375 Authors' Addresses 376 Kazuho Oku 377 Fastly 379 Email: kazuhooku@gmail.com 381 Christian Huitema 382 Private Octopus Inc. 384 Email: huitema@huitema.net