idnits 2.17.1 draft-duke-quic-v2-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 : ---------------------------------------------------------------------------- ** 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 (26 April 2021) is 1094 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-02 == 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 26 April 2021 5 Expires: 28 October 2021 7 QUIC Version 2 8 draft-duke-quic-v2-01 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 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 28 October 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 3 58 4. Version Negotiation Considerations . . . . . . . . . . . . . 4 59 5. Ossification Considerations . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 8.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6 66 A.1. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 QUIC [QUIC-TRANSPORT] has numerous extension points, including the 72 version number that occupies the second through fifth octets of every 73 long header (see [I-D.ietf-quic-invariants]). If experimental 74 versions lower in frequency, and QUIC version 1 constitutes the vast 75 majority of QUIC traffic, there is the potential for middleboxes to 76 ossify on the version octets always being 0x00000001. 78 Furthermore, version 1 Initial packets are encrypted with keys 79 derived from a universally known salt, which allow observers to 80 inspect the contents of these packets, which include the TLS Client 81 Hello and Server Hello messages. Again, middleboxes may ossify on 82 the version 1 key derivation and packet formats. 84 Finally [QUIC-VN] provides two mechanisms for endpoints to negotiate 85 the QUIC version to use. The "incompatible" version negotiation 86 method can support switching from any initial QUIC version to any 87 other version with full generality, at the cost of an additional 88 round-trip at the start of the connection. "Compatible" version 89 negotiation eliminates the round-trip penalty but levies some 90 restrictions on how much the two versions can differ semantically. 92 QUIC version 2 is meant to mitigate ossification concerns and 93 exercise the version negotiation mechanisms. The only change is a 94 tweak to the inputs of some crypto derivation functions to enforce 95 full key separation. Any endpoint that supports two versions needs 96 to implement version negotiation to protect against downgrade 97 attacks. 99 This document may, over time, also serve as a vehicle for other 100 needed changes to QUIC version 1. 102 [I-D.duke-quic-version-aliasing] is a more robust, but much more 103 complicated, proposal to address these ossification problems. By 104 design, it requires incompatible version negotiation. QUICv2 enables 105 exercise of compatible version negotiation mechanism. 107 2. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. Changes from QUIC Version 1 115 QUIC version 2 endpoints MUST implement the QUIC version 1 116 specification as described in [QUIC-TRANSPORT], [I-D.ietf-quic-tls], 117 and [I-D.ietf-quic-recovery], with the following changes: 119 * The version field of long headers is 0x00000002. Note: Unless 120 this document is published as an RFC, implementations should use 121 the provisional value 0xff010001, which might change with each 122 edition of this document. 124 * The salt used to derive Initial keys in Sec 5.2 of 125 [I-D.ietf-quic-tls] changes to 127 initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3 129 * The labels used in [I-D.ietf-quic-tls] to derive packet protection 130 keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity 131 Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic 132 key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic 133 hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku," to meet the 134 guidance for new versions in Section 9.6 of that document. 136 * The key and nonce used for the Retry Integrity Tag (Sec 5.8 of 137 [I-D.ietf-quic-tls] change to: 139 secret = 0x3425c20cf88779df2ff71e8abfa78249891e763bbed2f13c048343d348c060e2 140 key = 0xba858dc7b43de5dbf87617ff4ab253db 141 nonce = 0x141b99c239b03e785d6a2e9f 143 4. Version Negotiation Considerations 145 QUIC version 2 endpoints SHOULD also support QUIC version 1. Any 146 QUIC endpoint that supports multiple versions MUST fully implement 147 [QUIC-VN] to prevent version downgrade attacks. 149 Note that version 2 meets that document's definition of a compatible 150 version with version 1. Therefore, v2-capable servers MUST use 151 compatible version negotiation unless they do not support version 1. 153 As version 1 support is more likely than version 2 support, a client 154 SHOULD use QUIC version 1 for its original version unless it has out- 155 of-band knowledge that the server supports version 2. 157 5. Ossification Considerations 159 QUIC version 2 provides protection against some forms of 160 ossification. Devices that assume that all long headers will contain 161 encode version 1, or that the version 1 Initial key derivation 162 formula will remain version-invariant, will not correctly process 163 version 2 packets. 165 However, many middleboxes such as firewalls focus on the first packet 166 in a connection, which will often remain in the version 1 format due 167 to the considerations above. 169 Clients interested in combating firewall ossification can initiate a 170 connection using version 2 if they are either reasonably certain the 171 server supports it, or are willing to suffer a round-trip penalty if 172 they are incorrect. 174 6. Security Considerations 176 QUIC version 2 introduces no changes to the security or privacy 177 properties of QUIC version 1. 179 The mandatory version negotiation mechanism guards against downgrade 180 attacks, but downgrades have no security implications, as the version 181 properties are identical. 183 7. IANA Considerations 185 This document requests that IANA add the following entry to the QUIC 186 version registry: 188 Value: 0x00000002 190 Status: permanent 192 Specification: This Document 194 Change Controller: IETF 196 Contact: QUIC WG 198 8. References 200 8.1. Normative References 202 [I-D.ietf-quic-recovery] 203 Iyengar, J. and I. Swett, "QUIC Loss Detection and 204 Congestion Control", Work in Progress, Internet-Draft, 205 draft-ietf-quic-recovery-34, 14 January 2021, 206 . 209 [I-D.ietf-quic-tls] 210 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 211 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 212 14 January 2021, . 215 [QUIC-TRANSPORT] 216 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 217 and Secure Transport", Work in Progress, Internet-Draft, 218 draft-ietf-quic-transport-34, 14 January 2021, 219 . 222 [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version 223 Negotiation for QUIC", Work in Progress, Internet-Draft, 224 draft-ietf-quic-version-negotiation-02, 2 November 2020, 225 . 228 8.2. Informative References 230 [I-D.duke-quic-version-aliasing] 231 Duke, M., "QUIC Version Aliasing", Work in Progress, 232 Internet-Draft, draft-duke-quic-version-aliasing-04, 30 233 October 2020, . 236 [I-D.ietf-quic-invariants] 237 Thomson, M., "Version-Independent Properties of QUIC", 238 Work in Progress, Internet-Draft, draft-ietf-quic- 239 invariants-13, 14 January 2021, . 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, 244 DOI 10.17487/RFC2119, March 1997, 245 . 247 Appendix A. Changelog 249 *RFC Editor's Note:* Please remove this section prior to 250 publication of a final version of this document. 252 A.1. since draft-duke-quic-v2-00 254 * Added provisional versions for interop 256 * Change the v1 Retry Tag secret 258 * Change labels to create full key separation 260 Author's Address 262 Martin Duke 263 F5 Networks, Inc. 265 Email: martin.h.duke@gmail.com