idnits 2.17.1 draft-duke-quic-v2-02.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 (9 July 2021) is 1020 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-03 == Outdated reference: A later version (-10) exists of draft-duke-quic-version-aliasing-04 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 Networks, Inc. 4 Intended status: Standards Track 9 July 2021 5 Expires: 10 January 2022 7 QUIC Version 2 8 draft-duke-quic-v2-02 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. Over time, it may also serve as a vehicle for needed 16 protocol design changes. 18 Discussion of this work is encouraged to happen on the QUIC IETF 19 mailing list quic@ietf.org or on the GitHub repository which contains 20 the draft: https://github.com/martinduke/draft-duke-quic-v2. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the mailing list 27 (quic@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/quic/. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/martinduke/draft-duke-quic-v2. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 10 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 3 69 4. Version Negotiation Considerations . . . . . . . . . . . . . 4 70 5. Ossification Considerations . . . . . . . . . . . . . . . . . 4 71 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 9.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6 78 A.1. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 6 79 A.2. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 6 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 QUIC [RFC9000] has numerous extension points, including the version 85 number that occupies the second through fifth octets of every long 86 header (see [RFC8999]). If experimental versions are rare, and QUIC 87 version 1 constitutes the vast majority of QUIC traffic, there is the 88 potential for middleboxes to ossify on the version octets always 89 being 0x00000001. 91 Furthermore, version 1 Initial packets are encrypted with keys 92 derived from a universally known salt, which allow observers to 93 inspect the contents of these packets, which include the TLS Client 94 Hello and Server Hello messages. Again, middleboxes may ossify on 95 the version 1 key derivation and packet formats. 97 Finally [QUIC-VN] provides two mechanisms for endpoints to negotiate 98 the QUIC version to use. The "incompatible" version negotiation 99 method can support switching from any initial QUIC version to any 100 other version with full generality, at the cost of an additional 101 round-trip at the start of the connection. "Compatible" version 102 negotiation eliminates the round-trip penalty but levies some 103 restrictions on how much the two versions can differ semantically. 105 QUIC version 2 is meant to mitigate ossification concerns and 106 exercise the version negotiation mechanisms. The only change is a 107 tweak to the inputs of some crypto derivation functions to enforce 108 full key separation. Any endpoint that supports two versions needs 109 to implement version negotiation to protect against downgrade 110 attacks. 112 This document may, over time, also serve as a vehicle for other 113 needed changes to QUIC version 1. 115 [I-D.duke-quic-version-aliasing] is a more robust, but much more 116 complicated, proposal to address these ossification problems. By 117 design, it requires incompatible version negotiation. QUICv2 enables 118 exercise of compatible version negotiation mechanism. 120 2. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Changes from QUIC Version 1 128 QUIC version 2 endpoints MUST implement the QUIC version 1 129 specification as described in [RFC9000], [RFC9001], and [RFC9002], 130 with the following changes: 132 * The version field of long headers is TBD. Note: Unless this 133 document is published as an RFC, implementations should use the 134 provisional value 0xff010001, which might change with each edition 135 of this document. 137 * The salt used to derive Initial keys in Sec 5.2 of [RFC9001] 138 changes to 140 initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3 142 * The labels used in [RFC9001] to derive packet protection keys (Sec 143 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys 144 (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to 145 "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to 146 "quicv2 hp", and from "quic ku" to "quicv2 ku," to meet the 147 guidance for new versions in Section 9.6 of that document. 149 * The key and nonce used for the Retry Integrity Tag (Sec 5.8 of 150 [RFC9001]) change to: 152 secret = 0x3425c20cf88779df2ff71e8abfa78249891e763bbed2f13c048343d348c060e2 153 key = 0xba858dc7b43de5dbf87617ff4ab253db 154 nonce = 0x141b99c239b03e785d6a2e9f 156 4. Version Negotiation Considerations 158 QUIC version 2 endpoints SHOULD also support QUIC version 1. Any 159 QUIC endpoint that supports multiple versions MUST fully implement 160 [QUIC-VN] to prevent version downgrade attacks. 162 Note that version 2 meets that document's definition of a compatible 163 version with version 1. Therefore, v2-capable servers MUST use 164 compatible version negotiation unless they do not support version 1. 166 As version 1 support is more likely than version 2 support, a client 167 SHOULD use QUIC version 1 for its original version unless it has out- 168 of-band knowledge that the server supports version 2. 170 5. Ossification Considerations 172 QUIC version 2 provides protection against some forms of 173 ossification. Devices that assume that all long headers will contain 174 encode version 1, or that the version 1 Initial key derivation 175 formula will remain version-invariant, will not correctly process 176 version 2 packets. 178 However, many middleboxes such as firewalls focus on the first packet 179 in a connection, which will often remain in the version 1 format due 180 to the considerations above. 182 Clients interested in combating firewall ossification can initiate a 183 connection using version 2 if they are either reasonably certain the 184 server supports it, or are willing to suffer a round-trip penalty if 185 they are incorrect. 187 6. Applicability 189 This version of QUIC provides no change from QUIC version 1 relating 190 to the capabilities available to applications. Therefore, all 191 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 192 specified to operate over QUICv1 can also operate over this version 193 of QUIC. 195 7. Security Considerations 197 QUIC version 2 introduces no changes to the security or privacy 198 properties of QUIC version 1. 200 The mandatory version negotiation mechanism guards against downgrade 201 attacks, but downgrades have no security implications, as the version 202 properties are identical. 204 8. IANA Considerations 206 This document requests that IANA add the following entry to the QUIC 207 version registry: 209 Value: TBD 211 Status: permanent 213 Specification: This Document 215 Change Controller: IETF 217 Contact: QUIC WG 219 9. References 221 9.1. Normative References 223 [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version 224 Negotiation for QUIC", Work in Progress, Internet-Draft, 225 draft-ietf-quic-version-negotiation-03, 4 February 2021, 226 . 229 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 230 Multiplexed and Secure Transport", RFC 9000, 231 DOI 10.17487/RFC9000, May 2021, 232 . 234 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 235 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 236 . 238 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 239 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 240 May 2021, . 242 9.2. Informative References 244 [I-D.duke-quic-version-aliasing] 245 Duke, M., "QUIC Version Aliasing", Work in Progress, 246 Internet-Draft, draft-duke-quic-version-aliasing-04, 30 247 October 2020, . 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 256 "Transport Layer Security (TLS) Application-Layer Protocol 257 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 258 July 2014, . 260 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 261 RFC 8999, DOI 10.17487/RFC8999, May 2021, 262 . 264 Appendix A. Changelog 266 *RFC Editor's Note:* Please remove this section prior to 267 publication of a final version of this document. 269 A.1. since draft-duke-quic-v2-01 271 * Made the final version number TBD. 273 * Added ALPN considerations 275 A.2. since draft-duke-quic-v2-00 277 * Added provisional versions for interop 279 * Change the v1 Retry Tag secret 281 * Change labels to create full key separation 283 Author's Address 285 Martin Duke 286 F5 Networks, Inc. 288 Email: martin.h.duke@gmail.com