Draft: draft-ietf-quic-tls

Commentary: This takes example and expands on it , hopefully without destroying it . In summary : the output is condensed a little , which keeps the giant client Initial somewhat more in check formula and variable names consistent with the rest of the spec for context packet protection The known bug here is that the ClientHello does n't include transport parameters . The ServerHello should be OK . And I think that the ACK is correct also . I did try to get the connection IDs and packet numbers correct . I would appreciate someone checking my work . I do n't have a convenient method of testing this . 
 I 've independently replicated the key derivation and the server initial encryption given here . 
 Another question : would checking in the script I used to produce these be helpful for anyone ? 
 Nice ! I think the script would be helpful ! 
 I 've the test vector to the unit test of quicly , so that I can continue confirming the values as the draft evolves . And of course , the current test vector decrypts successfully . 
 Thanks everyone for checking these values . At request , I 've tweaked the packet numbers . That means new values , but I 'll assume that these are OK . 
 Confirmed that the updated version correctly decrypts and gives PN=2 . 
 Thanks that 's enough for me :) 
 Thanks I updated my test vectors in quic - go , and I can confirm that the new values work . 
 I also the vector to a unit test of quic - go , and I 'm getting the same values . As noted in my in - line comment , I 'd prefer to use different packet numbers for both packets sent from client and server . FWIW I also verified the vectors with my implementation .
