idnits 2.17.1 draft-ietf-quic-v2-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 3 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 (22 November 2021) is 886 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 (-14) exists of draft-ietf-quic-version-negotiation-05 == Outdated reference: A later version (-10) exists of draft-duke-quic-version-aliasing-07 Summary: 1 error (**), 0 flaws (~~), 3 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, Inc. 4 Intended status: Standards Track 22 November 2021 5 Expires: 26 May 2022 7 QUIC Version 2 8 draft-ietf-quic-v2-00 10 Abstract 12 This document specifies QUIC version 2, which is identical to QUIC 13 version 1 except for some trivial details. Its purpose is to combat 14 various ossification vectors and exercise the version negotiation 15 framework. It also serves as a template for the minimum changes in 16 any future version of QUIC. 18 Note that "version 2" is an informal name for this proposal that 19 indicates it is the second standards-track QUIC version. The 20 protocol specified here will receive a version number other than 2 21 from IANA. 23 Discussion of this work is encouraged to happen on the QUIC IETF 24 mailing list quic@ietf.org or on the GitHub repository which contains 25 the draft: https://github.com/quicwg/quic-v2. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 26 May 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 3 63 4. Version Negotiation Considerations . . . . . . . . . . . . . 4 64 5. Ossification Considerations . . . . . . . . . . . . . . . . . 4 65 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 9.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6 72 A.1. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 6 73 A.2. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 6 74 A.3. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 QUIC [RFC9000] has numerous extension points, including the version 80 number that occupies the second through fifth octets of every long 81 header (see [RFC8999]). If experimental versions are rare, and QUIC 82 version 1 constitutes the vast majority of QUIC traffic, there is the 83 potential for middleboxes to ossify on the version octets always 84 being 0x00000001. 86 Furthermore, version 1 Initial packets are encrypted with keys 87 derived from a universally known salt, which allow observers to 88 inspect the contents of these packets, which include the TLS Client 89 Hello and Server Hello messages. Again, middleboxes may ossify on 90 the version 1 key derivation and packet formats. 92 Finally [QUIC-VN] provides two mechanisms for endpoints to negotiate 93 the QUIC version to use. The "incompatible" version negotiation 94 method can support switching from any initial QUIC version to any 95 other version with full generality, at the cost of an additional 96 round-trip at the start of the connection. "Compatible" version 97 negotiation eliminates the round-trip penalty but levies some 98 restrictions on how much the two versions can differ semantically. 100 QUIC version 2 is meant to mitigate ossification concerns and 101 exercise the version negotiation mechanisms. The only change is a 102 tweak to the inputs of some crypto derivation functions to enforce 103 full key separation. Any endpoint that supports two versions needs 104 to implement version negotiation to protect against downgrade 105 attacks. 107 [I-D.duke-quic-version-aliasing] is a more robust, but much more 108 complicated, proposal to address these ossification problems. By 109 design, it requires incompatible version negotiation. QUICv2 enables 110 exercise of compatible version negotiation mechanism. 112 2. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Changes from QUIC Version 1 120 QUIC version 2 endpoints MUST implement the QUIC version 1 121 specification as described in [RFC9000], [RFC9001], and [RFC9002], 122 with the following changes: 124 * The version field of long headers is TBD. Note: Unless this 125 document is published as an RFC, implementations should use the 126 provisional value 0xff020000, which might change with each edition 127 of this document. 129 * The salt used to derive Initial keys in Sec 5.2 of [RFC9001] 130 changes to 132 initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3 134 * The labels used in [RFC9001] to derive packet protection keys (Sec 135 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys 136 (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to 137 "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to 138 "quicv2 hp", and from "quic ku" to "quicv2 ku," to meet the 139 guidance for new versions in Section 9.6 of that document. 141 * The key and nonce used for the Retry Integrity Tag (Sec 5.8 of 142 [RFC9001]) change to: 144 secret = 0x3425c20cf88779df2ff71e8abfa78249891e763bbed2f13c048343d348c060e2 145 key = 0xba858dc7b43de5dbf87617ff4ab253db 146 nonce = 0x141b99c239b03e785d6a2e9f 148 4. Version Negotiation Considerations 150 QUIC version 2 endpoints SHOULD also support QUIC version 1. Any 151 QUIC endpoint that supports multiple versions MUST fully implement 152 [QUIC-VN] to prevent version downgrade attacks. 154 Note that version 2 meets that document's definition of a compatible 155 version with version 1. Therefore, v2-capable servers MUST use 156 compatible version negotiation unless they do not support version 1. 158 As version 1 support is more likely than version 2 support, a client 159 SHOULD use QUIC version 1 for its original version unless it has out- 160 of-band knowledge that the server supports version 2. 162 5. Ossification Considerations 164 QUIC version 2 provides protection against some forms of 165 ossification. Devices that assume that all long headers will contain 166 encode version 1, or that the version 1 Initial key derivation 167 formula will remain version-invariant, will not correctly process 168 version 2 packets. 170 However, many middleboxes such as firewalls focus on the first packet 171 in a connection, which will often remain in the version 1 format due 172 to the considerations above. 174 Clients interested in combating firewall ossification can initiate a 175 connection using version 2 if they are either reasonably certain the 176 server supports it, or are willing to suffer a round-trip penalty if 177 they are incorrect. 179 6. Applicability 181 This version of QUIC provides no change from QUIC version 1 relating 182 to the capabilities available to applications. Therefore, all 183 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 184 specified to operate over QUICv1 can also operate over this version 185 of QUIC. 187 All QUIC extensions defined to work with version 1 also work with 188 version 2. 190 7. Security Considerations 192 QUIC version 2 introduces no changes to the security or privacy 193 properties of QUIC version 1. 195 The mandatory version negotiation mechanism guards against downgrade 196 attacks, but downgrades have no security implications, as the version 197 properties are identical. 199 8. IANA Considerations 201 This document requests that IANA add the following entry to the QUIC 202 version registry: 204 Value: TBD 206 Status: permanent 208 Specification: This Document 210 Change Controller: IETF 212 Contact: QUIC WG 214 9. References 216 9.1. Normative References 218 [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version 219 Negotiation for QUIC", Work in Progress, Internet-Draft, 220 draft-ietf-quic-version-negotiation-05, 25 October 2021, 221 . 224 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 225 Multiplexed and Secure Transport", RFC 9000, 226 DOI 10.17487/RFC9000, May 2021, 227 . 229 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 230 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 231 . 233 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 234 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 235 May 2021, . 237 9.2. Informative References 239 [I-D.duke-quic-version-aliasing] 240 Duke, M., "QUIC Version Aliasing", Work in Progress, 241 Internet-Draft, draft-duke-quic-version-aliasing-07, 25 242 October 2021, . 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 251 "Transport Layer Security (TLS) Application-Layer Protocol 252 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 253 July 2014, . 255 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 256 RFC 8999, DOI 10.17487/RFC8999, May 2021, 257 . 259 Appendix A. Changelog 261 *RFC Editor's Note:* Please remove this section prior to 262 publication of a final version of this document. 264 A.1. since draft-duke-quic-v2-02 266 * Converted to adopted draft 268 * Deleted references to QUIC improvements 270 * Clarified status of QUIC extensions 272 A.2. since draft-duke-quic-v2-01 274 * Made the final version number TBD. 276 * Added ALPN considerations 278 A.3. since draft-duke-quic-v2-00 280 * Added provisional versions for interop 282 * Change the v1 Retry Tag secret 284 * Change labels to create full key separation 286 Author's Address 288 Martin Duke 289 F5, Inc. 291 Email: martin.h.duke@gmail.com