< draft-duke-quic-version-aliasing-07.txt   draft-duke-quic-version-aliasing-08.txt >
QUIC M. Duke QUIC M. Duke
Internet-Draft F5 Networks, Inc. Internet-Draft Google
Intended status: Experimental 25 October 2021 Intended status: Experimental 28 April 2022
Expires: 28 April 2022 Expires: 30 October 2022
QUIC Version Aliasing QUIC Version Aliasing
draft-duke-quic-version-aliasing-07 draft-duke-quic-version-aliasing-08
Abstract Abstract
The QUIC transport protocol preserves its future extensibility partly The QUIC transport protocol preserves its future extensibility partly
by specifying its version number. There will be a relatively small by specifying its version number. There will be a relatively small
number of published version numbers for the foreseeable future. This number of published version numbers for the foreseeable future. This
document provides a method for clients and servers to negotiate the document provides a method for clients and servers to negotiate the
use of other version numbers in subsequent connections and encrypts use of other version numbers in subsequent connections and encrypts
Initial Packets using secret keys instead of standard ones. If a Initial Packets using secret keys instead of standard ones. If a
sizeable subset of QUIC connections use this mechanism, this should sizeable subset of QUIC connections use this mechanism, this should
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 28 April 2022. This Internet-Draft will expire on 30 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Relationship to ECH and QUIC Protected Initials . . . . . 5 2.1. Relationship to ECH and QUIC Protected Initials . . . . . 6
3. The Version Alias Transport Parameter . . . . . . . . . . . . 6 3. The Version Alias Transport Parameter . . . . . . . . . . . . 7
3.1. Version Number Generation . . . . . . . . . . . . . . . . 7 3.1. Aliased Version Number Generation . . . . . . . . . . . . 7
3.2. Initial Token Extension (ITE) Generation . . . . . . . . 7 3.2. Initial Token Extension (ITE) Generation . . . . . . . . 7
3.3. Salt and Packet Length Offset Generation . . . . . . . . 8 3.3. Salt and Packet Length Offset Generation . . . . . . . . 8
3.4. Expiration Time . . . . . . . . . . . . . . . . . . . . . 8 3.4. Packet Type Generation . . . . . . . . . . . . . . . . . 8
3.5. Format . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Standard Version Number . . . . . . . . . . . . . . . . . 9
3.6. Multiple Servers for One Domain . . . . . . . . . . . . . 10 3.6. Expiration Time . . . . . . . . . . . . . . . . . . . . . 9
3.7. Multiple Entities With One Load Balancer . . . . . . . . 10 3.7. Format . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Multiple Servers for One Domain . . . . . . . . . . . . . 11
4.1. The aliasing_parameters Transport Parameter . . . . . . . 12 3.9. Multiple Entities With One Load Balancer . . . . . . . . 11
5. Server Actions on Aliased Version Numbers . . . . . . . . . . 12 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. The aliasing_parameters Transport Parameter . . . . . . . 13
6.1. Bad Salt Packets . . . . . . . . . . . . . . . . . . . . 14 5. Server Actions on Aliased Version Numbers . . . . . . . . . . 14
6.2. Client Response to Bad Salt . . . . . . . . . . . . . . . 15 6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Server Response to version_aliasing Transport 6.1. Bad Salt Packets . . . . . . . . . . . . . . . . . . . . 15
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Client Response to Bad Salt . . . . . . . . . . . . . . . 17
7. Considerations for Retry Packets . . . . . . . . . . . . . . 16 6.3. version_aliasing_fallback Transport Parameter . . . . . . 17
8. Security and Privacy Considerations . . . . . . . . . . . . . 17 6.4. Server Response to version_aliasing_fallback Transport
8.1. Endpoint Impersonation . . . . . . . . . . . . . . . . . 17 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. First-Connection Privacy . . . . . . . . . . . . . . . . 17 7. Considerations for Retry Packets . . . . . . . . . . . . . . 19
8.3. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 18 8. Security and Privacy Considerations . . . . . . . . . . . . . 19
8.4. Initial Packet Injection . . . . . . . . . . . . . . . . 18 8.1. Endpoint Impersonation . . . . . . . . . . . . . . . . . 19
8.5. Retry Injection . . . . . . . . . . . . . . . . . . . . . 18 8.2. First-Connection Privacy . . . . . . . . . . . . . . . . 20
8.6. Increased Linkability . . . . . . . . . . . . . . . . . . 19 8.3. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 20
8.7. Salt Polling . . . . . . . . . . . . . . . . . . . . . . 19 8.4. Initial Packet Injection . . . . . . . . . . . . . . . . 21
8.8. Server Fingerprinting . . . . . . . . . . . . . . . . . . 20 8.5. Retry Injection . . . . . . . . . . . . . . . . . . . . . 21
8.9. Increased Processing of Garbage UDP Packets . . . . . . . 20 8.6. Increased Linkability . . . . . . . . . . . . . . . . . . 22
8.10. Increased Retry Overhead . . . . . . . . . . . . . . . . 21 8.7. Salt Polling . . . . . . . . . . . . . . . . . . . . . . 22
8.11. Request Forgery . . . . . . . . . . . . . . . . . . . . . 21 8.8. Server Fingerprinting . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.9. Increased Processing of Garbage UDP Packets . . . . . . . 23
9.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 21 8.10. Increased Retry Overhead . . . . . . . . . . . . . . . . 23
9.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 21 8.11. Request Forgery . . . . . . . . . . . . . . . . . . . . . 23
9.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 22 9.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
B.1. since draft-duke-quic-version-aliasing-05 . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 25
B.2. since draft-duke-quic-version-aliasing-04 . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25
B.3. since draft-duke-quic-version-aliasing-03 . . . . . . . . 23 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
B.4. since draft-duke-quic-version-aliasing-02 . . . . . . . . 23 B.1. since draft-duke-quic-version-aliasing-07 . . . . . . . . 25
B.5. since draft-duke-quic-version-aliasing-01 . . . . . . . . 23 B.2. since draft-duke-quic-version-aliasing-05 . . . . . . . . 26
B.6. since draft-duke-quic-version-aliasing-00 . . . . . . . . 23 B.3. since draft-duke-quic-version-aliasing-04 . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. since draft-duke-quic-version-aliasing-03 . . . . . . . . 26
B.5. since draft-duke-quic-version-aliasing-02 . . . . . . . . 26
B.6. since draft-duke-quic-version-aliasing-01 . . . . . . . . 26
B.7. since draft-duke-quic-version-aliasing-00 . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The QUIC version number is critical to future extensibility of the The QUIC version number is critical to future extensibility of the
protocol ([RFC9000]). Past experience with other protocols, such as protocol ([RFC9000]). Past experience with other protocols, such as
TLS1.3 [RFC8446], shows that middleboxes might attempt to enforce TLS1.3 [RFC8446], shows that middleboxes might attempt to enforce
that QUIC packets use versions known at the time the middlebox was that QUIC packets use versions known at the time the middlebox was
implemented. This deters deployment of experimental and standard implemented. This deters deployment of experimental and standard
versions on the internet. versions on the internet.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119. interpreted as carrying significance described in RFC 2119.
A "standard version" is a QUIC version that would be advertised in a A "standard version" is a QUIC version that would be advertised in a
QUIC version negotiation and conforms to a specification. Any QUIC version negotiation and conforms to a specification. Any
aliased version corresponds to a standard version in all its formats aliased version corresponds to a standard version in all its formats
and behaviors, except for the version number field in long headers. and behaviors, except for the version number field in long headers.
To be compatible with version aliasing, the first client packet in a To be compatible with version aliasing, there MUST be no more than
standard version MUST encode the packet type and token as if it were four long header packet types, and the first client packet in a
a QUIC version 1 initial packet. That is: standard version MUST encode the token as if it were a QUIC version 1
initial packet. That is:
* The most significant bit MUST be 1. * The most significant bit MUST be 1.
* The third and fourth most significant bits MUST be zero.
* The first field after the Source Connection ID MUST be a variable- * The first field after the Source Connection ID MUST be a variable-
length integer including the length of a token. length integer including the length of a token.
* The second field after the Destination Connection ID MUST be a * The second field after the Destination Connection ID MUST be a
field, with length indicated by the previous field, that contains field, with length indicated by the previous field, that contains
opaque data generated by the server. opaque data generated by the server.
* There must be a variable-length integer that encodes the packet * There must be a variable-length integer that encodes the packet
length, unprotected in the header. length, unprotected in the header.
An "aliased version" is a version with a number generated in An "aliased version" is a version with a number generated in
accordance with this document. Except for the version field in long accordance with this document. Except for the version field in long
headers, it conforms entirely to the specification of the standard headers, it conforms entirely to the specification of the standard
version. version.
2. Protocol Overview 2. Protocol Overview
When they instantiate a connection, servers select an alternate When they instantiate a connection, servers select an alternate
32-bit version number, and optionally an initial token extension, for 32-bit version number, and optionally an initial token extension, for
the next connection at random and securely derive a salt and Packet the next connection at random and securely derive a salt, packet
Length Offset from those values using a repeatable process. They Length Offset, and long header packet type codepoints from those
communicate this using a transport parameter extension including the values using a repeatable process. They communicate this using a
version, initial token extension, salt, Packet Length Offset, and an transport parameter extension including the version, initial token
expiration time for that value. extension, Initial salt, Packet Length Offset, packet type
codepoints, and an expiration time for that value.
If a client next connects to that server within the indicated If a client next connects to that server within the indicated
expiration time, it MAY use the provided version number and encrypt expiration time, it MAY use the provided version number and encrypt
its Initial Packets using a key derived from the provided salt. It its Initial Packets using a key derived from the provided salt. It
adds the Packet Length Offset to the true packet length when encoding uses the provided Initial packet codepoint. It adds the Packet
it in the long header. If the server provided an Initial Token Length Offset to the true packet length when encoding it in the long
Extension, the client puts it in the Initial Packet token field. If header. If the server provided an Initial Token Extension, the
there is another token the client wishes to include, it appends the client puts it in the Initial Packet token field. If there is
Initial Token Extension to that token. The server can reconstruct another token the client wishes to include, it appends the Initial
the salt and Packet Length Offset from the requested version and Token Extension to that token. The server can reconstruct the salt
token, and proceed with the connection normally. and Packet Length Offset from the requested version and token, and
proceed with the connection normally.
The Packet Length Offset provides a low-cost way for the server to The Packet Length Offset provides a low-cost way for the server to
verify it can derive a valid salt from the inputs without trial verify it can derive a valid salt from the inputs without trial
decryption. This has important security implications, as described decryption. This has important security implications, as described
in Section 8.5. in Section 8.5.
When generating a salt and Packet Length Offset, servers can choose When generating a salt and Packet Length Offset, servers can choose
between doing so randomly and storing the mapping, or using a between doing so randomly and storing the mapping, or using a
cryptographic process to transform the aliased version number and cryptographic process to transform the aliased version number and
token extension into the salt. The two options provide a simple token extension into the salt. The two options provide a simple
tradeoff between computational complexity and storage requirements. tradeoff between computational complexity and storage requirements.
Long header packets are composed identically to their standard
version, except that they use the provided packet type codepoint,
version number, and packet length offset. Initial packets
additionally use any provided token extension and are encrypted as
described below.
Short header packets are unchanged when using this extension.
2.1. Relationship to ECH and QUIC Protected Initials 2.1. Relationship to ECH and QUIC Protected Initials
The TLS Encrypted Client Hello [ECHO] shares some goals with this The TLS Encrypted Client Hello [ECHO] shares some goals with this
document. It encodes an "inner" encrypted Client Hello in a TLS document. It encodes an "inner" encrypted Client Hello in a TLS
extension in an "outer" Client Hello. The encryption uses asymmetric extension in an "outer" Client Hello. The encryption uses asymmetric
keys with the server's public key distributed via an out-of-band keys with the server's public key distributed via an out-of-band
mechanism like DNS. The inner Client Hello contains any privacy- mechanism like DNS. The inner Client Hello contains any privacy-
sensitive information and is only readable with the server's private sensitive information and is only readable with the server's private
key. key.
skipping to change at page 7, line 4 skipping to change at page 7, line 20
not greasing the version field. not greasing the version field.
A maximally privacy-protecting client might use Protected Initials A maximally privacy-protecting client might use Protected Initials
for any connection attempts for which it does not have an unexpired for any connection attempts for which it does not have an unexpired
aliased version, and QUIC version aliasing otherwise. aliased version, and QUIC version aliasing otherwise.
See also section 1.1 of [QUIC-PI] for further discussion of See also section 1.1 of [QUIC-PI] for further discussion of
tradeoffs. tradeoffs.
3. The Version Alias Transport Parameter 3. The Version Alias Transport Parameter
3.1. Version Number Generation
3.1. Aliased Version Number Generation
Servers MUST use a random process to generate version numbers. This Servers MUST use a random process to generate version numbers. This
version number MUST NOT correspond to a QUIC version the server version number MUST NOT correspond to a QUIC version the server
advertises in QUIC Version Negotiation packets or transport advertises in QUIC Version Negotiation packets or transport
parameters. Servers SHOULD also exclude version numbers used in parameters. Servers SHOULD also exclude version numbers used in
known specifications or experiments to avoid confusion at clients, known specifications or experiments to avoid confusion at clients,
whether or not they have plans to support those specifications. whether or not they have plans to support those specifications.
Servers MAY use version numbers reserved for grease in Section 15.1 Servers MAY use version numbers reserved for grease in Section 15.1
of [RFC9000], even though they might be advertised in Version of [RFC9000], even though they might be advertised in Version
skipping to change at page 7, line 35 skipping to change at page 8, line 5
Servers SHOULD generate an Initial Token Extension (ITE) to provide Servers SHOULD generate an Initial Token Extension (ITE) to provide
additional entropy in salt generation. Two clients that receive the additional entropy in salt generation. Two clients that receive the
same version number but different extensions will not be able to same version number but different extensions will not be able to
decode each other's Initial Packets. decode each other's Initial Packets.
Servers MAY choose any length that will allow client Initial Packets Servers MAY choose any length that will allow client Initial Packets
to fit within the minimum QUIC packet size of 1200 octets. A four- to fit within the minimum QUIC packet size of 1200 octets. A four-
octet extension is RECOMMENDED. The ITE MUST appear to be random to octet extension is RECOMMENDED. The ITE MUST appear to be random to
observers. observers.
If a server supports multiple standard versions, it MUST either
encode the standard version of the current connection in the ITE or
store it in a lookup table.
If the server chooses to encode the standard version, it MUST be
cryptographically protected.
Encoded standard versions MUST be robust to false positives. That
is, if decoded with a new key, the version encoding must return as
invalid, rather than an incorrect value.
Alternatively, servers MAY store a mapping of unexpired aliased
versions and ITEs to standard versions. This mapping SHOULD NOT
create observable patterns, e.g. one plaintext bit indicates if the
standard version is 1 or 2.
The server MUST be able to distinguish ITEs from Resumption and Retry The server MUST be able to distinguish ITEs from Resumption and Retry
tokens in incoming Initial Packets that contain an aliased version tokens in incoming Initial Packets that contain an aliased version
number. As the server controls the lengths and encoding of each, number. As the server controls the lengths and encoding of each,
there are many ways to guarantee this. there are many ways to guarantee this.
3.3. Salt and Packet Length Offset Generation 3.3. Salt and Packet Length Offset Generation
The salt is an opaque 20-octet field. It is used to generate Initial The salt is an opaque 20-octet field. It is used to generate Initial
connection keys using the process described in [RFC9001]. connection keys using the process described in [RFC9001].
The Packet Length Offset is a 64-bit unsigned integer with a maximum The Packet Length Offset is a 64-bit unsigned integer with a maximum
value of 2^62 - 1. Clients MUST ignore a transport parameter with a value of 2^62 - 1.
value that exceeds this limit.
To reduce header overhead, servers MAY consistently use a Packet To reduce header overhead, servers MAY consistently use a Packet
Length Offset of zero if and only if it either (1) never sends Retry Length Offset of zero if and only if it either (1) never sends Retry
packets, or (2) can guarantee, through the use of persistent storage packets, or (2) can guarantee, through the use of persistent storage
or other means, that it will never lose the cryptographic state or other means, that it will never lose the cryptographic state
required to generate the salt before the promised expiration time. required to generate the salt before the promised expiration time.
Section 8.5 describes the implications if it uses zero without Section 8.5 describes the implications if it uses zero without
meeting these conditions. meeting these conditions.
Servers MUST either generate a random salt and Packet Length Offset Servers MUST either generate a random salt and Packet Length Offset
skipping to change at page 8, line 39 skipping to change at page 8, line 38
generate the salt and offset using a cryptographic method that uses generate the salt and offset using a cryptographic method that uses
the version number, ITE, and only server state that is persistent the version number, ITE, and only server state that is persistent
across connections. across connections.
If the latter, servers MUST implement a method that it can repeat If the latter, servers MUST implement a method that it can repeat
deterministically at a later time to derive the salt and offset from deterministically at a later time to derive the salt and offset from
the incoming version number and ITE. It MUST NOT use client the incoming version number and ITE. It MUST NOT use client
controlled information other than the version number and ITE; for controlled information other than the version number and ITE; for
example, the client's IP address and port. example, the client's IP address and port.
3.4. Expiration Time 3.4. Packet Type Generation
The server generates the packet type codepoint for each of the four
long header packet types (Initial, 0RTT, Handshake, and Retry). Each
of these codepoints is two bits.
Future versions of QUIC with 4 or fewer long header packet types can
specify a mapping of these fields to their types.
Note that the server needs to derive the type codepoints solely from
the version number. It cannot extract the token, and the token
extension, until the packet is identified as an Initial packet.
A straightforward implementation might take arbitrary bits from a
hash of the version number. The first two bits it reads are the
codepoint for Initial packets. The next pair of bits that is not a
duplicate of the first is the codepoint for 0RTT packets. The next
pair that does not duplicate the first two is the codepoint for
Handshake packets, and the remaining codepoint is the Retry packet.
3.5. Standard Version Number
Servers also specify the Standard version that the client should use
to guide the wire formats and behaviors of the aliased version. This
version MUST meet the criteria to support version aliasing, and MUST
either be included as a supported version in the client's
version_information transport parameter (see
[I-D.ietf-quic-version-negotiation]) or be the standard version of
the current connection.
Note that servers MUST NOT accept resumption tickets or NEW_TOKEN
tokens from different standard versions. Therefore, the choice of
standard version might impact the performance of the connection that
uses an aliased version. The standard version that generated tickets
and/or tokens is typically encoded in those tickets or tokens.
There are several possible techniques for the server securely
recovering the standard version in use for an aliased connection:
* the server could store a mapping of aliased versions to standard
version;
* the server could encrypt the standard version in use in the
aliased version number (note that the ITE cannot be extracted
until the standard version in use is known);
* the server only accepts one standard version for aliased versions;
or
* the standard version is included as an input to the parameter
generation algorithm, and the server tries all supported standard
versions and tests each resulting Packet Length Offset for
validity.
3.6. Expiration Time
Servers should select an expiration time in seconds, measured from Servers should select an expiration time in seconds, measured from
the instant the transport parameter is first sent. This time SHOULD the instant the transport parameter is first sent. This time SHOULD
be less than the time until the server expects to support new QUIC be less than the time until the server expects to support new QUIC
versions, rotate the keys used to encode information in the version versions, rotate the keys used to encode information in the version
number, or rotate the keys used in salt generation. number, or rotate the keys used in salt generation.
Furthermore, the expiration time SHOULD be short enough to frustrate Furthermore, the expiration time SHOULD be short enough to frustrate
a salt polling attack (Section 8.7) a salt polling attack (Section 8.7)
Conversely, an extremely short expiration time will often force the Conversely, an extremely short expiration time will often force the
client to use standard QUIC version numbers and salts. client to use standard QUIC version numbers and salts.
3.5. Format 3.7. Format
This document defines a new transport parameter extension for QUIC This document defines a new transport parameter extension for QUIC
with provisional identifier 0x5641. The contents of the value field with provisional identifier 0x5641. The contents of the value field
are indicated below. are indicated below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Aliased Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ + + +
| Salt (160) | | Salt (160) |
+ + + +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length Offset (i) | | Packet Length Offset (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration (i) | | Expiration (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Token Extension (variable) | |INI|0RT|HAN|RET| Initial Token Extension (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Version Alias Transport Parameter value Figure 1: Version Alias Transport Parameter value
The definition of the fields is described above. Note that the The definition of the fields is described above. Note that the
"Expiration" field is in seconds, and its length is encoded using the "Expiration" field is in seconds, and its length is encoded using the
Variable Length Integer encoding from Section 16 of [RFC9000]. Variable Length Integer encoding from Section 16 of [RFC9000].
The Packet Length Offset is also encoded as a Variable Length The Packet Length Offset is also encoded as a Variable Length
Integer. Integer.
INI, 0RT, HAN, and RET are the codepoints for each long header packet
type. If any two packet types have the same codepoint, the transport
parameter is invalid.
Clients can compute the length of the Initial Token Extension by Clients can compute the length of the Initial Token Extension by
subtracting known and encoded field lengths from the overall subtracting known and encoded field lengths from the overall
transport parameter length. transport parameter length.
Note that servers that support version aliasing need not send the Note that servers that support version aliasing need not send the
transport parameter on every connection. Therefore, a client MAY transport parameter on every connection. Therefore, a client MAY
attempt to connect with an unexpired aliased version, even if in its attempt to connect with an unexpired aliased version, even if in its
most recent connection it did not receive the transport parameter. most recent connection it did not receive the transport parameter.
Clients MAY remember the value in this transport parameter for future Clients MAY remember the values in this transport parameter for
connections. Servers MUST either store the contents of the transport future connections. Servers MUST either store the contents of the
parameter, or preserve the state to compute the full contents based transport parameter, or preserve the state to compute the full
on what the client provides. contents based on what the client provides.
3.6. Multiple Servers for One Domain A server that receives this transport parameter MUST close the
connection with a TRANSPORT_PARAMETER_ERROR.
3.8. Multiple Servers for One Domain
If multiple servers serve the same entity behind a load balancer, all If multiple servers serve the same entity behind a load balancer, all
such servers SHOULD either have a common configuration for encoding such servers SHOULD either have a common configuration for encoding
standard versions and computing salts, or share a common database of standard versions and computing salts, or share a common database of
mappings. They MUST NOT generate version numbers that any of them mappings. They MUST NOT generate version numbers that any of them
would advertise in a Version Negotiation Packet or Transport would advertise in a Version Negotiation Packet or Transport
Parameter. Parameter.
3.7. Multiple Entities With One Load Balancer 3.9. Multiple Entities With One Load Balancer
If mutually mistrustful entities share the same IP address and port, If mutually mistrustful entities share the same IP address and port,
incoming packets are usually routed by examining the SNI at a load incoming packets are usually routed by examining the SNI at a load
balancer server that routes the traffic. This use case makes balancer server that routes the traffic. This use case makes
concealing the contents of the Client Initial especially attractive, concealing the contents of the Client Initial especially attractive,
as the IP address reveals less information. There are several as the IP address reveals less information. There are several
solutions to solve this problem. solutions to solve this problem.
* All entities have a common crytographic context for deriving salts * All entities have a common crytographic context for deriving salts
and Packet Length Offsets from the version number and ITE. This and Packet Length Offsets from the version number and ITE. This
skipping to change at page 11, line 12 skipping to change at page 12, line 22
all available version numbers to maximize the entropy of the all available version numbers to maximize the entropy of the
encoding. encoding.
Note that [ECHO] and [QUIC-PI] solve this problem elegantly by only Note that [ECHO] and [QUIC-PI] solve this problem elegantly by only
holding the private key at the load balancer, which decodes the holding the private key at the load balancer, which decodes the
sensitive information on behalf of the back-end server. sensitive information on behalf of the back-end server.
4. Client Behavior 4. Client Behavior
When a client receives the Version Alias Transport Parameter, it MAY When a client receives the Version Alias Transport Parameter, it MAY
cache the version number, ITE, salt, Packet Length Offset, and the cache the version number, ITE, salt, Packet Length Offset, packet
expiration of these values. It MAY use the version number and ITE in type codepoints, and the expiration of these values. It MAY use the
a subsequent connection and compute the initial keys using the version number and ITE in a subsequent connection and compute the
provided salt. initial keys using the provided salt.
The Client MUST NOT use the contents of a Version Alias transport The Client MUST NOT use the contents of a Version Alias transport
parameter if the handshake does not (1) later authenticate the server parameter if the handshake does not (1) later authenticate the server
name or (2) result in both endpoints computing the same 1-RTT keys. name or (2) result in both endpoints computing the same 1-RTT keys.
See Section 8.1. The authenticated server name MAY be a "public See Section 8.1. The authenticated server name MAY be a "public
name" distributed as described in [ECHO] rather than the true target name" distributed as described in [ECHO] rather than the true target
domain. domain.
Clients MUST NOT advertise aliased versions in the Version Clients MUST NOT advertise aliased versions in the Version
Negotiation Transport Parameter unless they support a standard Negotiation Transport Parameter unless they support a standard
skipping to change at page 11, line 41 skipping to change at page 12, line 51
Clients MAY decline to use the provided version number or salt in Clients MAY decline to use the provided version number or salt in
more than one connection. It SHOULD do so if its IP address has more than one connection. It SHOULD do so if its IP address has
changed between two connection attempts. Using a consistent version changed between two connection attempts. Using a consistent version
number can link the client across connection attempts. number can link the client across connection attempts.
Clients MUST use the same standard version to format the Initial Clients MUST use the same standard version to format the Initial
Packet as the standard version used in the connection that provided Packet as the standard version used in the connection that provided
the aliased version. the aliased version.
Clients MUST use the provided codepoints to encode the packet type.
If the server provided an ITE, the client MUST append it to any If the server provided an ITE, the client MUST append it to any
Initial Packet token it is including from a Retry packet or NEW_TOKEN Initial Packet token it is including from a Retry packet or NEW_TOKEN
frame, if it is using the associated aliased version. If there is no frame, if it is using the associated aliased version. If there is no
such token, it simply includes the ITE as the entire token. such token, it simply includes the ITE as the entire token.
When using an aliased version, the client MUST include a When using an aliased version, the client MUST include a
aliasing_parameters transport parameter in its Client Hello. aliasing_parameters transport parameter in its Client Hello.
The QUIC Token Length field MUST include the length of both any Retry The QUIC Token Length field MUST include the length of both any Retry
or NEW_TOKEN token and the ITE. or NEW_TOKEN token and the ITE.
skipping to change at page 12, line 47 skipping to change at page 14, line 13
The Version field matches the one in the packet header. The Version field matches the one in the packet header.
The Initial Token field matches the Initial Token in the packet The Initial Token field matches the Initial Token in the packet
header, including any Retry token, NEW_TOKEN token, and Initial Token header, including any Retry token, NEW_TOKEN token, and Initial Token
Extension. Its length is inferred from the specified length of the Extension. Its length is inferred from the specified length of the
parameter. parameter.
The purpose of this parameter is to validate the contents of these The purpose of this parameter is to validate the contents of these
header fields by including it in the TLS handshake transcript. header fields by including it in the TLS handshake transcript.
A client that receives this transport parameter MUST close the
connection with a TRANSPORT_PARAMETER_ERROR.
5. Server Actions on Aliased Version Numbers 5. Server Actions on Aliased Version Numbers
When a server receives an Initial packet with an unsupported version When a server receives a packet with an unsupported version number,
number, it SHOULD send a Version Negotiation Packet if it is it SHOULD send a Version Negotiation Packet if it is configured not
configured not to generate that version number at random. to generate that version number at random.
Otherwise, it extracts the ITE, if any, and either looks up the Otherwise, when a server receives the first long header packet with
corresponding salt in its database or computes it using the technique an unsupported version number, it hashes that version number to
originally used to derive the salt from the version number and ITE. obtain the packet type mapping. If the packet is Handshake or Retry,
there may have been a loss of relevant server state; the server
discards the packet and SHOULD follow the procedure in Section 6. If
0RTT, the server MAY either buffer it in anticipation of a later
Initial, or immediately follow the procedure in Section 6. If
buffering, and an Initial packet never arrives, the server SHOULD
follow the procedure in Section 6 when discarding any 0RTT packets.
For an Initial packet, it extracts the ITE, if any, and either looks
up the corresponding salt in its database or computes it using the
technique originally used to derive the salt from the version number
and ITE.
The server similarly obtains the Packet Length Offset and subtracts The server similarly obtains the Packet Length Offset and subtracts
it from the provided Length field, modulo 2^62. If the resulting it from the provided Length field, modulo 2^62. If the resulting
value is larger than the entire UDP datagram, the server discards the value is larger than the entire UDP datagram, the server discards the
packet and SHOULD follow the procedure in Section 6. The server MAY packet and SHOULD follow the procedure in Section 6. The server MAY
apply further checks (e.g. against the minimum QUIC packet length) to apply further checks (e.g. against the minimum QUIC packet length) to
further reduce the very small probability of a false positive. further reduce the very small probability of a false positive.
If the server supports multiple standard versions, it uses the If the server supports multiple standard versions, it uses the
standard version extracted by the ITE or stored in the mapping to standard version extracted by the ITE or stored in the mapping to
skipping to change at page 15, line 49 skipping to change at page 17, line 21
Timeout (PTO) to check if the Bad Salt packet was injected by an Timeout (PTO) to check if the Bad Salt packet was injected by an
attacker, and a valid response arrives from the actual server. attacker, and a valid response arrives from the actual server.
After waiting, the client checks the Integrity Tag using its record After waiting, the client checks the Integrity Tag using its record
of the Initial it sent. If this fails, the client SHOULD assume of the Initial it sent. If this fails, the client SHOULD assume
packet corruption and resend the Initial packet. packet corruption and resend the Initial packet.
If the verification succeeds, the client SHOULD attempt to connect If the verification succeeds, the client SHOULD attempt to connect
with one of the listed standard versions. It SHOULD observe the with one of the listed standard versions. It SHOULD observe the
privacy considerations in Section 8.2. It MUST include a privacy considerations in Section 8.2. It MUST include a
version_aliaising Transport Parameter in the Client Hello, that version_aliasing_fallback Transport Parameter in the Client Hello.
enumerates the aliased version and parameters it just tried to
connect with.
Once it sends this transport parameter, the client MUST NOT attempt Once it sends this transport parameter, the client MUST NOT attempt
to connect with that aliased version again. to connect with that aliased version again.
The original Client Initial is not part of the new connection. The original Client Initial is not part of the new connection.
Therefore, the Connection IDs can change, and the original client Therefore, the Connection IDs can change, and the original client
hello is not part of the transcript for TLS key derivation. hello is not part of the transcript for TLS key derivation.
Note that the client never sends this transport parameter with an 6.3. version_aliasing_fallback Transport Parameter
aliased version. A server that receives such a packet MUST terminate
the connection with a TRANSPORT_PARAMETER_ERROR.
6.3. Server Response to version_aliasing Transport Parameter The client sends this transport parameter in a TLS Client Hello
generated in response to a Bad Salt packet:
A client version_aliasing transport parameter tells the server that 0 1 2 3
the client received a Bad Salt packet. The server checks if could 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
have generated that version aliasing transport parameter given its +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
current configuration; i.e. if using the version and ITE as inputs | Aliased Version (32) |
results in the same salt and Packet Length Offset. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Salt (160) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bad Salt Integrity Tag (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Token (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the salt or Packet Length Offset are invalid, the server SHOULD The Aliased Version, Salt, and Initial Token fields are taken from
continue with the connection and SHOULD issue a new version_aliasing the connection attempt that triggered this fallback. The length of
transport parameter. the Initial Token is inferred from the Transport Parameter's overall
length.
The Bad Salt Integrity Tag comes from is taken from the Bad Salt
packet that triggered this fallback. Its purpose is to include the
Bad Salt packet contents in the TLS handshake hash.
6.4. Server Response to version_aliasing_fallback Transport Parameter
A client version_aliasing_fallback transport parameter tells the
server that the client received a Bad Salt packet. The server checks
if using the version and ITE as inputs results in the same salt.
If the salt does not match, the server SHOULD continue with the
connection and SHOULD issue a new version_aliasing transport
parameter.
If the salt and Packet Length Offset are valid, the server MUST If the salt and Packet Length Offset are valid, the server MUST
terminate the connection with the error code INVALID_BAD_SALT. terminate the connection with the error code INVALID_BAD_SALT.
Note that the client never sends this transport parameter with an
aliased version. A server that receives such a packet MUST terminate
the connection with a TRANSPORT_PARAMETER_ERROR.
7. Considerations for Retry Packets 7. Considerations for Retry Packets
QUIC Retry packets reduce the load on servers during periods of QUIC Retry packets reduce the load on servers during periods of
stress by forcing the client to prove it possesses the IP address stress by forcing the client to prove it possesses the IP address
before the server decrypts any Initial Packets or establishes any before the server decrypts any Initial Packets or establishes any
connection state. Version aliasing substantially complicates the connection state. Version aliasing substantially complicates the
process. process.
If a server has to send a Retry packet, the required format is If a server has to send a Retry packet, the required format is
ambiguous without understanding which standard version to use. If ambiguous without understanding which standard version to use. If
skipping to change at page 21, line 29 skipping to change at page 24, line 4
the client, potentially increasing the potency of this attack. the client, potentially increasing the potency of this attack.
9. IANA Considerations 9. IANA Considerations
9.1. QUIC Version Registry 9.1. QUIC Version Registry
This document request that IANA add the following entry to the QUIC This document request that IANA add the following entry to the QUIC
version registry: version registry:
Value: TBD Value: TBD
Status: permanent Status: permanent
Specification: This document Specification: This document
Change Controller: IETF Change Controller: IETF
Contact: QUIC WG Contact: QUIC WG
9.2. QUIC Transport Parameter Registry 9.2. QUIC Transport Parameter Registry
This document requests that IANA add the following entries to the This document requests that IANA add the following entries to the
QUIC Transport Parameters Registry: QUIC Transport Parameters Registry:
+=======+=====================+===============+ +=======+===========================+===============+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+=======+=====================+===============+ +=======+===========================+===============+
| TBD | Version Aliasing | This Document | | TBD | version_aliasing | This Document |
+-------+---------------------+---------------+ +-------+---------------------------+---------------+
| TBD | aliasing_parameters | This Document | | TBD | aliasing_parameters | This Document |
+-------+---------------------+---------------+ +-------+---------------------------+---------------+
| TBD | version_aliasing_fallback | This Document |
+-------+---------------------------+---------------+
Table 1 Table 1
9.3. QUIC Transport Error Codes Registry 9.3. QUIC Transport Error Codes Registry
This document requests that IANA add the following entry to the QUIC This document requests that IANA add the following entry to the QUIC
Transport Error Codes registry: Transport Error Codes registry:
Value: TBD (provisional: 0x4942) Value: TBD (provisional: 0x4942)
Code: INVALID_BAD_SALT Code: INVALID_BAD_SALT
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-quic-version-negotiation] [I-D.ietf-quic-version-negotiation]
Schinazi, D. and E. Rescorla, "Compatible Version 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-04, 26 May 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-04>. version-negotiation-07>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
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>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] 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>.
10.2. Informative References 10.2. Informative References
[ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-13, 12 August 2021, draft-ietf-tls-esni-14, 13 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-13>. esni-14>.
[QUIC-PI] Duke, M. and D. Schinazi, "Protected QUIC Initial [QUIC-PI] Duke, M. and D. Schinazi, "Protected QUIC Initial
Packets", Work in Progress, Internet-Draft, draft-duke- Packets", Work in Progress, Internet-Draft, draft-duke-
quic-protected-initial-02, 13 May 2021, quic-protected-initial-04, 27 April 2022,
<https://datatracker.ietf.org/doc/html/draft-duke-quic- <https://datatracker.ietf.org/doc/html/draft-duke-quic-
protected-initial-02>. protected-initial-04>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Marten Seemann was the original creator of the version aliasing Marten Seemann was the original creator of the version aliasing
approach. approach.
Appendix B. Change Log Appendix B. Change Log
*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-duke-quic-version-aliasing-05 B.1. since draft-duke-quic-version-aliasing-07
* Added the Bad Salt Integrity Tag to the transport parameter
* Greased packet types
* Allowed the server to specify the standard version to connect with
B.2. since draft-duke-quic-version-aliasing-05
* Revised security considerations * Revised security considerations
* Discussed multiple SNIs behind one load balancer * Discussed multiple SNIs behind one load balancer
* Removed VN from the fallback mechanism * Removed VN from the fallback mechanism
B.2. since draft-duke-quic-version-aliasing-04 B.3. since draft-duke-quic-version-aliasing-04
* Relationship with Encrypted Client Hello (ECH) and QUIC Protected * Relationship with Encrypted Client Hello (ECH) and QUIC Protected
Initials Initials
* Corrected statement about version negotiation * Corrected statement about version negotiation
B.3. since draft-duke-quic-version-aliasing-03 B.4. since draft-duke-quic-version-aliasing-03
* Discussed request forgery attacks * Discussed request forgery attacks
B.4. since draft-duke-quic-version-aliasing-02 B.5. since draft-duke-quic-version-aliasing-02
* Specified 0RTT status of the transport parameter * Specified 0RTT status of the transport parameter
B.5. since draft-duke-quic-version-aliasing-01 B.6. since draft-duke-quic-version-aliasing-01
* Fixed all references to "seed" where I meant "salt." * Fixed all references to "seed" where I meant "salt."
* Added the Packet Length Offset, which eliminates Retry Injection * Added the Packet Length Offset, which eliminates Retry Injection
Attacks Attacks
B.6. since draft-duke-quic-version-aliasing-00 B.7. since draft-duke-quic-version-aliasing-00
* Added "Initial Token Extensions" to increase salt entropy and make * Added "Initial Token Extensions" to increase salt entropy and make
salt polling attacks impractical. salt polling attacks impractical.
* Allowed servers to store a mapping of version number and ITE to * Allowed servers to store a mapping of version number and ITE to
salt instead. salt instead.
* Made standard version encoding mandatory. This dramatically * Made standard version encoding mandatory. This dramatically
simplifies the new Retry logic and changes the security model. simplifies the new Retry logic and changes the security model.
* Added references to Version Negotiation Transport Parameters. * Added references to Version Negotiation Transport Parameters.
* Extensive readability edit. * Extensive readability edit.
Author's Address Author's Address
Martin Duke Martin Duke
F5 Networks, Inc. Google
Email: martin.h.duke@gmail.com Email: martin.h.duke@gmail.com
 End of changes. 49 change blocks. 
146 lines changed or deleted 265 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/