Paragraph (version A):
This document describes how QUIC QUIC-TRANSPORT is secured using
Transport Layer Security (TLS) version 1.3 TLS13.  TLS 1.3 provides
critical latency improvements for connection establishment over
previous versions.  Absent packet loss, most new connections can be
established and secured within a single round trip; on subsequent
connections between the same client and server, the client can often
send application data immediately, that is, using a zero round trip
setup.
Paragraph (version A):
This document describes how the standardized TLS 1.3 acts as a
security component of QUIC.
Paragraph (version B):
This document describes how QUIC QUIC-TRANSPORT is secured using TLS
TLS13.
Paragraph (version B):
TLS 1.3 provides critical latency improvements for connection
establishment over previous versions.  Absent packet loss, most new
connections can be established and secured within a single round
trip; on subsequent connections between the same client and server,
the client can often send application data immediately, that is,
using a zero round trip setup.
Paragraph (version B):
This document describes how TLS acts as a security component of QUIC.
Paragraph (version A):
For brevity, the acronym TLS is used to refer to TLS 1.3.
Paragraph (version A):
The TLS key exchange is resistent to tampering by attackers and it
produces shared secrets that cannot be controlled by either
participating peer.
Paragraph (version B):
The TLS key exchange is resistant to tampering by attackers and it
produces shared secrets that cannot be controlled by either
participating peer.
Paragraph (version A):
A simplified TLS 1.3 handshake with 0-RTT application data is shown
in tls-full, see TLS13 for more options and details.
Paragraph (version A):
QUIC QUIC-TRANSPORT assumes responsibility for the confidentiality
and integrity protection of packets.  For this it uses keys derived
from a TLS 1.3 handshake TLS13, but instead of carrying TLS records
over QUIC (as with TCP), TLS Handshake and Alert messages are carried
directly over the QUIC transport, which takes over the
responsibilities of the TLS record layer, as shown below.
Paragraph (version A):
QUIC also relies on TLS 1.3 for authentication and negotiation of
parameters that are critical to security and performance.
Paragraph (version A):
Rather than a strict layering, these two protocols are co-dependent:
QUIC uses the TLS handshake; TLS uses the reliability and ordered
delivery provided by QUIC streams.
Paragraph (version B):
QUIC also relies on TLS for authentication and negotiation of
parameters that are critical to security and performance.
Paragraph (version A):
One important difference between TLS 1.3 records (used with TCP) and
QUIC CRYPTO frames is that in QUIC multiple frames may appear in the
same QUIC packet as long as they are associated with the same
encryption level.  For instance, an implementation might bundle a
Handshake message and an ACK for some Handshake data into the same
packet.
Paragraph (version A):
CRYPTO frames MAY appear in packets of any encryption level.
Paragraph (version A):
ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in
that encryption level.
Paragraph (version B):
One important difference between TLS records (used with TCP) and QUIC
CRYPTO frames is that in QUIC multiple frames may appear in the same
QUIC packet as long as they are associated with the same encryption
level.  For instance, an implementation might bundle a Handshake
message and an ACK for some Handshake data into the same packet.
Paragraph (version B):
CRYPTO frames MAY appear in packets of any encryption level except
0-RTT.
Paragraph (version B):
ACK frames MAY appear in packets of any encryption level other
than 0-RTT, but can only acknowledge packets which appeared in
that packet number space.
Paragraph (version A):
Section 6.3 of QUIC-TRANSPORT shows how packets at the various
encryption levels fit into the handshake process.
Paragraph (version B):
Section 17 of QUIC-TRANSPORT shows how packets at the various
encryption levels fit into the handshake process.
Paragraph (version A):
A QUIC client starts TLS by requesting TLS handshake octets from TLS.
The client acquires handshake octets before sending its first packet.
A QUIC server starts the process by providing TLS with the client's
handshake octets.
Paragraph (version A):
At any given time, the TLS stack at an endpoint will have a current
sending encryption level and receiving encryption level.  Each
encryption level is associated with a different flow of bytes, which
is reliably transmitted to the peer in CRYPTO frames.  When TLS
provides handshake octets to be sent, they are appended to the
current flow and any packet that includes the CRYPTO frame is
protected using keys from the corresponding encryption level.
Paragraph (version B):
A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
The client acquires handshake bytes before sending its first packet.
A QUIC server starts the process by providing TLS with the client's
handshake bytes.
Paragraph (version B):
QUIC takes the unprotected content of TLS handshake records as the
content of CRYPTO frames.  TLS record protection is not used by QUIC.
QUIC assembles CRYPTO frames into QUIC packets, which are protected
using QUIC packet protection.
Paragraph (version A):
Each time that TLS is provided with new data, new handshake octets
are requested from TLS.  TLS might not provide any octets if the
handshake messages it has received are incomplete or it has no data
to send.
Paragraph (version A):
Once the TLS handshake is complete, this is indicated to QUIC along
with any final handshake octets that TLS needs to send.  TLS also
provides QUIC with the transport parameters that the peer advertised
during the handshake.
Paragraph (version B):
Each time that TLS is provided with new data, new handshake bytes are
requested from TLS.  TLS might not provide any bytes if the handshake
messages it has received are incomplete or it has no data to send.
Paragraph (version B):
Once the TLS handshake is complete, this is indicated to QUIC along
with any final handshake bytes that TLS needs to send.  TLS also
provides QUIC with the transport parameters that the peer advertised
during the handshake.
Paragraph (version A):
The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered.  A
client can avoid the potential for head-of-line blocking that this
implies by sending a copy of the STREAM frame that carries the
Finished message in multiple packets.  This enables immediate
server processing for those packets.
Paragraph (version A):
At each change of encryption level in either direction, TLS signals
QUIC, providing the new level and the encryption keys.  These events
are not asynchronous, they always occur immediately after TLS is
provided with new handshake octets, or after TLS produces handshake
octets.
Paragraph (version A):
If 0-RTT is possible, it is ready after the client sends a TLS
ClientHello message or the server receives that message.  After
providing a QUIC client with the first handshake octets, the TLS
stack might signal the change to 0-RTT keys.  On the server, after
receiving handshake octets that contain a ClientHello message, a TLS
server might signal that 0-RTT keys are available.
Paragraph (version A):
Note that although TLS only uses one encryption level at a time, QUIC
may use more than one level.  For instance, after sending its
Finished message (using a CRYPTO frame in Handshake encryption) may
send STREAM data (in 1-RTT encryption).  However, if the Finished is
lost, the client would have to retransmit the Finished, in which case
it would use Handshake encryption.
Paragraph (version B):
The requirement for the server to wait for the client Finished
message creates a dependency on that message being delivered.  A
client can avoid the potential for head-of-line blocking that this
implies by sending a copy of the CRYPTO frame that carries the
Finished message in multiple packets.  This enables immediate
server processing for those packets.
Paragraph (version B):
As keys for new encryption levels become available, TLS provides QUIC
with those keys.  Separately, as TLS starts using keys at a given
encryption level, TLS indicates to QUIC that it is now reading or
writing with keys at that encryption level.  These events are not
asynchronous; they always occur immediately after TLS is provided
with new handshake bytes, or after TLS produces handshake bytes.
Paragraph (version B):
If 0-RTT is possible, it is ready after the client sends a TLS
ClientHello message or the server receives that message.  After
providing a QUIC client with the first handshake bytes, the TLS stack
might signal the change to 0-RTT keys.  On the server, after
receiving handshake bytes that contain a ClientHello message, a TLS
server might signal that 0-RTT keys are available.
Paragraph (version B):
Although TLS only uses one encryption level at a time, QUIC may use
more than one level.  For instance, after sending its Finished
message (using a CRYPTO frame at the Handshake encryption level) an
endpoint can send STREAM data (in 1-RTT encryption).  If the Finished
message is lost, the endpoint uses the Handshake encryption level to
retransmit the lost message.  Reordering or loss of packets can mean
that QUIC will need to handle packets at multiple encryption levels.
During the handshake, this means potentially handling packets at
higher and lower encryption levels than the current encryption level
used by TLS.
Paragraph (version B):
In particular, server implementations need to be able to read packets
at the Handshake encryption level at the same time as the 0-RTT
encryption level.  A client could interleave ACK frames that are
protected with Handshake keys with 0-RTT data and the server needs to
process those acknowledgments in order to detect lost Handshake
packets.
Paragraph (version A):
QUIC requires that the initial handshake packet from a client fit
within the payload of a single packet.  The size limits on QUIC
packets mean that a record containing a ClientHello needs to fit
within 1129 octets, though endpoints can reduce the size of their
connection ID to increase by up to 22 octets.
Paragraph (version A):
A TLS ClientHello can fit within this limit with ample space
remaining.  However, there are several variables that could cause
this limit to be exceeded.  Implementations are reminded that large
session tickets or HelloRetryRequest cookies, multiple or large key
shares, and long lists of supported ciphers, signature algorithms,
versions, QUIC transport parameters, and other negotiable parameters
and extensions could cause this message to grow.
Paragraph (version A):
For servers, the size of the session tickets and HelloRetryRequest
cookie extension can have an effect on a client's ability to connect.
Choosing a small value increases the probability that these values
can be successfully used by a client.
Paragraph (version B):
QUIC packet and framing add at least 36 bytes of overhead to the
ClientHello message.  That overhead increases if the client chooses a
connection ID without zero length.  Overheads also do not include the
token or a connection ID longer than 8 bytes, both of which might be
required if a server sends a Retry packet.
Paragraph (version A):
A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This
also prevents QUIC from sending 0-RTT data.  A client that attempts
0-RTT MUST also consider 0-RTT to be rejected if it receives a
Version Negotiation packet.
Paragraph (version B):
A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This
also prevents QUIC from sending 0-RTT data.  A server will always
reject 0-RTT if it sends a TLS HelloRetryRequest.
Paragraph (version A):
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
TLS13) can be used to correct a client's incorrect KeyShare extension
as well as for a stateless round-trip check.  From the perspective of
QUIC, this just looks like additional messages carried in the Initial
encryption level.  Although it is in principle possible to use this
feature for address verification in QUIC, QUIC implementations SHOULD
instead use the Retry feature (see Section 4.4.2 of QUIC-TRANSPORT).
HelloRetryRequest is still used to request key shares.
Paragraph (version B):
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
TLS13) can be used to correct a client's incorrect KeyShare extension
as well as for a stateless round-trip check.  From the perspective of
QUIC, this just looks like additional messages carried in the Initial
encryption level.  Although it is in principle possible to use this
feature for address verification in QUIC, QUIC implementations SHOULD
instead use the Retry feature (see Section 8.1 of QUIC-TRANSPORT).
HelloRetryRequest is still used to request key shares.
Paragraph (version A):
A TLS alert is turned into a QUIC connection error by converting the
one-octet alert description into a QUIC error code.  The alert
description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR.  The resulting value is sent in a
QUIC CONNECTION_CLOSE frame.
Paragraph (version B):
A TLS alert is turned into a QUIC connection error by converting the
one-byte alert description into a QUIC error code.  The alert
description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR.  The resulting value is sent in a
QUIC CONNECTION_CLOSE frame.
Paragraph (version A):
As with TLS over TCP, QUIC encrypts packets with keys derived from
the TLS handshake, using the AEAD algorithm negotiated by TLS.
Paragraph (version A):
The keys for the Initial encryption level are computed based on the
client's initial Destination Connection ID, as described in initial-
secrets.
Paragraph (version A):
The keys for the remaining encryption level are computed in the same
fashion as the corresponding TLS keys (see Section 7 of TLS13),
except that the label for HKDF-Expand-Label uses the prefix "quic "
rather than "tls13 ".  A different label provides key separation
between TLS and QUIC.
Paragraph (version A):
Note that if the server sends a Retry, the client's Initial will
correspond to a new connection and thus use the server provided
Destination Connection ID.
Paragraph (version A):
The hash function for HKDF when deriving handshake secrets and keys
is SHA-256 SHA.  The connection ID used with HKDF-Expand-Label is the
initial Destination Connection ID.
Paragraph (version A):
The value of initial_salt is a 20 octet sequence shown in the figure
in hexadecimal notation.  Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each
version of QUIC.  This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of handshake
packets from future versions.
Paragraph (version B):
Packet protection keys are not discarded immediately when new keys
are available.  If packets from a lower encryption level contain
CRYPTO frames, frames that retransmit that data MUST be sent at the
same encryption level.  Similarly, an endpoint generates
acknowledgements for packets at the same encryption level as the
packet being acknowledged.  Thus, it is possible that keys for a
lower encryption level are needed for a short time after keys for a
newer encryption level are available.
Paragraph (version B):
An endpoint cannot discard keys for a given encryption level unless
it has both received and acknowledged all CRYPTO frames for that
encryption level and when all CRYPTO frames for that encryption level
have been acknowledged by its peer.  However, this does not guarantee
that no further packets will need to be received or sent at that
encryption level because a peer might not have received all the
acknowledgements necessary to reach the same state.
Paragraph (version B):
Though an endpoint might retain older keys, new data MUST be sent at
the highest currently-available encryption level.  Only ACK frames
and retransmissions of data in CRYPTO frames are sent at a previous
encryption level.  These packets MAY also include PADDING frames.
Paragraph (version B):
Once this timer expires, an endpoint MUST NOT either accept or
generate new packets using those packet protection keys.  An endpoint
can discard packet protection keys for that encryption level.
Paragraph (version B):
Key updates (see key-update) can be used to update 1-RTT keys before
keys from other encryption levels are discarded.  In that case,
packets protected with the newest packet protection keys and packets
sent two updates prior will appear to use the same keys.  After the
handshake is complete, endpoints only need to maintain the two latest
sets of packet protection keys and MAY discard older keys.  Updating
keys multiple times rapidly can cause packets to be effectively lost
if packets are significantly delayed.  Because key updates can only
be performed once per round trip time, only packets that are delayed
by more than a round trip will be lost as a result of changing keys;
such packets will be marked as lost before this, as they leave a gap
in the sequence of packet numbers.
Paragraph (version B):
The successful use of Handshake packets indicates that no more
Initial packets need to be exchanged, as these keys can only be
produced after receiving all CRYPTO frames from Initial packets.
Thus, a client MUST discard Initial keys when it first sends a
Handshake packet and a server MUST discard Initial keys when it first
successfully processes a Handshake packet.  Endpoints MUST NOT send
Initial packets after this point.
Paragraph (version B):
This results in abandoning loss recovery state for the Initial
encryption level and ignoring any outstanding Initial packets.
Paragraph (version B):
QUIC derives packet protection keys in the same way that TLS derives
record protection keys.
Paragraph (version B):
Each encryption level has separate secret values for protection of
packets sent in each direction.  These traffic secrets are derived by
TLS (see Section 7.1 of TLS13) and are used by QUIC for all
encryption levels except the Initial encryption level.  The secrets
for the Initial encryption level are computed based on the client's
initial Destination Connection ID, as described in initial-secrets.
Paragraph (version B):
The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of TLS13) is used, using the hash
function from the negotiated cipher suite.  Other versions of TLS
MUST provide a similar function in order to be used QUIC.
Paragraph (version B):
The connection ID used with HKDF-Expand-Label is the Destination
Connection ID in the Initial packet sent by the client.  This will be
a randomly-selected value unless the client creates the Initial
packet after receiving a Retry packet, where the Destination
Connection ID is selected by the server.
Paragraph (version B):
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
Initial packets even where the TLS versions offered do not include
TLS 1.3.
Paragraph (version B):
test-vectors-initial contains test vectors for the initial packet
encryption.
Paragraph (version A):
QUIC packets are protected prior to applying packet number encryption
(pn-encrypt).  The unprotected packet number is part of the
associated data (A).  When removing packet protection, an endpoint
first removes the protection from the packet number.
Paragraph (version A):
All ciphersuites currently defined for TLS 1.3 - and therefore QUIC -
have a 16-byte authentication tag and produce an output 16 bytes
larger than their input.
Paragraph (version A):
The key and IV for the packet are computed as described in
encryption-keys.  The nonce, N, is formed by combining the packet
protection IV with the packet number.  The 64 bits of the
reconstructed QUIC packet number in network byte order are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded packet number and the IV forms the AEAD nonce.
Paragraph (version A):
The associated data, A, for the AEAD is the contents of the QUIC
header, starting from the flags octet in either the short or long
header, up to and including the unprotected packet number.
Paragraph (version A):
The input plaintext, P, for the AEAD is the content of the QUIC frame
following the header, as described in QUIC-TRANSPORT.
Paragraph (version B):
QUIC can use any of the ciphersuites defined in TLS13 with the
exception of TLS_AES_128_CCM_8_SHA256.  The AEAD for that
ciphersuite, AEAD_AES_128_CCM_8 CCM, does not produce a large enough
authentication tag for use with the header protection designs
provided (see header-protect).  All other ciphersuites defined in
TLS13 have a 16-byte authentication tag and produce an output 16
bytes larger than their input.
Paragraph (version B):
The input plaintext, P, for the AEAD is the payload of the QUIC
packet, as described in QUIC-TRANSPORT.
Paragraph (version A):
QUIC packet numbers are protected using a key that is derived from
the current set of secrets.  The key derived using the "pn" label is
used to protect the packet number from casual observation.  The
packet number protection algorithm depends on the negotiated AEAD.
Paragraph (version A):
Packet number protection is applied after packet protection is
applied (see aead).  The ciphertext of the packet is sampled and used
as input to an encryption algorithm.
Paragraph (version A):
In sampling the packet ciphertext, the packet number length is
assumed to be 4 octets (its maximum possible encoded length), unless
there is insufficient space in the packet for sampling.  The sampled
ciphertext starts after allowing for a 4 octet packet number unless
this would cause the sample to extend past the end of the packet.  If
the sample would extend past the end of the packet, the end of the
packet is sampled.
Paragraph (version A):
To ensure that this process does not sample the packet number, packet
number protection algorithms MUST NOT sample more ciphertext than the
minimum expansion of the corresponding AEAD.
Paragraph (version A):
Packet number protection is applied to the packet number encoded as
described in Section 4.8 of QUIC-TRANSPORT.  Since the length of the
packet number is stored in the first octet of the encoded packet
number, it may be necessary to progressively decrypt the packet
number.
Paragraph (version A):
Before a TLS ciphersuite can be used with QUIC, a packet protection
algorithm MUST be specifed for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs
are defined in AEAD), and AEAD_CHACHA20_POLY1305 (CHACHA).
Paragraph (version A):
This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and
AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit
AES AES in counter (CTR) mode.  AEAD_AES_256_GCM, and
AEAD_AES_256_CCM use 256-bit AES in CTR mode.
Paragraph (version A):
This algorithm samples 16 octets from the packet ciphertext.  This
value is used as the counter input to AES-CTR.
Paragraph (version A):
When AEAD_CHACHA20_POLY1305 is in use, packet number protection uses
the raw ChaCha20 function as defined in Section 2.4 of CHACHA.  This
uses a 256-bit key and 16 octets sampled from the packet protection
output.
Paragraph (version A):
The first 4 octets of the sampled ciphertext are interpreted as a
32-bit number in little-endian order and are used as the block count.
The remaining 12 octets are interpreted as three concatenated 32-bit
numbers in little-endian order and used as the nonce.
Paragraph (version B):
Parts of QUIC packet headers, in particular the Packet Number field,
are protected using a key that is derived separate to the packet
protection key and IV.  The key derived using the "quic hp" label is
used to provide confidentiality protection for those fields that are
not exposed to on-path elements.
Paragraph (version B):
This protection applies to the least-significant bits of the first
byte, plus the Packet Number field.  The four least-significant bits
of the first byte are protected for packets with long headers; the
five least significant bits of the first byte are protected for
packets with short headers.  For both header forms, this covers the
reserved bits and the Packet Number Length field; the Key Phase bit
is also protected for packets with a short header.
Paragraph (version B):
The same header protection key is used for the duration of the
connection, with the value not changing after a key update (see key-
update).  This allows header protection to be used to protect the key
phase.
Paragraph (version B):
This process does not apply to Retry or Version Negotiation packets,
which do not contain a protected payload or any of the fields that
are protected by this process.
Paragraph (version B):
Header protection is applied after packet protection is applied (see
aead).  The ciphertext of the packet is sampled and used as input to
an encryption algorithm.  The algorithm used depends on the
negotiated AEAD.
Paragraph (version B):
pseudo-hp shows a sample algorithm for applying header protection.
Removing header protection only differs in the order in which the
packet number length (pn_length) is determined.
Paragraph (version B):
fig-sample shows the protected fields of long and short headers
marked with an E.  fig-sample also shows the sampled fields.
Paragraph (version B):
Before a TLS ciphersuite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs
are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to
TLS selecting a ciphersuite, AES header protection is used (hp-aes),
matching the AEAD_AES_128_GCM packet protection.
Paragraph (version B):
The header protection algorithm uses both the header protection key
and a sample of the ciphertext from the packet Payload field.
Paragraph (version B):
The same number of bytes are always sampled, but an allowance needs
to be made for the endpoint removing protection, which will not know
the length of the Packet Number field.  In sampling the packet
ciphertext, the Packet Number field is assumed to be 4 bytes long
(its maximum possible encoded length).
Paragraph (version B):
An endpoint MUST discard packets that are not long enough to contain
a complete sample.
Paragraph (version B):
To ensure that sufficient data is available for sampling, packets are
padded so that the combined lengths of the encoded packet number and
protected payload is at least 4 bytes longer than the sample required
for header protection.  For the AEAD functions defined in TLS13,
which have 16-byte expansions and 16-byte header protection samples,
this results in needing at least 3 bytes of frames in the unprotected
payload if the packet number is encoded on a single byte, or 2 bytes
of frames for a 2-byte packet number encoding.
Paragraph (version B):
This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and
AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit
AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM, and
AEAD_AES_256_CCM use 256-bit AES in ECB mode.
Paragraph (version B):
When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw
ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a
256-bit key and 16 bytes sampled from the packet protection output.
Paragraph (version B):
The first 4 bytes of the sampled ciphertext are interpreted as a
32-bit number in little-endian order and are used as the block count.
The remaining 12 bytes are interpreted as three concatenated 32-bit
numbers in little-endian order and used as the nonce.
Paragraph (version A):
A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
keys to protect acknowledgements of 0-RTT packets.  Clients MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard
them.
Paragraph (version B):
A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
keys to protect acknowledgements of 0-RTT packets.  A client MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard
them.
Paragraph (version A):
Once the 1-RTT keys are established and the short header is in use,
it is possible to update the keys.  The KEY_PHASE bit in the short
header is used to indicate whether key updates have occurred.  The
KEY_PHASE bit is initially set to 0 and then inverted with each key
update key-update.
Paragraph (version A):
The KEY_PHASE bit allows a recipient to detect a change in keying
material without necessarily needing to receive the first packet that
triggered the change.  An endpoint that notices a changed KEY_PHASE
bit can update keys and decrypt the packet that contains the changed
bit, see key-update.
Paragraph (version A):
A receiving endpoint detects an update when the KEY_PHASE bit doesn't
match what it is expecting.  It creates a new secret (see Section 7.2
of TLS13) and the corresponding read key and IV.  If the packet can
be decrypted and authenticated using these values, then the keys it
uses for packet protection are also updated.  The next packet sent by
the endpoint will then use the new keys.
Paragraph (version A):
An endpoint doesn't need to send packets immediately when it detects
that its peer has updated keys.  The next packet that it sends will
simply use the new keys.  If an endpoint detects a second update
before it has sent any packets with updated keys it indicates that
its peer has updated keys twice without awaiting a reciprocal update.
An endpoint MUST treat consecutive key updates as a fatal error and
abort the connection.
Paragraph (version A):
An endpoint SHOULD retain old keys for a short period to allow it to
decrypt packets with smaller packet numbers than the packet that
triggered the key update.  This allows an endpoint to consume packets
that are reordered around the transition between keys.  Packets with
higher packet numbers always use the updated keys and MUST NOT be
decrypted with old keys.
Paragraph (version A):
Keys and their corresponding secrets SHOULD be discarded when an
endpoint has received all packets with packet numbers lower than the
lowest packet number used for the new key.  An endpoint might discard
keys if it determines that the length of the delay to affected
packets is excessive.
Paragraph (version B):
Once the 1-RTT keys are established and the short header is in use,
it is possible to update the keys.  The KEY_PHASE bit in the short
header is used to indicate whether key updates have occurred.  The
KEY_PHASE bit is initially set to 0 and then inverted with each key
update.
Paragraph (version B):
This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST
NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt
of a TLS KeyUpdate message as a connection error of type 0x10a,
equivalent to a fatal TLS alert of unexpected_message (see tls-
errors).
Paragraph (version B):
If the packet can be decrypted and authenticated using the updated
key and IV, then the keys the endpoint uses for packet protection are
also updated.  The next packet sent by the endpoint will then use the
new keys.
Paragraph (version B):
Endpoints MUST NOT send this extension in a TLS connection that does
not use QUIC (such as the use of TLS with TCP defined in TLS13).  A
fatal unsupported_extension alert MUST be sent if this extension is
received when the transport is not QUIC.
Paragraph (version B):
The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not
rely on this message to mark the end of 0-RTT data or to signal the
change to Handshake keys.
Paragraph (version B):
Clients MUST NOT send the EndOfEarlyData message.  A server MUST
treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
error of type PROTOCOL_VIOLATION.
Paragraph (version B):
As a result, EndOfEarlyData does not appear in the TLS handshake
transcript.
Paragraph (version A):
QUIC includes three defenses against this attack.  First, the packet
containing a ClientHello MUST be padded to a minimum size.  Second,
if responding to an unverified source address, the server is
forbidden to send more than three UDP datagrams in its first flight
(see Section 4.4.3 of QUIC-TRANSPORT).  Finally, because
acknowledgements of Handshake packets are authenticated, a blind
attacker cannot forge them.  Put together, these defenses limit the
level of amplification.
Paragraph (version A):
QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the
state of the connection.  If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity
without consequence.
Paragraph (version B):
QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the
state of the connection.  If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity
without consequence.
Paragraph (version A):
Packet number protection relies on the packet protection AEAD being a
pseudorandom function (PRF), which is not a property that AEAD
algorithms guarantee.  Therefore, no strong assurances about the
general security of this mechanism can be shown in the general case.
The AEAD algorithms described in this document are assumed to be
PRFs.
Paragraph (version A):
Use of the same key and ciphertext sample more than once risks
compromising packet number protection.  Protecting two different
packet numbers with the same key and ciphertext sample reveals the
exclusive OR of those packet numbers.  Assuming that the AEAD acts as
a PRF, if L bits are sampled, the odds of two ciphertext samples
being identical approach 2^(-L/2), that is, the birthday bound.  For
the algorithms described in this document, that probability is one in
2^64.
Paragraph (version A):
To prevent an attacker from modifying packet numbers, values of
packet numbers are transitively authenticated using packet
protection; packet numbers are part of the authenticated additional
data.  A falsified or modified packet number can only be detected
once the packet protection is removed.
Paragraph (version A):
An attacker can guess values for packet numbers and have an endpoint
confirm guesses through timing side channels.  If the recipient of a
packet discards packets with duplicate packet numbers without
attempting to remove packet protection they could reveal through
timing side-channels that the packet number matches a received
packet.  For authentication to be free from side-channels, the entire
process of packet number protection removal, packet number recovery,
and packet protection removal MUST be applied together without timing
and other side-channels.
Paragraph (version B):
Use of the same key and ciphertext sample more than once risks
compromising header protection.  Protecting two different headers
with the same key and ciphertext sample reveals the exclusive OR of
the protected fields.  Assuming that the AEAD acts as a PRF, if L
bits are sampled, the odds of two ciphertext samples being identical
approach 2^(-L/2), that is, the birthday bound.  For the algorithms
described in this document, that probability is one in 2^64.
Paragraph (version B):
To prevent an attacker from modifying packet headers, the header is
transitively authenticated using packet protection; the entire packet
header is part of the authenticated additional data.  Protected
fields that are falsified or modified can only be detected once the
packet protection is removed.
Paragraph (version B):
In using TLS, the central key schedule of TLS is used.  As a result
of the TLS handshake messages being integrated into the calculation
of secrets, the inclusion of the QUIC transport parameters extension
ensures that handshake and 1-RTT keys are not the same as those that
might be produced by a server running TLS over TCP.  However, 0-RTT
keys only include the ClientHello message and might therefore use the
same secrets.  To avoid the possibility of cross-protocol key
synchronization, additional measures are provided to improve key
separation.
Paragraph (version B):
The QUIC packet protection keys and IVs are derived using a different
label than the equivalent keys in TLS.
Paragraph (version B):
The initial secrets also use a key that is specific to the negotiated
QUIC version.  New QUIC versions SHOULD define a new salt value used
in calculating initial secrets.