Draft: draft-ietf-quic-tls

Commentary: In a typical multi - user setting , the adversary is assumed to perform some ( massive ) amount of offline work to break the integrity of a single random connection . Each user is represented as a unique ( key , nonce ) pair . In considering the same threat model , we must treat each key resulting from a KeyUpdate event as a unique user . As a result , roughly speaking , bounds implied from the multi - user setting imply ( minimally ) for the lifetime of a single connection .    . [ 1 ] present tight multi - user security bounds for randomized AES - GCM ( as is used in TLS 1.3 and QUIC ) , so we can take advantage of those for per - connection integrity limits . ( Confidentiality limits still apply per - key , as the analysis considers only encrypted blocks , which would not change if an endpoint updated its key or created a new connection . ) In contrast , there are no multi - user security bounds for AEADCHACHA20POLY1305 or AEADAES128_CCM , so we must use the single - user bounds in their stead . [ 1 ] 
 ( Thanks , 
 TL;DR : We should likely change per - key integrity limits to per - connection limits , with different margins . Ongoing analysis efforts with    ,   ,   , and   revealed that QUIC should consider changing its confidentiality and integrity limits to account for multi - user security settings . As some background , the existing limits in draft - ietf - quic - tls apply to a single key . They are derived from several existing analyses in the literature , including , , , and . Concretely , they seek to bound an attacker ’s advantage in breaking the security guarantees of the AEAD algorithm for a specific key in question . When a Key Update occurs , endpoints receive a new key , which resets the encryption and forgery attempt counters for this new key . This analysis fails to account for settings in which there are multiple , independent users of an AEAD algorithm , each with their own unique key . In these so - called “ multi - user ” settings , the attacker is allowed to perform some amount of offline work to help accelerate any attack on the AEAD algorithm . However , rather than target a single user ’s specific key , they are tasked with distinguishing all traffic ( under all keys ) from an equal amount of random bits . In the public - key setting , Bellare et al . prove that the success probability in attacking one of the many independent users ( or keys ) is bounded by the success probability of attacking a single user ( or key ) multiplied by the number of users present . ( This result extends to the symmetric - key setting . ) Why is this important ? Each key used throughout the duration of a single connection is effectively a distinct user . This means that the attacker ’s probability of success against any key in a connection must be considered across all keys . Or , more precisely , the integrity limit counters MUST NOT reset across Key Updates . ( Confidentiality limits still apply for individual keys , rather than across Key Updates , since there ’s no functional difference in the analyses between tearing down a connection and performing an update . The analyses consider encryption as a function of plaintext blocks protected . Thus , users that need to send N blocks of data will send N blocks of data , whether it be in one connection with many keys , or many connections with a single key . ) Fortunately , this may not be much of a problem in practice .     provide tight multi - user security bounds for AES - GCM with nonce randomization ( as is used by TLS 1.3 and QUIC ) , and those bounds permit a higher amount than previously established for a single key . However , to the best of our knowledge , there are no multi - user security analyses giving tighter bounds than the generic analyses of AEADCHACHA20POLY1305 and AEADAES128CCM . Thus , for the time being , we are stuck with the single - user integrity limits spread across Key Updates for these AEADs . Recognizing that this is a relatively new area for research , we are aiming to be quite conservative in setting limits , though we do allow an attacker a greater advantage in this multi - user attack than we would for a single connection . We may relax these limits if and when future analyses demonstrate that it ’s safe to do so . Note that this is not an ideal outcome . A “ true ” multi - user setting would consider all users , i.e. , all keys in all connections used by all QUIC clients and servers , simultaneously . However , endpoints can not obtain such a global view of the Internet , and thus can not make realistic parameter choices for bounds based on the number of users . The compromise struck in this PR is to consider a narrow view of multi - user security , i.e. , one in which the only “ users ” in a connection are those introduced by Key Update messages . ( This is certainly a gap in the literature worth exploring in the future . ) We also recommend setting very strong targets for attacker advantage for a single key , which we estimate will ensure that an attacker still has limited advantage in the multi - user setting . Felix ,  , and I did our best to document the basis for the analysis in this issue ( and corresponding PR ) in this CFRG I - D : We believe the foundations for this analysis are sound , though we are of course happy to learn if we made arithmetic mistakes . :-) [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] 
 There has been some discussion and indicates that this would be a design change . Is there support for this issue and ? 
 For clarity , yes , this would be a design change . 
 IANAC ( disclaimer : I Am Not A Cryptographer ) From my understanding of the issue , it seems that  does not provide the security guarantees it claims , when in the presence of a high number of received forged packets . In that instance , QUIC provides less security than TLS 1.3 . I think that we should fix this issue in QUICv1 , since we are chartered to produce a protocol that is at least as safe as TLS1.3 . PR seems like the right direction to me , especially if folks more knowledgeable in cryptography think it 's correct . 
 There seems to be emerging consensus for the associated PR , so this has been marked as proposal - ready 
 Overall I think this is ready to merge . I left some small editorial nits
