draft-ietf-quic-v2-01.txt   draft-ietf-quic-v2-02.txt 
QUIC M. Duke QUIC M. Duke
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 22 January 2022 Intended status: Standards Track 28 April 2022
Expires: 26 July 2022 Expires: 30 October 2022
QUIC Version 2 QUIC Version 2
draft-ietf-quic-v2-01 draft-ietf-quic-v2-02
Abstract Abstract
This document specifies QUIC version 2, which is identical to QUIC This document specifies QUIC version 2, which is identical to QUIC
version 1 except for some trivial details. Its purpose is to combat version 1 except for some trivial details. Its purpose is to combat
various ossification vectors and exercise the version negotiation various ossification vectors and exercise the version negotiation
framework. It also serves as a template for the minimum changes in framework. It also serves as a template for the minimum changes in
any future version of QUIC. any future version of QUIC.
Note that "version 2" is an informal name for this proposal that Note that "version 2" is an informal name for this proposal that
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 July 2022. This Internet-Draft will expire on 30 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 4 3. Changes from QUIC Version 1 . . . . . . . . . . . . . . . . . 4
3.1. Version Field . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Version Field . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Long Header Packet Types . . . . . . . . . . . . . . . . 4 3.2. Long Header Packet Types . . . . . . . . . . . . . . . . 4
3.3. Cryptography changes . . . . . . . . . . . . . . . . . . 4 3.3. Cryptography changes . . . . . . . . . . . . . . . . . . 4
3.3.1. Initial Salt . . . . . . . . . . . . . . . . . . . . 4 3.3.1. Initial Salt . . . . . . . . . . . . . . . . . . . . 4
3.3.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . 4 3.3.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . 4
3.3.3. Retry Integrity Tag . . . . . . . . . . . . . . . . . 4 3.3.3. Retry Integrity Tag . . . . . . . . . . . . . . . . . 4
4. Version Negotiation Considerations . . . . . . . . . . . . . 5 4. Version Negotiation Considerations . . . . . . . . . . . . . 5
4.1. Compatible Negotiation Requirements . . . . . . . . . . . 5 4.1. Compatible Negotiation Requirements . . . . . . . . . . . 5
5. TLS Resumption . . . . . . . . . . . . . . . . . . . . . . . 6 5. TLS Resumption and NEW_TOKEN Tokens . . . . . . . . . . . . . 6
6. Ossification Considerations . . . . . . . . . . . . . . . . . 7 6. Ossification Considerations . . . . . . . . . . . . . . . . . 7
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 9 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 9
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 10 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 10
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 12 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 12
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 13 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 13
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 15
B.1. since draft-ietf-quic-v2-00 . . . . . . . . . . . . . . . 15 B.1. since draft-ietf-quic-v2-01 . . . . . . . . . . . . . . . 15
B.2. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 15 B.2. since draft-ietf-quic-v2-00 . . . . . . . . . . . . . . . 15
B.3. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 15 B.3. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 15
B.4. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 15 B.4. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 B.5. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
QUIC [QUIC] has numerous extension points, including the version QUIC [QUIC] has numerous extension points, including the version
number that occupies the second through fifth octets of every long number that occupies the second through fifth octets of every long
header (see [RFC8999]). If experimental versions are rare, and QUIC header (see [RFC8999]). If experimental versions are rare, and QUIC
version 1 constitutes the vast majority of QUIC traffic, there is the version 1 constitutes the vast majority of QUIC traffic, there is the
potential for middleboxes to ossify on the version octets always potential for middleboxes to ossify on the version octets always
being 0x00000001. being 0x00000001.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
maximize compatibility with clients. In particular, HTTP clients maximize compatibility with clients. In particular, HTTP clients
often use Alt-Svc [RFC7838] to discover QUIC support. As this often use Alt-Svc [RFC7838] to discover QUIC support. As this
mechanism does not currently distinguish between QUIC versions, HTTP mechanism does not currently distinguish between QUIC versions, HTTP
servers that support multiple versions reduce the probability of servers that support multiple versions reduce the probability of
incompatibility and the cost associated with QUIC version negotiation incompatibility and the cost associated with QUIC version negotiation
or TCP fallback. For example, an origin advertising support for "h3" or TCP fallback. For example, an origin advertising support for "h3"
in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC
version used by HTTP/3 and therefore some clients will only support version used by HTTP/3 and therefore some clients will only support
that version. that version.
Any QUIC endpoint that supports multiple versions MUST meet the Any QUIC endpoint that supports QUIC version 2 MUST send, process,
minimum requirements described in [QUIC-VN] to prevent version and validate the version_information transport parameter specified in
downgrade attacks. [QUIC-VN] to prevent version downgrade attacks.
Note that version 2 meets that document's definition of a compatible Note that version 2 meets that document's definition of a compatible
version with version 1. Therefore, servers can use compatible version with version 1, and version 1 is compatible with version 2.
negotiation to switch a connection between the two versions. Therefore, servers can use compatible negotiation to switch a
Endpoints that support both versions SHOULD support compatible connection between the two versions. Endpoints that support both
version negotiation to avoid a round trip. versions SHOULD support compatible version negotiation to avoid a
round trip.
4.1. Compatible Negotiation Requirements 4.1. Compatible Negotiation Requirements
Compatible version negotiation between versions 1 and 2 follow the Compatible version negotiation between versions 1 and 2 follow the
same requirements in either direction. This section uses the terms same requirements in either direction. This section uses the terms
"original version" and "negotiated version" from [QUIC-VN]. "original version" and "negotiated version" from [QUIC-VN].
If the server sends a Retry packet, it MUST use the original version. If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions. The client The client ignores Retry packets using other versions. The client
MUST NOT use a different version in the subsequent Initial that MUST NOT use a different version in the subsequent Initial that
skipping to change at page 6, line 39 skipping to change at page 6, line 39
If the server's version_information transport parameter does not If the server's version_information transport parameter does not
contain a Chosen Version field equivalent to the version in the contain a Chosen Version field equivalent to the version in the
server's Handshake packet headers, the client MUST terminate the server's Handshake packet headers, the client MUST terminate the
connection with a VERSION_NEGOTIATION_ERROR. connection with a VERSION_NEGOTIATION_ERROR.
The client MUST NOT send 0-RTT packets using the negotiated version, The client MUST NOT send 0-RTT packets using the negotiated version,
even after processing a packet of that version from the server. even after processing a packet of that version from the server.
Servers can apply original version 0-RTT packets to a connection Servers can apply original version 0-RTT packets to a connection
without additional considerations. without additional considerations.
5. TLS Resumption 5. TLS Resumption and NEW_TOKEN Tokens
TLS session tickets are specific to the QUIC version of the TLS session tickets and NEW_TOKEN tokens are specific to the QUIC
connection that provided them. Clients MUST NOT use a session ticket version of the connection that provided them. Clients SHOULD NOT use
from a QUICv1 connection to initiate a QUICv2 connection, or vice a session ticket or token from a QUICv1 connection to initiate a
versa. QUICv2 connection, or vice versa.
Servers SHOULD validate the originating version of any session ticket Servers MUST validate the originating version of any session ticket
and not resume from any ticket issued from a different version. This or token and not accept one issued from a different version. A
results in falling back to a full TLS handshake, without 0-RTT. rejected ticket results in falling back to a full TLS handshake,
without 0-RTT. A rejected token results in the client address
remaining unverified, which limits the amount of data the server can
send.
After compatible version negotiation, any resulting session ticket After compatible version negotiation, any resulting session ticket
maps to the negotiated version rather than original one. maps to the negotiated version rather than original one.
6. Ossification Considerations 6. Ossification Considerations
QUIC version 2 provides protection against some forms of QUIC version 2 provides protection against some forms of
ossification. Devices that assume that all long headers will contain ossification. Devices that assume that all long headers will contain
encode version 1, or that the version 1 Initial key derivation encode version 1, or that the version 1 Initial key derivation
formula will remain version-invariant, will not correctly process formula will remain version-invariant, will not correctly process
skipping to change at page 7, line 28 skipping to change at page 7, line 31
connection using version 2 if they are either reasonably certain the connection using version 2 if they are either reasonably certain the
server supports it, or are willing to suffer a round-trip penalty if server supports it, or are willing to suffer a round-trip penalty if
they are incorrect. they are incorrect.
7. Applicability 7. Applicability
This version of QUIC provides no change from QUIC version 1 relating This version of QUIC provides no change from QUIC version 1 relating
to the capabilities available to applications. Therefore, all to the capabilities available to applications. Therefore, all
Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints
specified to operate over QUICv1 can also operate over this version specified to operate over QUICv1 can also operate over this version
of QUIC. of QUIC. In particular, both the "h3" [I-D.ietf-quic-http] and "doq"
[I-D.ietf-dprive-dnsoquic] ALPNs can operate over QUICv2.
All QUIC extensions defined to work with version 1 also work with All QUIC extensions defined to work with version 1 also work with
version 2. version 2.
8. Security Considerations 8. Security Considerations
QUIC version 2 introduces no changes to the security or privacy QUIC version 2 introduces no changes to the security or privacy
properties of QUIC version 1. properties of QUIC version 1.
The mandatory version negotiation mechanism guards against downgrade The mandatory version negotiation mechanism guards against downgrade
skipping to change at page 8, line 23 skipping to change at page 8, line 27
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/rfc/rfc9000>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>. <https://www.rfc-editor.org/rfc/rfc9001>.
[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version
Negotiation for QUIC", Work in Progress, Internet-Draft, Negotiation for QUIC", Work in Progress, Internet-Draft,
draft-ietf-quic-version-negotiation-05, 25 October 2021, draft-ietf-quic-version-negotiation-07, 5 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
version-negotiation-05>. version-negotiation-07>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
10.2. Informative References 10.2. Informative References
[I-D.duke-quic-version-aliasing] [I-D.duke-quic-version-aliasing]
Duke, M., "QUIC Version Aliasing", Work in Progress, Duke, M., "QUIC Version Aliasing", Work in Progress,
Internet-Draft, draft-duke-quic-version-aliasing-07, 25 Internet-Draft, draft-duke-quic-version-aliasing-07, 25
October 2021, <https://datatracker.ietf.org/doc/html/ October 2021, <https://datatracker.ietf.org/doc/html/
draft-duke-quic-version-aliasing-07>. draft-duke-quic-version-aliasing-07>.
[I-D.ietf-dprive-dnsoquic]
Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", Work in Progress, Internet-
Draft, draft-ietf-dprive-dnsoquic-12, 20 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-dprive-
dnsoquic-12>.
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
The protected packet is the smallest possible packet size of 21 The protected packet is the smallest possible packet size of 21
bytes. bytes.
packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba
Appendix B. Changelog Appendix B. Changelog
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
B.1. since draft-ietf-quic-v2-00 B.1. since draft-ietf-quic-v2-01
* Ban use of NEW_TOKEN tokens across versions
* version-info transport parameter required for all v2 endpoints
* Explicitly list known ALPN compatibility
B.2. since draft-ietf-quic-v2-00
* Expanded requirements for compatible version negotiation * Expanded requirements for compatible version negotiation
* Added test vectors * Added test vectors
* Greased the packet type codepoints * Greased the packet type codepoints
* Random version number * Random version number
* Clarified requirement to use QUIC-VN * Clarified requirement to use QUIC-VN
* Banned use of resumption tokens across versions * Banned use of resumption tokens across versions
B.2. since draft-duke-quic-v2-02 B.3. since draft-duke-quic-v2-02
* Converted to adopted draft * Converted to adopted draft
* Deleted references to QUIC improvements * Deleted references to QUIC improvements
* Clarified status of QUIC extensions * Clarified status of QUIC extensions
B.3. since draft-duke-quic-v2-01 B.4. since draft-duke-quic-v2-01
* Made the final version number TBD. * Made the final version number TBD.
* Added ALPN considerations * Added ALPN considerations
B.4. since draft-duke-quic-v2-00 B.5. since draft-duke-quic-v2-00
* Added provisional versions for interop * Added provisional versions for interop
* Change the v1 Retry Tag secret * Change the v1 Retry Tag secret
* Change labels to create full key separation * Change labels to create full key separation
Author's Address Author's Address
Martin Duke Martin Duke
 End of changes. 18 change blocks. 
32 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/