QUIC Version 2
draft-duke-quic-v2-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Martin Duke | ||
| Last updated | 2021-04-26 | ||
| Replaced by | draft-ietf-quic-v2, RFC 9369 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-duke-quic-v2-01
QUIC M. Duke
Internet-Draft F5 Networks, Inc.
Intended status: Standards Track 26 April 2021
Expires: 28 October 2021
QUIC Version 2
draft-duke-quic-v2-01
Abstract
This document specifies QUIC version 2, which is identical to QUIC
version 1 except for some trivial details. Its purpose is to combat
various ossification vectors and exercise the version negotiation
framework. Over time, it may also serve as a vehicle for needed
protocol design changes.
Discussion of this work is encouraged to happen on the QUIC IETF
mailing list quic@ietf.org or on the GitHub repository which contains
the draft: https://github.com/martinduke/draft-duke-quic-v2.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 October 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Duke Expires 28 October 2021 [Page 1]
Internet-Draft QUICv2 April 2021
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 3
4. Version Negotiation Considerations . . . . . . . . . . . . . 4
5. Ossification Considerations . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6
A.1. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
QUIC [QUIC-TRANSPORT] has numerous extension points, including the
version number that occupies the second through fifth octets of every
long header (see [I-D.ietf-quic-invariants]). If experimental
versions lower in frequency, and QUIC version 1 constitutes the vast
majority of QUIC traffic, there is the potential for middleboxes to
ossify on the version octets always being 0x00000001.
Furthermore, version 1 Initial packets are encrypted with keys
derived from a universally known salt, which allow observers to
inspect the contents of these packets, which include the TLS Client
Hello and Server Hello messages. Again, middleboxes may ossify on
the version 1 key derivation and packet formats.
Finally [QUIC-VN] provides two mechanisms for endpoints to negotiate
the QUIC version to use. The "incompatible" version negotiation
method can support switching from any initial QUIC version to any
other version with full generality, at the cost of an additional
round-trip at the start of the connection. "Compatible" version
negotiation eliminates the round-trip penalty but levies some
restrictions on how much the two versions can differ semantically.
Duke Expires 28 October 2021 [Page 2]
Internet-Draft QUICv2 April 2021
QUIC version 2 is meant to mitigate ossification concerns and
exercise the version negotiation mechanisms. The only change is a
tweak to the inputs of some crypto derivation functions to enforce
full key separation. Any endpoint that supports two versions needs
to implement version negotiation to protect against downgrade
attacks.
This document may, over time, also serve as a vehicle for other
needed changes to QUIC version 1.
[I-D.duke-quic-version-aliasing] is a more robust, but much more
complicated, proposal to address these ossification problems. By
design, it requires incompatible version negotiation. QUICv2 enables
exercise of compatible version negotiation mechanism.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Changes from QUIC Version 1
QUIC version 2 endpoints MUST implement the QUIC version 1
specification as described in [QUIC-TRANSPORT], [I-D.ietf-quic-tls],
and [I-D.ietf-quic-recovery], with the following changes:
* The version field of long headers is 0x00000002. Note: Unless
this document is published as an RFC, implementations should use
the provisional value 0xff010001, which might change with each
edition of this document.
* The salt used to derive Initial keys in Sec 5.2 of
[I-D.ietf-quic-tls] changes to
initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3
* The labels used in [I-D.ietf-quic-tls] to derive packet protection
keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity
Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic
key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic
hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku," to meet the
guidance for new versions in Section 9.6 of that document.
* The key and nonce used for the Retry Integrity Tag (Sec 5.8 of
[I-D.ietf-quic-tls] change to:
Duke Expires 28 October 2021 [Page 3]
Internet-Draft QUICv2 April 2021
secret = 0x3425c20cf88779df2ff71e8abfa78249891e763bbed2f13c048343d348c060e2
key = 0xba858dc7b43de5dbf87617ff4ab253db
nonce = 0x141b99c239b03e785d6a2e9f
4. Version Negotiation Considerations
QUIC version 2 endpoints SHOULD also support QUIC version 1. Any
QUIC endpoint that supports multiple versions MUST fully implement
[QUIC-VN] to prevent version downgrade attacks.
Note that version 2 meets that document's definition of a compatible
version with version 1. Therefore, v2-capable servers MUST use
compatible version negotiation unless they do not support version 1.
As version 1 support is more likely than version 2 support, a client
SHOULD use QUIC version 1 for its original version unless it has out-
of-band knowledge that the server supports version 2.
5. Ossification Considerations
QUIC version 2 provides protection against some forms of
ossification. Devices that assume that all long headers will contain
encode version 1, or that the version 1 Initial key derivation
formula will remain version-invariant, will not correctly process
version 2 packets.
However, many middleboxes such as firewalls focus on the first packet
in a connection, which will often remain in the version 1 format due
to the considerations above.
Clients interested in combating firewall ossification can initiate a
connection using version 2 if they are either reasonably certain the
server supports it, or are willing to suffer a round-trip penalty if
they are incorrect.
6. Security Considerations
QUIC version 2 introduces no changes to the security or privacy
properties of QUIC version 1.
The mandatory version negotiation mechanism guards against downgrade
attacks, but downgrades have no security implications, as the version
properties are identical.
7. IANA Considerations
This document requests that IANA add the following entry to the QUIC
version registry:
Duke Expires 28 October 2021 [Page 4]
Internet-Draft QUICv2 April 2021
Value: 0x00000002
Status: permanent
Specification: This Document
Change Controller: IETF
Contact: QUIC WG
8. References
8.1. Normative References
[I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-34, 14 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
recovery-34.txt>.
[I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-tls-34,
14 January 2021, <http://www.ietf.org/internet-drafts/
draft-ietf-quic-tls-34.txt>.
[QUIC-TRANSPORT]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-34.txt>.
[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version
Negotiation for QUIC", Work in Progress, Internet-Draft,
draft-ietf-quic-version-negotiation-02, 2 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
version-negotiation-02.txt>.
8.2. Informative References
[I-D.duke-quic-version-aliasing]
Duke, M., "QUIC Version Aliasing", Work in Progress,
Internet-Draft, draft-duke-quic-version-aliasing-04, 30
October 2020, <http://www.ietf.org/internet-drafts/draft-
duke-quic-version-aliasing-04.txt>.
Duke Expires 28 October 2021 [Page 5]
Internet-Draft QUICv2 April 2021
[I-D.ietf-quic-invariants]
Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-13, 14 January 2021, <http://www.ietf.org/
internet-drafts/draft-ietf-quic-invariants-13.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Appendix A. Changelog
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
A.1. since draft-duke-quic-v2-00
* Added provisional versions for interop
* Change the v1 Retry Tag secret
* Change labels to create full key separation
Author's Address
Martin Duke
F5 Networks, Inc.
Email: martin.h.duke@gmail.com
Duke Expires 28 October 2021 [Page 6]