Paragraph (version B):
For brevity, the acronym TLS is used to refer to TLS 1.3, though a
newer version could be used; see tls-version.
Paragraph (version B):
The TLS authenticated key exchange occurs between two endpoints:
client and server.  The client initiates the exchange and the server
responds.  If the key exchange completes successfully, both client
and server will agree on a secret.  TLS supports both pre-shared key
(PSK) and Diffie-Hellman over either finite fields or elliptic curves
((EC)DHE) key exchanges.  PSK is the basis for Early Data (0-RTT);
the latter provides perfect forward secrecy (PFS) when the (EC)DHE
keys are destroyed.
Paragraph (version A):
In order to drive the handshake, TLS depends on being able to send
and receive handshake messages.  There are two basic functions on
this interface: one where QUIC requests handshake messages and one
where QUIC provides handshake packets.
Paragraph (version B):
In order to drive the handshake, TLS depends on being able to send
and receive handshake messages.  There are two basic functions on
this interface: one where QUIC requests handshake messages and one
where QUIC provides bytes that comprise handshake messages.
Paragraph (version A):
Each encryption level is associated with a different sequence of
bytes, which is reliably transmitted to the peer in CRYPTO frames.
When TLS provides handshake bytes to be sent, they are appended to
the current flow.  Any packet that includes the CRYPTO frame is
protected using keys from the corresponding encryption level.  Four
encryption levels are used, producing keys for Initial, 0-RTT,
Handshake, and 1-RTT packets.  CRYPTO frames are carried in just
three of these levels, omitting the 0-RTT level.  These four levels
correspond to three packet number spaces: Initial and Handshake
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
Paragraph (version B):
Each encryption level is associated with a different sequence of
bytes, which is reliably transmitted to the peer in CRYPTO frames.
When TLS provides handshake bytes to be sent, they are appended to
the handshake bytes for the current encryption level.  The encryption
level then determines the type of packet that the resulting CRYPTO
frame is carried in; see packet-types-keys.
Paragraph (version B):
Four encryption levels are used, producing keys for Initial, 0-RTT,
Handshake, and 1-RTT packets.  CRYPTO frames are carried in just
three of these levels, omitting the 0-RTT level.  These four levels
correspond to three packet number spaces: Initial and Handshake
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
Paragraph (version A):
If the packet was in the TLS receiving encryption level, sequence
the data into the input flow as usual.  As with STREAM frames, the
offset is used to find the proper location in the data sequence.
If the result of this process is that new data is available, then
it is delivered to TLS in order.
Paragraph (version B):
QUIC is only capable of conveying TLS handshake records in CRYPTO
frames.  TLS alerts are turned into QUIC CONNECTION_CLOSE error
codes; see tls-errors.  TLS application data and other message types
cannot be carried by QUIC at any encryption level; it is an error if
they are received from the TLS stack.
Paragraph (version B):
If the packet uses the current TLS receiving encryption level,
sequence the data into the input flow as usual.  As with STREAM
frames, the offset is used to find the proper location in the data
sequence.  If the result of this process is that new data is
available, then it is delivered to TLS in order.
Paragraph (version A):
If the packet is from a new encryption level, it is saved for
later processing by TLS.  Once TLS moves to receiving from this
encryption level, saved data can be provided.  When providing data
from any new encryption level to TLS, if there is data from a
previous encryption level that TLS has not consumed, this MUST be
treated as a connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
The content of CRYPTO frames might either be processed incrementally
by TLS or buffered until complete messages or flights are available.
TLS is responsible for buffering handshake bytes that have arrived in
order.  QUIC is responsible for buffering handshake bytes that arrive
out of order or for encryption levels that are not yet ready.  QUIC
does not provide any means of flow control for CRYPTO frames; see
Section 7.5 of QUIC-TRANSPORT.
Paragraph (version A):
exchange-summary summarizes the exchange between QUIC and TLS for
both client and server.  Each arrow is tagged with the encryption
level used for that transmission.
Paragraph (version B):
exchange-summary summarizes the exchange between QUIC and TLS for
both client and server.  Solid arrows indicate packets that carry
handshake data; dashed arrows show where application data can be
sent.  Each arrow is tagged with the encryption level used for that
transmission.
Paragraph (version A):
A badly configured TLS implementation could negotiate TLS 1.2 or
another older version of TLS.  An endpoint MUST terminate the
connection if a version of TLS older than 1.3 is negotiated.
Paragraph (version B):
Clients MUST NOT offer TLS versions older than 1.3.  A badly
configured TLS implementation could negotiate TLS 1.2 or another
older version of TLS.  An endpoint MUST terminate the connection if a
version of TLS older than 1.3 is negotiated.
Paragraph (version B):
A typical TLS ClientHello can easily fit into a 1200-byte packet.
However, in addition to the overheads added by QUIC, there are
several variables that could cause this limit to be exceeded.  Large
session tickets, 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 B):
Where servers provide certificates for authentication, the size of
the certificate chain can consume a large number of bytes.
Controlling the size of certificate chains is critical to
performance in QUIC as servers are limited to sending 3 bytes for
every byte received prior to validating the client address; see
Section 8.1 of QUIC-TRANSPORT.  The size of a certificate chain
can be managed by limiting the number of names or extensions;
using keys with small public key representations, like ECDSA; or
by using certificate compression COMPRESS.
Paragraph (version B):
The 0-RTT feature in QUIC allows a client to send application data
before the handshake is complete.  This is made possible by reusing
negotiated parameters from a previous connection.  To enable this,
0-RTT depends on the client remembering critical parameters and
providing the server with a TLS session ticket that allows the server
to recover the same information.
Paragraph (version B):
This information includes parameters that determine TLS state, as
governed by TLS13, QUIC transport parameters, the chosen application
protocol, and any information the application protocol might need;
see app-0rtt.  This information determines how 0-RTT packets and
their contents are formed.
Paragraph (version B):
To ensure that the same information is available to both endpoints,
all information used to establish 0-RTT comes from the same
connection.  Endpoints cannot selectively disregard information that
might alter the sending or processing of 0-RTT.
Paragraph (version B):
TLS13 sets a limit of 7 days on the time between the original
connection and any attempt to use 0-RTT.  There are other constraints
on 0-RTT usage, notably those caused by the potential exposure to
replay attack; see replay.
Paragraph (version B):
To communicate their willingness to process 0-RTT data, servers send
a NewSessionTicket message that contains the early_data extension
with a max_early_data_size of 0xffffffff.  The TLS
max_early_data_size parameter is not used in QUIC.  The amount of
data that the client can send in 0-RTT is controlled by the
initial_max_data transport parameter supplied by the server.
Paragraph (version B):
Servers MUST NOT send the early_data extension with a
max_early_data_size field set to any value other than 0xffffffff.  A
client MUST treat receipt of a NewSessionTicket that contains an
early_data extension with any other value as a connection error of
type PROTOCOL_VIOLATION.
Paragraph (version B):
A client that wishes to send 0-RTT packets uses the early_data
extension in the ClientHello message of a subsequent handshake; see
Section 4.2.10 of TLS13.  It then sends application data in 0-RTT
packets.
Paragraph (version B):
A client that attempts 0-RTT might also provide an address validation
token if the server has sent a NEW_TOKEN frame; see Section 8.1 of
QUIC-TRANSPORT.
Paragraph (version B):
A client MAY reattempt 0-RTT if it receives a Retry or Version
Negotiation packet.  These packets do not signify rejection of 0-RTT.
Paragraph (version B):
When a server receives a ClientHello with the early_data extension,
it has to decide whether to accept or reject early data from the
client.  Some of this decision is made by the TLS stack (e.g.,
checking that the cipher suite being resumed was included in the
ClientHello; see Section 4.2.10 of TLS13).  Even when the TLS stack
has no reason to reject early data, the QUIC stack or the application
protocol using QUIC might reject early data because the configuration
of the transport or application associated with the resumed session
is not compatible with the server's current configuration.
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 Initial
packets.  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 B):
The HelloRetryRequest message (see Section 4.1.4 of TLS13) can be
used to request that a client provide new information, such as a key
share, or to validate some characteristic of the client.  From the
perspective of QUIC, HelloRetryRequest is not differentiated from
other cryptographic handshake messages that are carried in Initial
packets.  Although it is in principle possible to use this feature
for address verification, QUIC implementations SHOULD instead use the
Retry feature; see Section 8.1 of QUIC-TRANSPORT.
Paragraph (version A):
The Authentication Encryption with Associated Data (AEAD) AEAD
function used for QUIC packet protection is the AEAD that is
negotiated for use with the TLS connection.  For example, if TLS is
using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is
used.
Paragraph (version A):
All QUIC packets other than Version Negotiation and Retry packets are
protected with an AEAD algorithm AEAD.  Prior to establishing a
shared secret, packets are protected with AEAD_AES_128_GCM and a key
derived from the Destination Connection ID in the client's first
Initial packet (see initial-secrets).  This provides protection
against off-path attackers and robustness against QUIC version
unaware middleboxes, but not against on-path attackers.
Paragraph (version B):
The Authenticated Encryption with Associated Data (AEAD; see AEAD)
function used for QUIC packet protection is the AEAD that is
negotiated for use with the TLS connection.  For example, if TLS is
using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM
function is used.
Paragraph (version B):
QUIC can use any of the cipher suites defined in TLS13 with the
exception of TLS_AES_128_CCM_8_SHA256.  A cipher suite MUST NOT be
negotiated unless a header protection scheme is defined for the
cipher suite.  This document defines a header protection scheme for
all cipher suites defined in TLS13 aside from
TLS_AES_128_CCM_8_SHA256.  These cipher suites have a 16-byte
authentication tag and produce an output 16 bytes larger than their
input.
Paragraph (version B):
An endpoint MUST NOT reject a ClientHello that offers a cipher
suite that it does not support, or it would be impossible to
deploy a new cipher suite.  This also applies to
TLS_AES_128_CCM_8_SHA256.
Paragraph (version B):
The associated data, A, for the AEAD is the contents of the QUIC
header, starting from the first byte of either the short or long
header, up to and including the unprotected packet number.
Paragraph (version A):
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):
Parts of QUIC packet headers, in particular the Packet Number field,
are protected using a key that is derived separately from 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):
Before a TLS cipher suite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that cipher suite.
This document defines algorithms for AEAD_AES_128_GCM,
AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined
in AEAD), and AEAD_CHACHA20_POLY1305 (defined in CHACHA).  Prior to
TLS selecting a cipher suite, AES header protection is used (hp-aes),
matching the AEAD_AES_128_GCM packet protection.
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.  The cipher suites defined in TLS13 - other
than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme
is not defined in this document - 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):
For example, for a packet with a short header, an 8-byte connection
ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to
28 inclusive (using zero-based indexing).
Paragraph (version B):
This section defines the packet protection algorithm for
AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES in electronic
code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES in ECB mode.
AES is defined in AES.
Paragraph (version B):
The ODCID Length field contains the length in bytes of the
Original Destination Connection ID field that follows it, encoded
as an 8-bit unsigned integer.
Paragraph (version B):
The Original Destination Connection ID contains the value of the
Destination Connection ID from the Initial packet that this Retry
is in response to.  The length of this field is given in ODCID
Length.  The presence of this field mitigates an off-path
attacker's ability to inject a Retry packet.
Paragraph (version B):
An endpoint MUST NOT initiate a key update prior to having confirmed
the handshake (handshake-confirmed).  An endpoint MUST NOT initiate a
subsequent key update unless it has received an acknowledgment for a
packet that was sent protected with keys from the current key phase.
This ensures that keys are available to both peers before another key
update can be initiated.  This can be implemented by tracking the
lowest packet number sent with each key phase, and the highest
acknowledged packet number in the 1-RTT space: once the latter is
higher than or equal to the former, another key update can be
initiated.
Paragraph (version B):
A peer is permitted to initiate a key update after receiving an
acknowledgement of a packet in the current key phase.  An endpoint
detects a key update when processing a packet with a key phase that
differs from the value used to protect the last packet it sent.  To
process this packet, the endpoint uses the next packet protection key
and IV.  See receive-key-generation for considerations about
generating these keys.
Paragraph (version B):
Any TLS cipher suite that is specified for use with QUIC MUST define
limits on the use of the associated AEAD function that preserves
margins for confidentiality and integrity.  That is, limits MUST be
specified for the number of packets that can be authenticated and for
the number of packets that can fail authentication.  Providing a
reference to any analysis upon which values are based - and any
assumptions used in that analysis - allows limits to be adapted to
varying usage conditions.
Paragraph (version B):
Certain aspects of the TLS handshake are different when used with
QUIC.
Paragraph (version B):
QUIC also requires additional features from TLS.  In addition to
negotiation of cryptographic parameters, the TLS handshake carries
and authenticates values for QUIC transport parameters.
Paragraph (version B):
QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation.  TLS uses Application Layer Protocol
Negotiation (ALPN) to select an application protocol.  Unless another
mechanism is used for agreeing on an application protocol, endpoints
MUST use ALPN for this purpose.
Paragraph (version B):
TLS session tickets and address validation tokens are used to
carry QUIC configuration information between connections.
Specifically, to enable a server to efficiently recover state that
is used in connection establishment and address validation.  These
MUST NOT be used to communicate application semantics between
endpoints; clients MUST treat them as opaque values.  The
potential for reuse of these tokens means that they require
stronger protections against replay.
Paragraph (version B):
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 times as many bytes as the number
of bytes it has received (see Section 8.1 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.