Draft: draft-ietf-quic-tls

Commentary: I believe these are all editorial , but please review . 
 Thanks for doing this  . It 's telling how often I make the same mistakes . I 'd say " at least I was consistent , but I do n't think that I was :) Just a few tweaks and we 're good .
Paragraph (version A):
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org [1]), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Paragraph (version B):
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Paragraph (version A):
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):
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 A):
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 0-RTT; the latter
provides perfect forward secrecy (PFS) when the (EC)DHE keys are
destroyed.
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):
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 and is an error if
they are received from the TLS stack.
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 A):
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):
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 A):
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 which the client can send in 0-RTT is controlled by the
"initial_max_data" transport parameter supplied by the server.
Paragraph (version A):
Servers MUST NOT send the "early_data" extension with a
max_early_data_size 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 A):
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):
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 A):
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 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):
The value of initial_salt is a 20 byte 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 packets from
future versions.
Paragraph (version B):
The value of initial_salt is a 20-byte 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 packets from
future versions.
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 A):
QUIC can use any of the ciphersuites defined in TLS13 with the
exception of TLS_AES_128_CCM_8_SHA256.  A ciphersuite MUST NOT be
negotiated unless a header protection scheme is defined for the
ciphersuite.  This document defines a header protection scheme for
all ciphersuites defined in TLS13 aside from
TLS_AES_128_CCM_8_SHA256.  These ciphersuites have a 16-byte
authentication tag and produce an output 16 bytes larger than their
input.
Paragraph (version A):
An endpoint MUST NOT reject a ClientHello that offers a
ciphersuite that it does not support, or it would be impossible to
deploy a new ciphersuite.  This also applies to
TLS_AES_128_CCM_8_SHA256.
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):
All QUIC packets other than Version Negotiation are protected with an
AEAD algorithm (AEAD).  Prior to establishing a shared secret,
packets are protected with AEAD_AES_128_GCM.  Retry packets use the
AEAD for integrity protection only, as described in retry-integrity.
Initial packets use 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):
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 A):
The associated data, A, for the AEAD is the contents of the QUIC
header, starting from the flags byte in either the short or long
header, up to and including the unprotected packet number.
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):
The output of this algorithm is a 5 byte mask which is applied to the
protected header fields using exclusive OR.  The least significant
bits of the first byte of the packet are masked by the least
significant bits of the first mask byte, and the packet number is
masked with the remaining bytes.  Any unused bytes of mask that might
result from a shorter packet number encoding are unused.
Paragraph (version B):
The output of this algorithm is a 5-byte mask which is applied to the
protected header fields using exclusive OR.  The least significant
bits of the first byte of the packet are masked by the least
significant bits of the first mask byte, and the packet number is
masked with the remaining bytes.  Any unused bytes of mask that might
result from a shorter packet number encoding are unused.
Paragraph (version A):
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 (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):
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 A):
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 ciphersuites 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):
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 A):
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):
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 A):
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 AES in
electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES
in ECB mode.
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 A):
The ODCID Len contains the length in bytes of the Original
Destination Connection ID field that follows it, encoded as an
8-bit unsigned integer.
Paragraph (version A):
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
Len. The presence of this field mitigates an off-path attacker's
ability to inject a Retry packet.
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 A):
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 prior 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):
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 A):
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 last 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):
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 A):
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 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):
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 A):
QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters.  The TLS handshake provides preliminary
values for QUIC transport parameters and allows a server to perform
return routability checks on clients.
Paragraph (version A):
QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation.  TLS uses Application Layer Protocol
Negotiation (ALPN) 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):
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 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 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.
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.