Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

David's WGLC comments #68

Merged
merged 2 commits into from
May 20, 2022
Merged

David's WGLC comments #68

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
489d6ff
David's WGLC comments
martinduke May 20, 2022
6f41b66
Update draft-ietf-quic-v2.md
martinduke May 20, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
24 changes: 10 additions & 14 deletions draft-ietf-quic-v2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,13 +36,8 @@ vectors and exercise the version negotiation framework. It also serves as a
template for the minimum changes in any future version of QUIC.

Note that "version 2" is an informal name for this proposal that indicates it
is the second standards-track QUIC version. The protocol specified here will
receive a version number other than 2 from IANA.

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/quicwg/quic-v2).
is the second standards-track QUIC version. The protocol specified here uses a
version number other than 2 in the wire image.

--- middle

Expand Down Expand Up @@ -80,13 +75,19 @@ needs to implement version negotiation to protect against downgrade attacks.
# Differences with QUIC Version 1

QUIC version 2 endpoints MUST implement the QUIC version 1 specification as
described in {{QUIC}}, {{QUIC-TLS}}, and {{!RFC9002}}. However, the following
differences apply in version 2.
described in {{QUIC}}, {{QUIC-TLS}}, and {{!QUIC-LOSSRECOVERY=RFC9002}}.
However, the following differences apply in version 2.

## Version Field

The Version field of long headers is 0x709a50c4.

> **RFC Editor's Note:** Please remove the sentence below prior to publication
> of a final version of this document.

This version number will not change in subsequent versions of this draft,
unless there is a behavior change that breaks compatibility.

## Long Header Packet Types

All version 2 long header packet types are different. The Type field values are:
Expand Down Expand Up @@ -187,11 +188,6 @@ version. An endpoint MUST drop packets using any other version. Endpoints have
no need to generate the keying material that would allow them to decrypt or
authenticate these packets.

If the server's version_information transport parameter does not contain a
Chosen Version field equivalent to the version in the server's Handshake packet
headers, the client MUST terminate the connection with a
VERSION_NEGOTIATION_ERROR.

The client MUST NOT send 0-RTT packets using the negotiated version, even after
processing a packet of that version from the server. Servers can apply original
version 0-RTT packets to a connection without additional considerations.
Expand Down