Draft: rfc9001

Commentary: Lots of missing articles here .
Paragraph (version A):
The TLS component provides a series of updates to the QUIC
component, including (a) new packet protection keys to install (b)
state changes such as handshake completion, the server
certificate, etc.
Paragraph (version B):
The TLS component provides a series of updates to the QUIC
component, including (a) new packet protection keys to install and
(b) state changes such as handshake completion, the server
certificate, etc.
Paragraph (version A):
Before starting the handshake QUIC provides TLS with the transport
parameters (see quic_parameters) that it wishes to carry.
Paragraph (version B):
Before starting the handshake, QUIC provides TLS with the transport
parameters (see quic_parameters) that it wishes to carry.
Paragraph (version A):
At any time, the TLS stack at an endpoint will have a current sending
encryption level and receiving encryption level.  TLS encryption
levels determine the QUIC packet type and keys that are used for
protecting data.
Paragraph (version B):
At any time, the TLS stack at an endpoint will have a current sending
encryption level and a receiving encryption level.  TLS encryption
levels determine the QUIC packet type and keys that are used for
protecting data.
Paragraph (version A):
A server MUST NOT use post-handshake client authentication (as
defined in Section 4.6.2 of TLS13), because the multiplexing offered
by QUIC prevents clients from correlating the certificate request
with the application-level event that triggered it (see HTTP2-TLS13).
More specifically, servers MUST NOT send post-handshake TLS
CertificateRequest messages, and clients MUST treat receipt of such
messages as a connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
A server MUST NOT use post-handshake client authentication (as
defined in Section 4.6.2 of TLS13) because the multiplexing offered
by QUIC prevents clients from correlating the certificate request
with the application-level event that triggered it (see HTTP2-TLS13).
More specifically, servers MUST NOT send post-handshake TLS
CertificateRequest messages, and clients MUST treat receipt of such
messages as a connection error of type PROTOCOL_VIOLATION.
Paragraph (version A):
The TLS early_data extension in the NewSessionTicket message is
defined to convey (in the max_early_data_size parameter) the amount
of TLS 0-RTT data the server is willing to accept.  QUIC does not use
TLS 0-RTT data.  QUIC uses 0-RTT packets to carry early data.
Accordingly, the max_early_data_size parameter is repurposed to hold
a sentinel value 0xffffffff to indicate that the server is willing to
accept QUIC 0-RTT data; to indicate that the server does not accept
0-RTT data, the early_data extension is omitted from the
NewSessionTicket.  The amount of data that the client can send in
QUIC 0-RTT is controlled by the initial_max_data transport parameter
supplied by the server.
Paragraph (version B):
The TLS early_data extension in the NewSessionTicket message is
defined to convey (in the max_early_data_size parameter) the amount
of TLS 0-RTT data the server is willing to accept.  QUIC does not use
TLS 0-RTT data.  QUIC uses 0-RTT packets to carry early data.
Accordingly, the max_early_data_size parameter is repurposed to hold
a sentinel value 0xffffffff to indicate that the server is willing to
accept QUIC 0-RTT data.  To indicate that the server does not accept
0-RTT data, the early_data extension is omitted from the
NewSessionTicket.  The amount of data that the client can send in
QUIC 0-RTT is controlled by the initial_max_data transport parameter
supplied by the server.
Paragraph (version A):
This secret is determined by using HKDF-Extract (see Section 2.2 of
HKDF) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
an input keying material (IKM) of the Destination Connection ID
field.  This produces an intermediate pseudorandom key (PRK) that is
used to derive two separate secrets for sending and receiving.
Paragraph (version B):
This secret is determined by using HKDF-Extract (see Section 2.2 of
HKDF) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
the input keying material (IKM) of the Destination Connection ID
field.  This produces an intermediate pseudorandom key (PRK) that is
used to derive two separate secrets for sending and receiving.
Paragraph (version A):
It is also possible for the attacker to tamper with data that is
carried in Handshake packets, but because that tampering requires
modifying TLS handshake messages, that tampering will cause the TLS
handshake to fail.
Paragraph (version B):
It is also possible for the attacker to tamper with data that is
carried in Handshake packets, but because that sort of tampering
requires modifying TLS handshake messages, any such tampering will
cause the TLS handshake to fail.
Paragraph (version A):
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):
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):
During a key update, the time taken to generate new keys could reveal
through timing side-channels that a key update has occurred.
Alternatively, where an attacker injects packets, this side channel
could reveal the value of the Key Phase on injected packets.  After
receiving a key update, an endpoint SHOULD generate and save the next
set of receive packet protection keys, as described in receive-key-
generation.  By generating new keys before a key update is received,
receipt of packets will not create timing signals that leak the value
of the Key Phase.
Paragraph (version B):
During a key update, the time taken to generate new keys could reveal
through timing side channels that a key update has occurred.
Alternatively, where an attacker injects packets, this side channel
could reveal the value of the Key Phase on injected packets.  After
receiving a key update, an endpoint SHOULD generate and save the next
set of receive packet protection keys, as described in receive-key-
generation.  By generating new keys before a key update is received,
receipt of packets will not create timing signals that leak the value
of the Key Phase.
Paragraph (version A):
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.  To avoid the
possibility of cross-protocol key synchronization, additional
measures are provided to improve key separation.
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 the handshake and 1-RTT keys are not the same as those
that might be produced by a server running TLS over TCP.  To avoid
the possibility of cross-protocol key synchronization, additional
measures are provided to improve key separation.