QUIC Version AliasingF5 Networks, Inc.martin.h.duke@gmail.com
Transport
QUICThe QUIC transport protocol preserves its future
extensibility partly by specifying its version number. There will be a
relatively small number of published version numbers for the foreseeable future.
This document provides a method for clients and servers to negotiate the use of
other version numbers in subsequent connections. If a sizeable subset of QUIC
connections use this mechanism, this should prevent middlebox ossification
around the current set of published version numbers and the contents of QUIC
Initial packets.The QUIC version number is critical to future extensibility of the protocol. Past
experience with other protocols, such as TLS1.3 , shows that
middleboxes might attempt to enforce that QUIC packets use versions known at the
time the middlebox was implemented. This has a chilling effect on deploying
experimental and standard versions on the internet.Each version of QUIC has a “salt” that is used to derive the keys
used to encrypt Initial packets. As each salt is published in a standards
document, any observer can decrypt these packets and inspect the contents,
including a TLS Client Hello. A subsidiary mechanism like Encrypted SNI
might protect some of the TLS fields inside a TLS Client Hello.This document proposes “QUIC Version Aliasing,” a standard way of servers
advertising the availability of other versions inside the cryptographic
protection of a QUIC handshake. These versions are syntactically identical to the
QUIC version in which the communication takes place, but use a different salt. In
subsequent communications, the client uses the new version number and encrypts
its Initial packets with a key derived from the provided salt. These version
numbers and salts are unique to the client.If a large subset of QUIC traffic adopts his technique, middleboxes will be
unable to enforce particular version numbers or policy based on Client Hello
contents without incurring unacceptable penalties on users. This would
simultaneously protect the protocol against ossification and improve its privacy
properties.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 .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 interpreted as carrying
significance described in RFC 2119.A “syntax version” is a QUIC version that would be advertised in a QUIC version
negotiation and conforms to a specification. Any aliased version corresponds to
a syntax version in all its formats and behaviors, except for the version number
field in long headers.An “aliased version” is a version with a number generated in accordance with this
document. Except for the version field in long headers, it conforms entirely to
the specification of the syntax version.When they instantiate a connection, servers select an alternate 32-bit version
number for the next connection at random and securely derive a salt from that
version number using a repeatable process. They communicate this using a
transport parameter extension including the version, salt, and an expiration time
for that value.The next time a client connects to that server, if it is within the indicated
expiration time, it MAY use the provided version number and encrypt its Initial
Packets using a key derived from the provided salt. The server can reconstruct
the salt from the requested version and proceed with the connection normally.Servers MUST use a random process to generate version numbers. This version
number MUST NOT correspond to a QUIC version the server advertises in QUIC
Version Negotiation packets.Servers MAY encode the syntax version as long as this information is
cryptographically protected. For example, a server advertises support for QUIC
version 1 and QUIC version 2 in Version Negotiation packets, each corresponding
to a particular packet syntax. In a Version 1 connection, it might provide an
aliased version in the transport parameter, 0x45f3213b, that encodes the fact the
syntax version is 1. When the client initiates a connection using version
0x45f3213b, the server knows the Initial Packet is formatted in accordance with
QUIC version 1. A subsequent aliased version provided in the transport parameters
would also encode version 1, even though this is sent in a connection ostensibly
of version 0x45f3213b.Servers MUST NOT use client-controlled information (e.g. the client IP address)
in the random process, see .Servers MUST NOT advertise these versions in QUIC Version Negotiation packets.If multiple servers represent the same entity behind a load balancer, all such
servers SHOULD have a common configuration for how to encode and extract syntax
version to use. They MUST NOT generate version numbers that any of them would
advertise in a Version Negotiation Packet.The salt is an opaque 20-octet field. It is used to generate a Initial connection
keys using the process described in {QUIC-TLS}.Servers MUST generate the SALT using a cryptographic method that uses the version
number and only server state that is persistent across connections. That is,
servers MUST implement a method that it can repeat deterministically at a later
time to derive the salt from the incoming version number. It MUST NOT use client
controlled information other than the version number; for example, the client’s
IP address and port.Servers should select an expiration time in seconds, measured from the instant
the transport parameter is first sent. This time SHOULD be less than the time
until the server expects to support new QUIC versions, rotate the keys used
to encode information in the version number, or rotate the keys use in salt
generation.Furthermore, the expiration time SHOULD be short enough to frustrate a seed
polling attack .Conversely, an extremely short expiration time will often force the client to use
standard QUIC version numbers and salts.This document defines a new transport parameter extension for QUIC with
identifier 0x5641. The contents of the value field are indicated below.The definition of the fields is described above. Note that the “Expiration”
field is in seconds, and its length is encoded using the Variable Length
Integer encoding from Section 16 of .When a client receives the Version Alias Transport Parameter, it MAY cache
the version number, salt, and the expiration of this value. It MAY use the
version number in a subsequent connection and compute the initial keys using
the provided salt.Clients SHOULD NOT attempt to use the provided version number and salt after
the provided Expiration time has elapsed.Clients SHOULD NOT use the provided version number or salt in more than one
connection, particularly if its IP address has changed between two connection
attempts. Using a consistent version number can link the client across IP address
changes.Clients MUST use the same syntax version to format the Initial Packet as the
syntax version used in the connection that provided the aliased version.If the response to an Initial packet using the provided version is a Version
Negotiation Packet, the client SHOULD cease attempting to use that version and
salt to the server unless it later determines that the packet was the result of
a version downgrade, see .When a server receives an Initial Packet with an unknown version number, it
SHOULD send a Version Negotiation Packet if it is specifically configured not to
generate that version number at random. Otherwise, it derives a salt from the
version number using the algorithm and inputs it uses to generate salts to put in
transport parameters.If the syntax version was encoded in the version number, the server extracts it
so that it can properly parse the packet. If not, it can try trial parsing of the
packet for each syntax version it supports.If the computed seed results in a packet that fails authentication, or the
encoded syntax version is not supported at the server, or trial parsing fails for
all supported versions, the server SHOULD send a Version Negotiation Packet.Servers SHOULD provide a new Version Alias transport parameter, with a new
version number and salt, each time a client connects, to reduce linkability for
the client. However, issuing version numbers to a client SHOULD be rate-limited
to mitigate the seed polling attack .QUIC Retry packets reduce the load on servers during periods of stress by forcing
the client to prove it possesses the IP address before the server decrypts any
Initial Packets or establishing any connection state. Version aliasing
substantially complicates the process.If a server has to send a Retry packet, the required format is ambiguous without
understanding which syntax version to use. If all supported syntax versions use
the same Retry format, it simply uses that format with the provided version
number.If the supported syntax versions use different Retry formats, the server MUST
either extract the syntax version from the version field and format the Retry
accordingly using the aliased version number, or it MUST send a valid Retry
packet for each supported version using the syntax version number instead of the
aliased version number. It MUST NOT do both.The Retry integrity Tag of a Retry Packet for an aliased version uses the
procedure in Section 5.8 of . However, the secret key K uses the
first 16 octets of the aliased salt instead of the key provided in the
specification.Clients MUST accept Retry packets that contain either the aliased version or
syntax version. It MUST ignore Retry packets with other syntax versions. It it
receives Retry packets with both the aliased version and the correct syntax
version, it MUST discard the second one it receives in accordance with section
17.2.5 of unless the other one failed integrity validation.After a client receives a Retry, it sends a new Initial Packet with the provided
Retry token. It MAY use the aliased version and salt or the syntax version and
salt, regardless of which type of Retry it received. Note that if the server is
not able to generate the correct salt for an aliased version due to lost keys or
other errors, this might result in a Version Negotiation packet, which violates
the usual order of server responses (QUIC servers would normally send Version
Negotiation before Retry).Clients that receive a Version Negotiation packet in response to an Initial with
a valid Retry token MAY interpret this to mean that the server can no longer
process the aliased version. They can retry the connection with a syntax version
number, but see . These MUST include the Retry token so
that the client can verify that the Retry was authentic.This document intends to improve the existing security and privacy properties of
QUIC by dramatically improving the secrecy of QUIC Initial Packets. However,
there are new attacks against this mechanism.A countermeasure against version aliasing is the downgrade attack. Middleboxes
may drop a packet containing a random version and imitate the server’s failure to
correctly process it. Clients and servers MUST implement the parts of
relevant to downgrade detection.Note that downgrade detection only works after receiving a response from the
server. If a client immediately responds to a Version Negotiation Packet with
an Initial Packet with a syntax version number, it will have exposed its request
in a format readable to observers before it discovers if the Version Negotiation
Packet is authentic. A client SHOULD wait for an interval to see if a valid
response comes from the server before assuming the version negotiation is valid.
The client MAY also alter its Initial Packet (e.g., its ALPN field) to sanitize
sensitive information and obtain another aliased version before proceeding with
its true request.Servers that support version aliasing SHOULD be liberal about the Initial Packet
formats they receive, keeping the connection open long enough to deliver their
transport parameters, to support this mechanism.As each version number is theoretically unique to each client, if a client uses
one twice, those two connections are extremely likely to be from the same host.
If the client has changed IP address, this is a significant increase in
linkability relative to QUIC with a standard version numbers.Observers that wish to decode Initial Packets might open a large number of
connections to the server in an effort to obtain a large portion of the mapping
of version numbers to salts to a server. While storage-intensive, this attack
could increase the probability that at least some version-aliased connections are
observable. There are two mitigations servers can execute against this
attack:rate-limit transport parameters sent to a particular client; and/orset a low expiration time to reduce the lifetime of the attacker’s database.Segmenting the version number space based on client information, i.e. using only
a subset of version numbers for a certain IP address range, would significantly
amplify an attack. Observers will generally be on the path to the client and be
able to mimic having an identical IP address. Segmentation in this way would
dramatically reduce the search space for attackers. Thus, servers are prohibited
from using these mechanisms.As QUIC shares the UDP protocol number with other UDP applications, in some
deployments it may be possible for traffic intended for other UDP applications to
arrive at a QUIC server endpoint. When servers support a finite set of version
numbers, a valid version number field is a strong indicator the packet is, in
fact, QUIC. If the version number is invalid, a QUIC Version Negotiation is a
low-cost response that triggers very early in packet processing.However, a server that provides version aliasing is prepared to accept almost any
version number. As a result, many more sufficiently sized UDP payloads with the
first bit set to ‘1’ are potential QUIC Initial Packets that require generation
of a salt, some initial connection state, and a decryption operation.While not a more potent attack then simply sending valid Initial Packets, servers
may have to provision additional resources to address this possibility.This document requires two small cryptographic operations to build a Retry packet
instead of one, placing more load on servers when already under load.This draft chooses a transport parameter (0x5641) to minimize the risk of
collision. IANA should assign a permanent value from the QUIC Transport Parameter
Registry.QUIC: A UDP-Based Multiplexed and Secure TransportFastlyMozillaUsing Transport Layer Security (TLS) to Secure QUICMozillasn3rdCompatible Version Negotiation for QUICGoogle LLCMozillaEncrypted Server Name Indication for TLS 1.3RTFM, Inc.FastlyCloudflareApple, Inc.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Marten Seemann was the original progenitor of the version aliasing approach.RFC Editor’s Note: Please remove this section prior to
publication of a final version of this document.