Using TLS to Secure QUIC
draft-ietf-quic-tls-34

[Ballot comment]
Thanks for the updates and discussion prompted by my initial review
comments.  For reference, those comments and the corresponding github
issue links are available at
https://mailarchive.ietf.org/arch/msg/quic/D4Bc7u5BBAbiZMSOkirIS5uM5is/

[Ballot comment]
[edited to add two comments: one on the Abstract and one toplevel
comment about ClientHello reuse/change after Retry.]

I've noted some potential editorial improvements in a local copy of the
markdown and will make a pull request with the suggested changes.

The length of the remaining comments notwithstanding, this document is
generally quite well done and a sizeable chunk of my comments are just
relating to subtleties of TLS and our interaction with it; I plan to
change my position to Yes once the Discuss points have been
appropriately discussed.  My apologies in advance to the chairs who will
have to open github issues for all
of these!

We may want to make a pass through the document to normalize the way in
which we discuss 0-RTT.  For example, Section 4.5 mentions that
resumption "can be used without also enabling 0-RTT" as if 0-RTT should
be off by default, but much of the previous discussion involving 0-RTT
treats it as an expected and normal part of the protocl.  (For what
little it's worth, my own personal preference leans towards how RFC 8446
treats 0-RTT data, as an optional and potentially dangerous thing that
should be off by default and only enabled after careful consideration,
though in some ways it actually seems significantly safer in QUIC than
TLS.  Regardless, I do not see any value in re-litigating the question
at this point; I'm just hoping that the document can be consistent about
it.)

I think we would benefit from some clarity about the client's response
to a Retry.  Specifically, is the client expected to use the same
ClientHello from the first Initial, in the Initial generated in response
to the Retry?  I did not see any notes about, e.g., transport parameter
values sent by the client changing in response to Retry, and since the
Connection IDs change it seems that we might fall under the Random (and
key share) reuse considerations for TLS.

Abstract

I think this document also specifies some generic bits about how QUIC
uses cryptography, that are not directly related to TLS integration.

Section 2.1

  The 0-RTT handshake is only possible if the client and server have
  previously communicated.  In the 1-RTT handshake, the client is

Pedantically, RFC 8446 does allow the exchange of 0-RTT data for
externally provisioned PSKs (non-resumption), provided that the
necessary parameters are provisioned along with the PSK.

Section 3

Figure 3 shows "TLS Alerts" as being carried over QUIC Transport, but
per §4.8 TLS alerts are translated into QUIC connection errors and are
not sent natively.

  *  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.

I think that if we're going to talk about passing the server certificate
between TLS and QUIC components, we should be very clear about where/how
certificate validation occurs.  For example, it would be pretty
disasterous if TLS passed the certificate to QUIC expecting that QUIC
would do any validation of the peer identity, but QUIC assumed that TLS
would only provide a validated certificate.  Perhaps in §4.1 when we
mention the potential for "additional functions [...] to configure TLS",
we might mention "including certificate validation", if appropriate?

Section 4

  QUIC carries TLS handshake data in CRYPTO frames, each of which
  consists of a contiguous block of handshake data identified by an
  offset and length.  Those frames are packaged into QUIC packets and
  encrypted under the current TLS encryption level.  [...]

I'm not sure I understand the benefit of specifically calling this a
"TLS encryption level".  While it's true that the keys are being
provided by TLS, the cryptographic mechanisms being used are applied by
QUIC.  Furthermore, there's a 1:1 correspondence between the QUIC and
TLS encryption levels, so perhaps it is acceptable to not have a
qualifier at all (for just "under the current encryption level").

  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 packet
  number space.  [...]

I'm a bit confused as to what analogy is being made here.  It seems to
be equating TLS records and QUIC frames, but of course multiple DTLS
records can appear in a single UDP datagram, so the difference between
QUIC and DTLS does not seem quite so large as depicted here.  Of course,
if the analogy is supposed to be between TLS handshake messages and QUIC
frames, or TLS records and QUIC packets, then things would be different,
but I'm not sure what this is intended to say.

Section 4.1.3

  Once the handshake is complete, TLS becomes passive.  TLS can still
  receive data from its peer and respond in kind, but it will not need
  to send more data unless specifically requested - either by an
  application or QUIC.  [...]

(pedantic note) In some sense this is a forward-looking statement *about
TLS*, which is not something the QUIC WG is chartered to work on.  That
said, because of how TLS feature negotiation is done, any new kind of
data spontaneously emitted by TLS would need to be negotiated with an
extension in the handshake, but I don't think we are attempting to
specifically lock down the set of extensions in the TLS handshake for
QUIC connections, so in theory a change to the TLS implementation
defaults could result in QUIC connections that have TLS spontaneously
emit data.  On the gripping hand, I don't really see much need for a
text change here.

Section 4.1.5

Why does the server call Get Handshake twice between receiving the
client Initial and the client's second Hansdhake flight?  IIUC the
interface says that additional handshake data will only be supplied from
TLS in response to input handshake data (and thus, not in response to
TLS generating new keys, which is what the figure suggests to be a
proximal trigger for the second Get Handshake).  We should probably be
careful that the interfaces we document are capable of describing the
case where TLS provides both new keys and handshake bytes, and the
handshake bytes are split across encryption levels (as is the case for
the server's first flight), which may be the motivation for the two Get
Handshake calls depicted here.

Similarly, it's my understanding that the client should still call Get
Handshake after receiving the Initial (but would receive only keys and
not output handshake data at that point).  I'm not sure whether the
figure should indicate that (ineffectual) Get Handshake call.

Should the figure indicate the Handshake Confirmed operation in addition
to Handshake Complete?

Section 4.3

  The TLS implementation does not need to ensure that the ClientHello
  is sufficiently large.  QUIC PADDING frames are added to increase the
  size of the packet as necessary.

Should we reference Section 8.1 of [QUIC-TRANSPORT] for "sufficiently
large"?

Section 4.4

  A client MUST authenticate the identity of the server.  This
  typically involves verification that the identity of the server is
  included in a certificate and that the certificate is issued by a
  trusted entity (see for example [RFC2818]).

I assume that, per normal TLS semantics, this requirement can be met by
PSK authentication as well as certificate authentication.  PSK
authentication has often been an aspect of TLS that has not received
substantial attention, so we may want to preemtively pay some attention
to the PSK case.

  A server MUST NOT use post-handshake client authentication (as
  defined in Section 4.6.2 of [TLS13]), because the multiplexing

Do we want to say anything about not sending the "post_handshake_auth"
extension (defined in the numerologically similar section 4.2.6 of RFC
8446)?  Strictly speaking we don't need to say anything, but efficient
implementations would satisfy the existing QUIC requirement by not
sending the extension and relying on the TLS stack to reject
post-handshake authentication since the extension had not been offered.

Section 4.8

  The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
  generate alerts at the "warning" level.

This seems to be making a normative restriction on the operation of TLS,
which is not in the QUIC WG charter.  Perhaps we should instead
constrain the QUIC implementation to not accept such alerts (and what to
do if they are received) and note that the only closure alerts in RFC
8446 are "close_notify" and "user_cancelled", which are replaced by
equivalent QUIC-level functionality.

Section 4.9

  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

(nit/editorial) I believe that the "both" is meant to apply to "received
and acknowledged" and "when all CRYTO frames [...] have been
acknowledged", but the current formulation does not have parallel
structure between those clauses, so it ends up reading more naturally as
saying that the "both" refers to "received" and "acknowledged".  I don't
have a simple suggestion for fixing it, though (it might require a
significant restructuring to fix), so I'm leaving it here in my comments
rather than incorporating a fix into my editorial PR.  (Any drastic
rewording might consider the rest of the paragraph as well, as it seems
to leave the reader without a clear sense for when it definitely is safe
to discard old keys.)

  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.

Is there anything useful to say about whether it is advisable to make
retransmission packets have the same size as the original transmission?
("No" is a fine answer.)

Section 4.9.3

  0-RTT keys to allow decrypting reordered packets without requiring
  their contents to be retransmitted with 1-RTT keys.  After receiving
  a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;
  the RECOMMENDED time period is three times the Probe Timeout (PTO,
  see [QUIC-RECOVERY]).  A server MAY discard 0-RTT keys earlier if it

Just to check my understanding, the two endpoints will not necessarily
agree on the value of PTO at any given point in time, so this is a
heuristic and not some form of synchronized behavior where the server
replicates the client's loss-detection algorithm precisely?

Section 5

  *  Retry packets use AEAD_AES_128_GCM to provide protection against
      accidental modification or insertion by off-path adversaries; see
      Section 5.8.

[As noted by others, please check the terminology here against
[QUIC-TRANSPORT]; I think the latter uses "attacker" rather than
"adversary" and I haven't internalized the new on-path, limited on-path,
off-path terminology yet, either.]

  *  All other packets have strong cryptographic protections for
      confidentiality and integrity, using keys and algorithms
      negotiated by TLS.

(side note) the handshake keys are "strong" in a certain sense
(unpredictability) but weak in the sense that they are not authenticated
until the handshake has completed.  It may not be necessary to attempt
to express this subtlety in this point in the document, though.

Section 5.1

I think we should say something about the "Context" argument to
HKDF-Expand-Label here.  (I assume it is going to be the same
Transcript-Hash as used for TLS 1.3, but it is not currently specified,
as far as I can see.  I do note that we have some ongoing discussion in
the context of draft-ietf-emu-eap-tls13 that *exporters*, at least,
might better have been specified to use the full transcript including
client Finished, but I am not convinced that we should consider such
drastic changes for our usage, especially since it would neuter 0.5-RTT
unless we add a lot more complexity.)  We may also want to say that
the Length input is determined by the ciphersuite's requirements.
Alternately we could specify in terms of Derive-Secret(), but there's
not really a clear incentive to do so.

Section 5.2

  This secret is determined by using HKDF-Extract (see Section 2.2 of
  [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
  a 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.

[I was going to say something about all-zeros providing the same level
of cryptographic protection, but then I saw the discussion at
https://github.com/quicwg/base-drafts/issues/4325 and the note further
down that new versions of QUIC should pick different salt values.]
I assume this holds for the final RFC version as compared to the I-Ds,
and https://github.com/quicwg/base-drafts/pull/3711 suggests that a new
(random) salt should be chosen for the final RFC version, but I didn't
see an open issue in github for it, so I'll mention it here just in case
that helps.  (The retry key+nonce in §5.8 seem to be in a similar boat,
and the examples in the appendix would need to be adjusted as well, of
course.)

  initial_secret = HKDF-Extract(initial_salt,
                                client_dst_connection_id)

  client_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "client in", "",
                                            Hash.length)
  server_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "server in", "",
                                            Hash.length)

(editorial) I wonder a bit if the rhetoric would be more clear if we did
not call the "initial_secret" a "secret", since it is just an
intermediate value used for constructing secrets and not used directly
to construct keys, itself.  (The idea would be to hew to the TLS 1.3
terminology where specific named Secrets are used to drive
Derive-Secret() calls but other cryptographic inputs are not named with
the word "secret".)

Section 5.3

  QUIC can use any of the cipher suites defined in [TLS13] with the
  exception of TLS_AES_128_CCM_8_SHA256.  [...]

It's a little interesting to use the RFC as the authority on
ciphersuites rather than the registry, but I guess the header protection
scheme requirement makes it more reasonable.  Also, for what it's worth,
there are MAC-only TLS 1.3 ciphersuites in the IANA registry.  I don't
know whether you want to say anything (to forbid?) such things from
being used as QUIC AEADs.

Section 5.4.x

Are we really sure that we want to use normative pseudocode?  I thought
(but cannot currently substantiate) that we typically preferred
normative prose and example pseudocode, since pseudocode somewhat
intrinsically has not-fully-specified semantics.  As some specific (but
not comprehensive!) examples, which bytes of the mask are used when the
packet number is encoded in fewer than 4 bytes, and the key/plaintext
inputs to AES-ECB seem to only be specified in the pseudocode.

Section 5.5

  Once an endpoint successfully receives a packet with a given packet
  number, it MUST discard all packets in the same packet number space
  with higher packet numbers if they cannot be successfully unprotected
  with either the same key, or - if there is a key update - the next
  packet protection key (see Section 6).  [...]

Pedantically, "the next packet protection key" seems to imply
specifically the one next key, not "any subsequent key".  A strict
reading of this text would thust require discarding all packets received
after a second key update, because this clause applies to the very first
packet successfully received, and the third key used is neither the
"same" or "next" key, from that reference point.  (I note that in §6.4
we merely talk about "either the same or newer packet protection keys".)

Section 5.6

  Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
  and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
  as they carry application data.  [...]

I guess STOP_SENDING is not listed as unsafe because it would be an
error to send it in 0-RTT anyway?

Section 5.7

  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 its 1-RTT packets coalesced with a Handshake
  packet containing a copy of the CRYPTO frame that carries the
  Finished message, until one of the Handshake packets is acknowledged.
  This enables immediate server processing for those packets.

This mostly only helps for unauthenticated clients, since for
authenticated clients the Finishsed isn't much good without the
Certificate+CertificateVerify, which are probably too big to include
with every packet.

Section 5.8

  The secret key and the nonce are values derived by calling HKDF-
  Expand-Label using
  0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
  the secret, with labels being "quic key" and "quic iv" (Section 5.1).

HKDF-Expand-Label also takes a "Context" argument; what value is used
for that?  (Presumably the ouput Length argument is set to the lengths
of the stated fields.)

  Retry Pseudo-Packet {
    ODCID Length (8),
    Original Destination Connection ID (0..160),
    Header Form (1) = 1,
    Fixed Bit (1) = 1,
    Long Packet Type (2) = 3,
    Type-Specific Bits (4),
    Version (32),
    DCID Len (8),
    Destination Connection ID (0..160),
    SCID Len (8),
    Source Connection ID (0..160),
    Retry Token (..),
  }

Should we say that the four bits before Version are Unused (not
Type-Specific Bits), as they are in the Retry packet itself?  (I assume
that the the arbitrary value in those bits does need to be preserved,
though.)

Section 6

I suggest noting that, in contrast to TLS, key updates are synchronized
between traffic directions; read keys are updated at the same time that
write keys are (and vice versa).

Section 6.3

  The process of creating new packet protection keys for receiving
  packets could reveal that a key update has occurred.  An endpoint MAY
  perform this process as part of packet processing, but this creates a
  timing signal that can be used by an attacker to learn when key
  updates happen and thus the value of the Key Phase bit in certain
  packets.  Endpoints MAY instead defer the creation of the next set of
  receive packet protection keys until some time after a key update
  completes, up to three times the PTO; see Section 6.5.

(editorial) I think this paragraph (and following) might need a rewrite,
since the phrase "new keys" in the context of a key update could be
ambiguous.  In particular, if we are considering the process of a key
update from generation M to generation N, this text only seems to make
sense if the "new keys" whose generation is being discussed is
generation O (i.e., ones that are not being used to send traffic yet by
anybody), but it is easy to misread "new keys" as being "the ones
installed/activated for use as part of the key update process".  Perhaps
the guidance that endpoints are to maintain both current and next keys
in normal operation should be moved earlier, with the context that you
need to be prepared to handle any valid incoming packets (which includes
those using both current and next keys, since the peer can initiate a
key update) without a timing channel for when key generation is
occurring.  (There may be some similar text in §9.5 that would be
updated in accordance with any changes made here.)

  Once generated, the next set of packet protection keys SHOULD be
  retained, even if the packet that was received was subsequently
  discarded.  [...]

What is "the packet" that was received?

Section 6.5

  An endpoint MAY allow a period of approximately the Probe Timeout
  (PTO; see [QUIC-RECOVERY]) after receiving a packet that uses the new
  key generation before it creates the next set of packet protection
  keys.  [...]

(editorial) Similarly to the previous section, I think the action being
described here might be more properly described as "promoting the 'next'
keys to be the 'current' keys (and thus starting the precomputation for
the subsequent 'next' keys)".  Surly this is not advocating waiting a
PTO before generating the keys you need to process a packet you just
received ... right?

Section 6.6

  The usage limits defined in TLS 1.3 exist for protection against
  attacks on confidentiality and apply to successful applications of
  AEAD protection.  The integrity protections in authenticated
  encryption also depend on limiting the number of attempts to forge
  packets.  TLS achieves this by closing connections after any record
  fails an authentication check.  In comparison, QUIC ignores any
  packet that cannot be authenticated, allowing multiple forgery
  attempts.

QUIC seems very analogous to DTLS in this regard, and DTLS 1.3 also has
similar text about AEAD limits for integrity.  Perhaps a brief mention
that they are essentially the same is useful?

  For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
  is 2^23 encrypted packets; see Appendix B.1.  For
  AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
  number of possible packets (2^62) and so can be disregarded.  For
  AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
  packets; see Appendix B.2.  Applying a limit reduces the probability
  that an attacker can distinguish the AEAD in use from a random
  permutation; see [AEBounds], [ROBUST], and [GCM-MU].
  [...]
  Note:  These limits were originally calculated using assumptions
      about the limits on TLS record size.  The maximum size of a TLS
      record is 2^14 bytes.  In comparison, QUIC packets can be up to
      2^16 bytes.  However, it is expected that QUIC packets will
      generally be smaller than TLS records.  Where packets might be
      larger than 2^14 bytes in length, smaller limits might be needed.

(This seems to say that we're just reusing the TLS numbers even though
in theory we do allow larger packets.  But if that's the case, why do
the actual numbers we present differ from the ones given for DTLS 1.3?
The actual text in Appendix B suggests that we are not actually reusing
the TLS numbers (since we use different estimates for l, and
furthermore, that [GCM-MU] allows larger limits than [AEBounds] as used
by TLS 1.3).)

  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.

DTLS 1.3 imposes essentially the same requirement.  IIUC it would be
acceptable to use the same limit for DTLS 1.3 and for QUIC, and we
should perhaps say that if a cipher is allowed for one it is allowed for
the other (with the same limit), though on second though, we really do
want the analysis to take into account the different assumptions about
the number of blocks in a packet..

Section 9

In various places (e.g., §4.1.4) we recommend to buffer (or "retain")
data that cannot be processed yet.  Perhaps it goes without saying, but
such buffering needs limits in place in order to avoid DoS.

It may be too banal to mention again here that the Initial secret/keys
are not particularly secure, but I'll mention it just in case we want
to.

Section 9.6

  The initial secrets 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.

Also for the Retry Integrity Tag key/nonce secret?

Appendix A.1, A.5

I think that RFC 8446 has us write just "" instead of _ to indicate a
zero-length Context.  I don't see the usage of _ explained anywhere.

Appendix A.2

  The client sends an Initial packet.  The unprotected payload of this
  packet contains the following CRYPTO frame, plus enough PADDING
  frames to make a 1162 byte payload:
  [...]
  The unprotected header includes the connection ID and a 4-byte packet
  number encoding for a packet number of 2:

  c300000001088394c8f03e5157080000449e00000002

If I'm reading this correctly, the variable-length integer encoding of
the packet Length is 0x449e which would indicate a 1182-byte payload
(including packet number), not 1162.

Appendix A.4

Should we mention specifically the Retry Token value?

Appendix B.1.1, B.1.2

I don't think that Theorem 4.3 of [GCM-MU] is the right reference for
both formulae.  (I actually had trouble matching up any of the formulae
in the paper with the ones here due to different variable names, and ran
out of time to dig further.)

Appendix B.2

  TLS [TLS13] and [AEBounds] do not specify limits on usage for
  AEAD_AES_128_CCM.  However, any AEAD that is used with QUIC requires

DTLS 1.3 does, though.

  This produces a relation that combines both encryption and decryption
  attempts with the same limit as that produced by the theorem for
  confidentiality alone.  For a target advantage of 2^-57, this results
  in:

  v + q <= 2^34.5 / l

  By setting "q = v", values for both confidentiality and integrity
  limits can be produced.  Endpoints that limit packets to 2^11 bytes
  therefore have both confidentiality and integrity limits of 2^26.5
  packets.  Endpoints that do not restrict packet size have a limit of
  2^21.5.

DTLS currently has text that does a dedicated computation for "q" and
then substitutes that established value into this last formula to
determine the limit for "v".  Should DTLS switch to using an analysis
more like the one presented here?  (Or vice versa, of course.)

[Ballot comment]
[edited to add two comments: one on the Abstract and one toplevel
comment about ClientHello reuse/change after Retry.]

I've noted some potential editorial improvements in a local copy of the
markdown and will make a pull request with the suggested changes.

The length of the remaining comments notwithstanding, this document is
generally quite well done and a sizeable chunk of my comments are just
relating to subtleties of TLS and our interaction with it; I plan to
change my position to Yes once the Discuss points have been
appropriately discussed.  My apologies in advance to the chairs who will
have to open github issues for all
of these!

We may want to make a pass through the document to normalize the way in
which we discuss 0-RTT.  For example, Section 4.5 mentions that
resumption "can be used without also enabling 0-RTT" as if 0-RTT should
be off by default, but much of the previous discussion involving 0-RTT
treats it as an expected and normal part of the protocl.  (For what
little it's worth, my own personal preference leans towards how RFC 8446
treats 0-RTT data, as an optional and potentially dangerous thing that
should be off by default and only enabled after careful consideration,
though in some ways it actually seems significantly safer in QUIC than
TLS.  Regardless, I do not see any value in re-litigating the question
at this point; I'm just hoping that the document can be consistent about
it.)

I think we would benefit from some clarity about the client's response
to a Retry.  Specifically, is the client expected to use the same
ClientHello from the first Initial, in the Initial generated in response
to the Retry?  I did not see any notes about, e.g., transport parameter
values sent by the client changing in response to Retry, and since the
Connection IDs change it seems that we might fall under the nonce (and
key share) reuse considerations for TLS.

Abstract

I think this document also specifies some generic bits about how QUIC
uses cryptography, that are not directly related to TLS integration.

Section 2.1

  The 0-RTT handshake is only possible if the client and server have
  previously communicated.  In the 1-RTT handshake, the client is

Pedantically, RFC 8446 does allow the exchange of 0-RTT data for
externally provisioned PSKs (non-resumption), provided that the
necessary parameters are provisioned along with the PSK.

Section 3

Figure 3 shows "TLS Alerts" as being carried over QUIC Transport, but
per §4.8 TLS alerts are translated into QUIC connection errors and are
not sent natively.

  *  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.

I think that if we're going to talk about passing the server certificate
between TLS and QUIC components, we should be very clear about where/how
certificate validation occurs.  For example, it would be pretty
disasterous if TLS passed the certificate to QUIC expecting that QUIC
would do any validation of the peer identity, but QUIC assumed that TLS
would only provide a validated certificate.  Perhaps in §4.1 when we
mention the potential for "additional functions [...] to configure TLS",
we might mention "including certificate validation", if appropriate?

Section 4

  QUIC carries TLS handshake data in CRYPTO frames, each of which
  consists of a contiguous block of handshake data identified by an
  offset and length.  Those frames are packaged into QUIC packets and
  encrypted under the current TLS encryption level.  [...]

I'm not sure I understand the benefit of specifically calling this a
"TLS encryption level".  While it's true that the keys are being
provided by TLS, the cryptographic mechanisms being used are applied by
QUIC.  Furthermore, there's a 1:1 correspondence between the QUIC and
TLS encryption levels, so perhaps it is acceptable to not have a
qualifier at all (for just "under the current encryption level").

  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 packet
  number space.  [...]

I'm a bit confused as to what analogy is being made here.  It seems to
be equating TLS records and QUIC frames, but of course multiple DTLS
records can appear in a single UDP datagram, so the difference between
QUIC and DTLS does not seem quite so large as depicted here.  Of course,
if the analogy is supposed to be between TLS handshake messages and QUIC
frames, or TLS records and QUIC packets, then things would be different,
but I'm not sure what this is intended to say.

Section 4.1.3

  Once the handshake is complete, TLS becomes passive.  TLS can still
  receive data from its peer and respond in kind, but it will not need
  to send more data unless specifically requested - either by an
  application or QUIC.  [...]

(pedantic note) In some sense this is a forward-looking statement *about
TLS*, which is not something the QUIC WG is chartered to work on.  That
said, because of how TLS feature negotiation is done, any new kind of
data spontaneously emitted by TLS would need to be negotiated with an
extension in the handshake, but I don't think we are attempting to
specifically lock down the set of extensions in the TLS handshake for
QUIC connections, so in theory a change to the TLS implementation
defaults could result in QUIC connections that have TLS spontaneously
emit data.  On the gripping hand, I don't really see much need for a
text change here.

Section 4.1.5

Why does the server call Get Handshake twice between receiving the
client Initial and the client's second Hansdhake flight?  IIUC the
interface says that additional handshake data will only be supplied from
TLS in response to input handshake data (and thus, not in response to
TLS generating new keys, which is what the figure suggests to be a
proximal trigger for the second Get Handshake).  We should probably be
careful that the interfaces we document are capable of describing the
case where TLS provides both new keys and handshake bytes, and the
handshake bytes are split across encryption levels (as is the case for
the server's first flight), which may be the motivation for the two Get
Handshake calls depicted here.

Similarly, it's my understanding that the client should still call Get
Handshake after receiving the Initial (but would receive only keys and
not output handshake data at that point).  I'm not sure whether the
figure should indicate that (ineffectual) Get Handshake call.

Should the figure indicate the Handshake Confirmed operation in addition
to Handshake Complete?

Section 4.3

  The TLS implementation does not need to ensure that the ClientHello
  is sufficiently large.  QUIC PADDING frames are added to increase the
  size of the packet as necessary.

Should we reference Section 8.1 of [QUIC-TRANSPORT] for "sufficiently
large"?

Section 4.4

  A client MUST authenticate the identity of the server.  This
  typically involves verification that the identity of the server is
  included in a certificate and that the certificate is issued by a
  trusted entity (see for example [RFC2818]).

I assume that, per normal TLS semantics, this requirement can be met by
PSK authentication as well as certificate authentication.  PSK
authentication has often been an aspect of TLS that has not received
substantial attention, so we may want to preemtively pay some attention
to the PSK case.

  A server MUST NOT use post-handshake client authentication (as
  defined in Section 4.6.2 of [TLS13]), because the multiplexing

Do we want to say anything about not sending the "post_handshake_auth"
extension (defined in the numerologically similar section 4.2.6 of RFC
8446)?  Strictly speaking we don't need to say anything, but efficient
implementations would satisfy the existing QUIC requirement by not
sending the extension and relying on the TLS stack to reject
post-handshake authentication since the extension had not been offered.

Section 4.8

  The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
  generate alerts at the "warning" level.

This seems to be making a normative restriction on the operation of TLS,
which is not in the QUIC WG charter.  Perhaps we should instead
constrain the QUIC implementation to not accept such alerts (and what to
do if they are received) and note that the only closure alerts in RFC
8446 are "close_notify" and "user_cancelled", which are replaced by
equivalent QUIC-level functionality.

Section 4.9

  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

(nit/editorial) I believe that the "both" is meant to apply to "received
and acknowledged" and "when all CRYTO frames [...] have been
acknowledged", but the current formulation does not have parallel
structure between those clauses, so it ends up reading more naturally as
saying that the "both" refers to "received" and "acknowledged".  I don't
have a simple suggestion for fixing it, though (it might require a
significant restructuring to fix), so I'm leaving it here in my comments
rather than incorporating a fix into my editorial PR.  (Any drastic
rewording might consider the rest of the paragraph as well, as it seems
to leave the reader without a clear sense for when it definitely is safe
to discard old keys.)

  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.

Is there anything useful to say about whether it is advisable to make
retransmission packets have the same size as the original transmission?
("No" is a fine answer.)

Section 4.9.3

  0-RTT keys to allow decrypting reordered packets without requiring
  their contents to be retransmitted with 1-RTT keys.  After receiving
  a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;
  the RECOMMENDED time period is three times the Probe Timeout (PTO,
  see [QUIC-RECOVERY]).  A server MAY discard 0-RTT keys earlier if it

Just to check my understanding, the two endpoints will not necessarily
agree on the value of PTO at any given point in time, so this is a
heuristic and not some form of synchronized behavior where the server
replicates the client's loss-detection algorithm precisely?

Section 5

  *  Retry packets use AEAD_AES_128_GCM to provide protection against
      accidental modification or insertion by off-path adversaries; see
      Section 5.8.

[As noted by others, please check the terminology here against
[QUIC-TRANSPORT]; I think the latter uses "attacker" rather than
"adversary" and I haven't internalized the new on-path, limited on-path,
off-path terminology yet, either.]

  *  All other packets have strong cryptographic protections for
      confidentiality and integrity, using keys and algorithms
      negotiated by TLS.

(side note) the handshake keys are "strong" in a certain sense
(unpredictability) but weak in the sense that they are not authenticated
until the handshake has completed.  It may not be necessary to attempt
to express this subtlety in this point in the document, though.

Section 5.1

I think we should say something about the "Context" argument to
HKDF-Expand-Label here.  (I assume it is going to be the same
Transcript-Hash as used for TLS 1.3, but it is not currently specified,
as far as I can see.  I do note that we have some ongoing discussion in
the context of draft-ietf-emu-eap-tls13 that *exporters*, at least,
might better have been specified to use the full transcript including
client Finished, but I am not convinced that we should consider such
drastic changes for our usage, especially since it would neuter 0.5-RTT
unless we add a lot more complexity.)  We may also want to say that
the Length input is determined by the ciphersuite's requirements.
Alternately we could specify in terms of Derive-Secret(), but there's
not really a clear incentive to do so.

Section 5.2

  This secret is determined by using HKDF-Extract (see Section 2.2 of
  [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
  a 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.

[I was going to say something about all-zeros providing the same level
of cryptographic protection, but then I saw the discussion at
https://github.com/quicwg/base-drafts/issues/4325 and the note further
down that new versions of QUIC should pick different salt values.]
I assume this holds for the final RFC version as compared to the I-Ds,
and https://github.com/quicwg/base-drafts/pull/3711 suggests that a new
(random) salt should be chosen for the final RFC version, but I didn't
see an open issue in github for it, so I'll mention it here just in case
that helps.  (The retry key+nonce in §5.8 seem to be in a similar boat,
and the examples in the appendix would need to be adjusted as well, of
course.)

  initial_secret = HKDF-Extract(initial_salt,
                                client_dst_connection_id)

  client_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "client in", "",
                                            Hash.length)
  server_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "server in", "",
                                            Hash.length)

(editorial) I wonder a bit if the rhetoric would be more clear if we did
not call the "initial_secret" a "secret", since it is just an
intermediate value used for constructing secrets and not used directly
to construct keys, itself.  (The idea would be to hew to the TLS 1.3
terminology where specific named Secrets are used to drive
Derive-Secret() calls but other cryptographic inputs are not named with
the word "secret".)

Section 5.3

  QUIC can use any of the cipher suites defined in [TLS13] with the
  exception of TLS_AES_128_CCM_8_SHA256.  [...]

It's a little interesting to use the RFC as the authority on
ciphersuites rather than the registry, but I guess the header protection
scheme requirement makes it more reasonable.  Also, for what it's worth,
there are MAC-only TLS 1.3 ciphersuites in the IANA registry.  I don't
know whether you want to say anything (to forbid?) such things from
being used as QUIC AEADs.

Section 5.4.x

Are we really sure that we want to use normative pseudocode?  I thought
(but cannot currently substantiate) that we typically preferred
normative prose and example pseudocode, since pseudocode somewhat
intrinsically has not-fully-specified semantics.  As some specific (but
not comprehensive!) examples, which bytes of the mask are used when the
packet number is encoded in fewer than 4 bytes, and the key/plaintext
inputs to AES-ECB seem to only be specified in the pseudocode.

Section 5.5

  Once an endpoint successfully receives a packet with a given packet
  number, it MUST discard all packets in the same packet number space
  with higher packet numbers if they cannot be successfully unprotected
  with either the same key, or - if there is a key update - the next
  packet protection key (see Section 6).  [...]

Pedantically, "the next packet protection key" seems to imply
specifically the one next key, not "any subsequent key".  A strict
reading of this text would thust require discarding all packets received
after a second key update, because this clause applies to the very first
packet successfully received, and the third key used is neither the
"same" or "next" key, from that reference point.  (I note that in §6.4
we merely talk about "either the same or newer packet protection keys".)

Section 5.6

  Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
  and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
  as they carry application data.  [...]

I guess STOP_SENDING is not listed as unsafe because it would be an
error to send it in 0-RTT anyway?

Section 5.7

  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 its 1-RTT packets coalesced with a Handshake
  packet containing a copy of the CRYPTO frame that carries the
  Finished message, until one of the Handshake packets is acknowledged.
  This enables immediate server processing for those packets.

This mostly only helps for unauthenticated clients, since for
authenticated clients the Finishsed isn't much good without the
Certificate+CertificateVerify, which are probably too big to include
with every packet.

Section 5.8

  The secret key and the nonce are values derived by calling HKDF-
  Expand-Label using
  0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
  the secret, with labels being "quic key" and "quic iv" (Section 5.1).

HKDF-Expand-Label also takes a "Context" argument; what value is used
for that?  (Presumably the ouput Length argument is set to the lengths
of the stated fields.)

  Retry Pseudo-Packet {
    ODCID Length (8),
    Original Destination Connection ID (0..160),
    Header Form (1) = 1,
    Fixed Bit (1) = 1,
    Long Packet Type (2) = 3,
    Type-Specific Bits (4),
    Version (32),
    DCID Len (8),
    Destination Connection ID (0..160),
    SCID Len (8),
    Source Connection ID (0..160),
    Retry Token (..),
  }

Should we say that the four bits before Version are Unused (not
Type-Specific Bits), as they are in the Retry packet itself?  (I assume
that the the arbitrary value in those bits does need to be preserved,
though.)

Section 6

I suggest noting that, in contrast to TLS, key updates are synchronized
between traffic directions; read keys are updated at the same time that
write keys are (and vice versa).

Section 6.3

  The process of creating new packet protection keys for receiving
  packets could reveal that a key update has occurred.  An endpoint MAY
  perform this process as part of packet processing, but this creates a
  timing signal that can be used by an attacker to learn when key
  updates happen and thus the value of the Key Phase bit in certain
  packets.  Endpoints MAY instead defer the creation of the next set of
  receive packet protection keys until some time after a key update
  completes, up to three times the PTO; see Section 6.5.

(editorial) I think this paragraph (and following) might need a rewrite,
since the phrase "new keys" in the context of a key update could be
ambiguous.  In particular, if we are considering the process of a key
update from generation M to generation N, this text only seems to make
sense if the "new keys" whose generation is being discussed is
generation O (i.e., ones that are not being used to send traffic yet by
anybody), but it is easy to misread "new keys" as being "the ones
installed/activated for use as part of the key update process".  Perhaps
the guidance that endpoints are to maintain both current and next keys
in normal operation should be moved earlier, with the context that you
need to be prepared to handle any valid incoming packets (which includes
those using both current and next keys, since the peer can initiate a
key update) without a timing channel for when key generation is
occurring.  (There may be some similar text in §9.5 that would be
updated in accordance with any changes made here.)

  Once generated, the next set of packet protection keys SHOULD be
  retained, even if the packet that was received was subsequently
  discarded.  [...]

What is "the packet" that was received?

Section 6.5

  An endpoint MAY allow a period of approximately the Probe Timeout
  (PTO; see [QUIC-RECOVERY]) after receiving a packet that uses the new
  key generation before it creates the next set of packet protection
  keys.  [...]

(editorial) Similarly to the previous section, I think the action being
described here might be more properly described as "promoting the 'next'
keys to be the 'current' keys (and thus starting the precomputation for
the subsequent 'next' keys)".  Surly this is not advocating waiting a
PTO before generating the keys you need to process a packet you just
received ... right?

Section 6.6

  The usage limits defined in TLS 1.3 exist for protection against
  attacks on confidentiality and apply to successful applications of
  AEAD protection.  The integrity protections in authenticated
  encryption also depend on limiting the number of attempts to forge
  packets.  TLS achieves this by closing connections after any record
  fails an authentication check.  In comparison, QUIC ignores any
  packet that cannot be authenticated, allowing multiple forgery
  attempts.

QUIC seems very analogous to DTLS in this regard, and DTLS 1.3 also has
similar text about AEAD limits for integrity.  Perhaps a brief mention
that they are essentially the same is useful?

  For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
  is 2^23 encrypted packets; see Appendix B.1.  For
  AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
  number of possible packets (2^62) and so can be disregarded.  For
  AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
  packets; see Appendix B.2.  Applying a limit reduces the probability
  that an attacker can distinguish the AEAD in use from a random
  permutation; see [AEBounds], [ROBUST], and [GCM-MU].
  [...]
  Note:  These limits were originally calculated using assumptions
      about the limits on TLS record size.  The maximum size of a TLS
      record is 2^14 bytes.  In comparison, QUIC packets can be up to
      2^16 bytes.  However, it is expected that QUIC packets will
      generally be smaller than TLS records.  Where packets might be
      larger than 2^14 bytes in length, smaller limits might be needed.

(This seems to say that we're just reusing the TLS numbers even though
in theory we do allow larger packets.  But if that's the case, why do
the actual numbers we present differ from the ones given for DTLS 1.3?
The actual text in Appendix B suggests that we are not actually reusing
the TLS numbers (since we use different estimates for l, and
furthermore, that [GCM-MU] allows larger limits than [AEBounds] as used
by TLS 1.3).)

  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.

DTLS 1.3 imposes essentially the same requirement.  IIUC it would be
acceptable to use the same limit for DTLS 1.3 and for QUIC, and we
should perhaps say that if a cipher is allowed for one it is allowed for
the other (with the same limit), though on second though, we really do
want the analysis to take into account the different assumptions about
the number of blocks in a packet..

Section 9

In various places (e.g., §4.1.4) we recommend to buffer (or "retain")
data that cannot be processed yet.  Perhaps it goes without saying, but
such buffering needs limits in place in order to avoid DoS.

It may be too banal to mention again here that the Initial secret/keys
are not particularly secure, but I'll mention it just in case we want
to.

Section 9.6

  The initial secrets 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.

Also for the Retry Integrity Tag key/nonce secret?

Appendix A.1, A.5

I think that RFC 8446 has us write just "" instead of _ to indicate a
zero-length Context.  I don't see the usage of _ explained anywhere.

Appendix A.2

  The client sends an Initial packet.  The unprotected payload of this
  packet contains the following CRYPTO frame, plus enough PADDING
  frames to make a 1162 byte payload:
  [...]
  The unprotected header includes the connection ID and a 4-byte packet
  number encoding for a packet number of 2:

  c300000001088394c8f03e5157080000449e00000002

If I'm reading this correctly, the variable-length integer encoding of
the packet Length is 0x449e which would indicate a 1182-byte payload
(including packet number), not 1162.

Appendix A.4

Should we mention specifically the Retry Token value?

Appendix B.1.1, B.1.2

I don't think that Theorem 4.3 of [GCM-MU] is the right reference for
both formulae.  (I actually had trouble matching up any of the formulae
in the paper with the ones here due to different variable names, and ran
out of time to dig further.)

Appendix B.2

  TLS [TLS13] and [AEBounds] do not specify limits on usage for
  AEAD_AES_128_CCM.  However, any AEAD that is used with QUIC requires

DTLS 1.3 does, though.

  This produces a relation that combines both encryption and decryption
  attempts with the same limit as that produced by the theorem for
  confidentiality alone.  For a target advantage of 2^-57, this results
  in:

  v + q <= 2^34.5 / l

  By setting "q = v", values for both confidentiality and integrity
  limits can be produced.  Endpoints that limit packets to 2^11 bytes
  therefore have both confidentiality and integrity limits of 2^26.5
  packets.  Endpoints that do not restrict packet size have a limit of
  2^21.5.

DTLS currently has text that does a dedicated computation for "q" and
then substitutes that established value into this last formula to
determine the limit for "v".  Should DTLS switch to using an analysis
more like the one presented here?  (Or vice versa, of course.)

[Ballot comment]
Thank you to Radia Perlman for the SECDIR review and the ensuing discussion about this review.

Two areas of recommended clarity:

** Section 4.  Recommend a bit more text up front describing the notion of “encryption levels”.  This section first introduces the concept by noting that “Those frames are packaged into QUIC packets and encrypted under the current TLS encryption level”.  Later in Section 4.1.3, it is noted that “Four encryption levels are used, producing keys for Initial, 0-RTT, Handshake, and 1-RTT packets” which makes these “levels” seem only like categories.  In describing specific processing there is text such as “When TLS provides keys for a higher encryption level …” which now describes a relatively ordering perhaps with something have having or less.  I might be helpful to include an early narrative on what “higher” and “lower” and encryption “levels” means and how level changes occur (i.e., explicitly linking them to changes in the QUIC state machine).

** Section 4.4.  Per the peer authentication text, should it be acknowledged that due the general-purpose nature of the protocol, peer validation practices may will need to be further defined by applications?

[Ballot comment]
I've noted some potential editorial improvements in a local copy of the
markdown and have made a pull request with them, at
https://github.com/quicwg/base-drafts/pull/4473

The length of the remaining comments notwithstanding, this document is
generally quite well done and a sizeable chunk of my comments are just
relating to subtleties of TLS and our interaction with it; I plan to
change my position to Yes once the Discuss points have been
appropriately discussed.  My apologies in advance to the chairs who will
have to open github issues for all
of these!

We may want to make a pass through the document to normalize the way in
which we discuss 0-RTT.  For example, Section 4.5 mentions that
resumption "can be used without also enabling 0-RTT" as if 0-RTT should
be off by default, but much of the previous discussion involving 0-RTT
treats it as an expected and normal part of the protocl.  (For what
little it's worth, my own personal preference leans towards how RFC 8446
treats 0-RTT data, as an optional and potentially dangerous thing that
should be off by default and only enabled after careful consideration,
though in some ways it actually seems significantly safer in QUIC than
TLS.  Regardless, I do not see any value in re-litigating the question
at this point; I'm just hoping that the document can be consistent about
it.)

Abstract

I think this document also specifies some generic bits about how QUIC
uses cryptography, that are not directly related to TLS integration.

Section 2.1

  The 0-RTT handshake is only possible if the client and server have
  previously communicated.  In the 1-RTT handshake, the client is

Pedantically, RFC 8446 does allow the exchange of 0-RTT data for
externally provisioned PSKs (non-resumption), provided that the
necessary parameters are provisioned along with the PSK.

Section 3

Figure 3 shows "TLS Alerts" as being carried over QUIC Transport, but
per §4.8 TLS alerts are translated into QUIC connection errors and are
not sent natively.

  *  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.

I think that if we're going to talk about passing the server certificate
between TLS and QUIC components, we should be very clear about where/how
certificate validation occurs.  For example, it would be pretty
disasterous if TLS passed the certificate to QUIC expecting that QUIC
would do any validation of the peer identity, but QUIC assumed that TLS
would only provide a validated certificate.  Perhaps in §4.1 when we
mention the potential for "additional functions [...] to configure TLS",
we might mention "including certificate validation", if appropriate?

Section 4

  QUIC carries TLS handshake data in CRYPTO frames, each of which
  consists of a contiguous block of handshake data identified by an
  offset and length.  Those frames are packaged into QUIC packets and
  encrypted under the current TLS encryption level.  [...]

I'm not sure I understand the benefit of specifically calling this a
"TLS encryption level".  While it's true that the keys are being
provided by TLS, the cryptographic mechanisms being used are applied by
QUIC.  Furthermore, there's a 1:1 correspondence between the QUIC and
TLS encryption levels, so perhaps it is acceptable to not have a
qualifier at all (for just "under the current encryption level").

  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 packet
  number space.  [...]

I'm a bit confused as to what analogy is being made here.  It seems to
be equating TLS records and QUIC frames, but of course multiple DTLS
records can appear in a single UDP datagram, so the difference between
QUIC and DTLS does not seem quite so large as depicted here.  Of course,
if the analogy is supposed to be between TLS handshake messages and QUIC
frames, or TLS records and QUIC packets, then things would be different,
but I'm not sure what this is intended to say.

Section 4.1.3

  Once the handshake is complete, TLS becomes passive.  TLS can still
  receive data from its peer and respond in kind, but it will not need
  to send more data unless specifically requested - either by an
  application or QUIC.  [...]

(pedantic note) In some sense this is a forward-looking statement *about
TLS*, which is not something the QUIC WG is chartered to work on.  That
said, because of how TLS feature negotiation is done, any new kind of
data spontaneously emitted by TLS would need to be negotiated with an
extension in the handshake, but I don't think we are attempting to
specifically lock down the set of extensions in the TLS handshake for
QUIC connections, so in theory a change to the TLS implementation
defaults could result in QUIC connections that have TLS spontaneously
emit data.  On the gripping hand, I don't really see much need for a
text change here.

Section 4.1.5

Why does the server call Get Handshake twice between receiving the
client Initial and the client's second Hansdhake flight?  IIUC the
interface says that additional handshake data will only be supplied from
TLS in response to input handshake data (and thus, not in response to
TLS generating new keys, which is what the figure suggests to be a
proximal trigger for the second Get Handshake).  We should probably be
careful that the interfaces we document are capable of describing the
case where TLS provides both new keys and handshake bytes, and the
handshake bytes are split across encryption levels (as is the case for
the server's first flight), which may be the motivation for the two Get
Handshake calls depicted here.

Similarly, it's my understanding that the client should still call Get
Handshake after receiving the Initial (but would receive only keys and
not output handshake data at that point).  I'm not sure whether the
figure should indicate that (ineffectual) Get Handshake call.

Should the figure indicate the Handshake Confirmed operation in addition
to Handshake Complete?

Section 4.3

  The TLS implementation does not need to ensure that the ClientHello
  is sufficiently large.  QUIC PADDING frames are added to increase the
  size of the packet as necessary.

Should we reference Section 8.1 of [QUIC-TRANSPORT] for "sufficiently
large"?

Section 4.4

  A client MUST authenticate the identity of the server.  This
  typically involves verification that the identity of the server is
  included in a certificate and that the certificate is issued by a
  trusted entity (see for example [RFC2818]).

I assume that, per normal TLS semantics, this requirement can be met by
PSK authentication as well as certificate authentication.  PSK
authentication has often been an aspect of TLS that has not received
substantial attention, so we may want to preemtively pay some attention
to the PSK case.

  A server MUST NOT use post-handshake client authentication (as
  defined in Section 4.6.2 of [TLS13]), because the multiplexing

Do we want to say anything about not sending the "post_handshake_auth"
extension (defined in the numerologically similar section 4.2.6 of RFC
8446)?  Strictly speaking we don't need to say anything, but efficient
implementations would satisfy the existing QUIC requirement by not
sending the extension and relying on the TLS stack to reject
post-handshake authentication since the extension had not been offered.

Section 4.8

  The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
  generate alerts at the "warning" level.

This seems to be making a normative restriction on the operation of TLS,
which is not in the QUIC WG charter.  Perhaps we should instead
constrain the QUIC implementation to not accept such alerts (and what to
do if they are received) and note that the only closure alerts in RFC
8446 are "close_notify" and "user_cancelled", which are replaced by
equivalent QUIC-level functionality.

Section 4.9

  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

(nit/editorial) I believe that the "both" is meant to apply to "received
and acknowledged" and "when all CRYTO frames [...] have been
acknowledged", but the current formulation does not have parallel
structure between those clauses, so it ends up reading more naturally as
saying that the "both" refers to "received" and "acknowledged".  I don't
have a simple suggestion for fixing it, though (it might require a
significant restructuring to fix), so I'm leaving it here in my comments
rather than incorporating a fix into my editorial PR.  (Any drastic
rewording might consider the rest of the paragraph as well, as it seems
to leave the reader without a clear sense for when it definitely is safe
to discard old keys.)

  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.

Is there anything useful to say about whether it is advisable to make
retransmission packets have the same size as the original transmission?
("No" is a fine answer.)

Section 4.9.3

  0-RTT keys to allow decrypting reordered packets without requiring
  their contents to be retransmitted with 1-RTT keys.  After receiving
  a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;
  the RECOMMENDED time period is three times the Probe Timeout (PTO,
  see [QUIC-RECOVERY]).  A server MAY discard 0-RTT keys earlier if it

Just to check my understanding, the two endpoints will not necessarily
agree on the value of PTO at any given point in time, so this is a
heuristic and not some form of synchronized behavior where the server
replicates the client's loss-detection algorithm precisely?

Section 5

  *  Retry packets use AEAD_AES_128_GCM to provide protection against
      accidental modification or insertion by off-path adversaries; see
      Section 5.8.

[As noted by others, please check the terminology here against
[QUIC-TRANSPORT]; I think the latter uses "attacker" rather than
"adversary" and I haven't internalized the new on-path, limited on-path,
off-path terminology yet, either.]

  *  All other packets have strong cryptographic protections for
      confidentiality and integrity, using keys and algorithms
      negotiated by TLS.

(side note) the handshake keys are "strong" in a certain sense
(unpredictability) but weak in the sense that they are not authenticated
until the handshake has completed.  It may not be necessary to attempt
to express this subtlety in this point in the document, though.

Section 5.1

I think we should say something about the "Context" argument to
HKDF-Expand-Label here.  (I assume it is going to be the same
Transcript-Hash as used for TLS 1.3, but it is not currently specified,
as far as I can see.  I do note that we have some ongoing discussion in
the context of draft-ietf-emu-eap-tls13 that *exporters*, at least,
might better have been specified to use the full transcript including
client Finished, but I am not convinced that we should consider such
drastic changes for our usage, especially since it would neuter 0.5-RTT
unless we add a lot more complexity.)  We may also want to say that
the Length input is determined by the ciphersuite's requirements.
Alternately we could specify in terms of Derive-Secret(), but there's
not really a clear incentive to do so.

Section 5.2

  This secret is determined by using HKDF-Extract (see Section 2.2 of
  [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
  a 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.

[I was going to say something about all-zeros providing the same level
of cryptographic protection, but then I saw the discussion at
https://github.com/quicwg/base-drafts/issues/4325 and the note further
down that new versions of QUIC should pick different salt values.]
I assume this holds for the final RFC version as compared to the I-Ds,
and https://github.com/quicwg/base-drafts/pull/3711 suggests that a new
(random) salt should be chosen for the final RFC version, but I didn't
see an open issue in github for it, so I'll mention it here just in case
that helps.  (The retry key+nonce in §5.8 seem to be in a similar boat,
and the examples in the appendix would need to be adjusted as well, of
course.)

  initial_secret = HKDF-Extract(initial_salt,
                                client_dst_connection_id)

  client_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "client in", "",
                                            Hash.length)
  server_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "server in", "",
                                            Hash.length)

(editorial) I wonder a bit if the rhetoric would be more clear if we did
not call the "initial_secret" a "secret", since it is just an
intermediate value used for constructing secrets and not used directly
to construct keys, itself.  (The idea would be to hew to the TLS 1.3
terminology where specific named Secrets are used to drive
Derive-Secret() calls but other cryptographic inputs are not named with
the word "secret".)

Section 5.3

  QUIC can use any of the cipher suites defined in [TLS13] with the
  exception of TLS_AES_128_CCM_8_SHA256.  [...]

It's a little interesting to use the RFC as the authority on
ciphersuites rather than the registry, but I guess the header protection
scheme requirement makes it more reasonable.  Also, for what it's worth,
there are MAC-only TLS 1.3 ciphersuites in the IANA registry.  I don't
know whether you want to say anything (to forbid?) such things from
being used as QUIC AEADs.

Section 5.4.x

Are we really sure that we want to use normative pseudocode?  I thought
(but cannot currently substantiate) that we typically preferred
normative prose and example pseudocode, since pseudocode somewhat
intrinsically has not-fully-specified semantics.  As some specific (but
not comprehensive!) examples, which bytes of the mask are used when the
packet number is encoded in fewer than 4 bytes, and the key/plaintext
inputs to AES-ECB seem to only be specified in the pseudocode.

Section 5.5

  Once an endpoint successfully receives a packet with a given packet
  number, it MUST discard all packets in the same packet number space
  with higher packet numbers if they cannot be successfully unprotected
  with either the same key, or - if there is a key update - the next
  packet protection key (see Section 6).  [...]

Pedantically, "the next packet protection key" seems to imply
specifically the one next key, not "any subsequent key".  A strict
reading of this text would thust require discarding all packets received
after a second key update, because this clause applies to the very first
packet successfully received, and the third key used is neither the
"same" or "next" key, from that reference point.  (I note that in §6.4
we merely talk about "either the same or newer packet protection keys".)

Section 5.6

  Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
  and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
  as they carry application data.  [...]

I guess STOP_SENDING is not listed as unsafe because it would be an
error to send it in 0-RTT anyway?

Section 5.7

  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 its 1-RTT packets coalesced with a Handshake
  packet containing a copy of the CRYPTO frame that carries the
  Finished message, until one of the Handshake packets is acknowledged.
  This enables immediate server processing for those packets.

This mostly only helps for unauthenticated clients, since for
authenticated clients the Finishsed isn't much good without the
Certificate+CertificateVerify, which are probably too big to include
with every packet.

Section 5.8

  The secret key and the nonce are values derived by calling HKDF-
  Expand-Label using
  0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
  the secret, with labels being "quic key" and "quic iv" (Section 5.1).

HKDF-Expand-Label also takes a "Context" argument; what value is used
for that?  (Presumably the ouput Length argument is set to the lengths
of the stated fields.)

  Retry Pseudo-Packet {
    ODCID Length (8),
    Original Destination Connection ID (0..160),
    Header Form (1) = 1,
    Fixed Bit (1) = 1,
    Long Packet Type (2) = 3,
    Type-Specific Bits (4),
    Version (32),
    DCID Len (8),
    Destination Connection ID (0..160),
    SCID Len (8),
    Source Connection ID (0..160),
    Retry Token (..),
  }

Should we say that the four bits before Version are Unused (not
Type-Specific Bits), as they are in the Retry packet itself?  (I assume
that the the arbitrary value in those bits does need to be preserved,
though.)

Section 6

I suggest noting that, in contrast to TLS, key updates are synchronized
between traffic directions; read keys are updated at the same time that
write keys are (and vice versa).

Section 6.3

  The process of creating new packet protection keys for receiving
  packets could reveal that a key update has occurred.  An endpoint MAY
  perform this process as part of packet processing, but this creates a
  timing signal that can be used by an attacker to learn when key
  updates happen and thus the value of the Key Phase bit in certain
  packets.  Endpoints MAY instead defer the creation of the next set of
  receive packet protection keys until some time after a key update
  completes, up to three times the PTO; see Section 6.5.

(editorial) I think this paragraph (and following) might need a rewrite,
since the phrase "new keys" in the context of a key update could be
ambiguous.  In particular, if we are considering the process of a key
update from generation M to generation N, this text only seems to make
sense if the "new keys" whose generation is being discussed is
generation O (i.e., ones that are not being used to send traffic yet by
anybody), but it is easy to misread "new keys" as being "the ones
installed/activated for use as part of the key update process".  Perhaps
the guidance that endpoints are to maintain both current and next keys
in normal operation should be moved earlier, with the context that you
need to be prepared to handle any valid incoming packets (which includes
those using both current and next keys, since the peer can initiate a
key update) without a timing channel for when key generation is
occurring.  (There may be some similar text in §9.5 that would be
updated in accordance with any changes made here.)

  Once generated, the next set of packet protection keys SHOULD be
  retained, even if the packet that was received was subsequently
  discarded.  [...]

What is "the packet" that was received?

Section 6.5

  An endpoint MAY allow a period of approximately the Probe Timeout
  (PTO; see [QUIC-RECOVERY]) after receiving a packet that uses the new
  key generation before it creates the next set of packet protection
  keys.  [...]

(editorial) Similarly to the previous section, I think the action being
described here might be more properly described as "promoting the 'next'
keys to be the 'current' keys (and thus starting the precomputation for
the subsequent 'next' keys)".  Surly this is not advocating waiting a
PTO before generating the keys you need to process a packet you just
received ... right?

Section 6.6

  The usage limits defined in TLS 1.3 exist for protection against
  attacks on confidentiality and apply to successful applications of
  AEAD protection.  The integrity protections in authenticated
  encryption also depend on limiting the number of attempts to forge
  packets.  TLS achieves this by closing connections after any record
  fails an authentication check.  In comparison, QUIC ignores any
  packet that cannot be authenticated, allowing multiple forgery
  attempts.

QUIC seems very analogous to DTLS in this regard, and DTLS 1.3 also has
similar text about AEAD limits for integrity.  Perhaps a brief mention
that they are essentially the same is useful?

  For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
  is 2^23 encrypted packets; see Appendix B.1.  For
  AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
  number of possible packets (2^62) and so can be disregarded.  For
  AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
  packets; see Appendix B.2.  Applying a limit reduces the probability
  that an attacker can distinguish the AEAD in use from a random
  permutation; see [AEBounds], [ROBUST], and [GCM-MU].
  [...]
  Note:  These limits were originally calculated using assumptions
      about the limits on TLS record size.  The maximum size of a TLS
      record is 2^14 bytes.  In comparison, QUIC packets can be up to
      2^16 bytes.  However, it is expected that QUIC packets will
      generally be smaller than TLS records.  Where packets might be
      larger than 2^14 bytes in length, smaller limits might be needed.

(This seems to say that we're just reusing the TLS numbers even though
in theory we do allow larger packets.  But if that's the case, why do
the actual numbers we present differ from the ones given for DTLS 1.3?
The actual text in Appendix B suggests that we are not actually reusing
the TLS numbers (since we use different estimates for l, and
furthermore, that [GCM-MU] allows larger limits than [AEBounds] as used
by TLS 1.3).)

  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.

DTLS 1.3 imposes essentially the same requirement.  IIUC it would be
acceptable to use the same limit for DTLS 1.3 and for QUIC, and we
should perhaps say that if a cipher is allowed for one it is allowed for
the other (with the same limit), though on second though, we really do
want the analysis to take into account the different assumptions about
the number of blocks in a packet..

Section 9

In various places (e.g., §4.1.4) we recommend to buffer (or "retain")
data that cannot be processed yet.  Perhaps it goes without saying, but
such buffering needs limits in place in order to avoid DoS.

It may be too banal to mention again here that the Initial secret/keys
are not particularly secure, but I'll mention it just in case we want
to.

Section 9.6

  The initial secrets 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.

Also for the Retry Integrity Tag key/nonce secret?

Appendix A.1, A.5

I think that RFC 8446 has us write just "" instead of _ to indicate a
zero-length Context.  I don't see the usage of _ explained anywhere.

Appendix A.2

  The client sends an Initial packet.  The unprotected payload of this
  packet contains the following CRYPTO frame, plus enough PADDING
  frames to make a 1162 byte payload:
  [...]
  The unprotected header includes the connection ID and a 4-byte packet
  number encoding for a packet number of 2:

  c300000001088394c8f03e5157080000449e00000002

If I'm reading this correctly, the variable-length integer encoding of
the packet Length is 0x449e which would indicate a 1182-byte payload
(including packet number), not 1162.

Appendix A.4

Should we mention specifically the Retry Token value?

Appendix B.1.1, B.1.2

I don't think that Theorem 4.3 of [GCM-MU] is the right reference for
both formulae.  (I actually had trouble matching up any of the formulae
in the paper with the ones here due to different variable names, and ran
out of time to dig further.)

Appendix B.2

  TLS [TLS13] and [AEBounds] do not specify limits on usage for
  AEAD_AES_128_CCM.  However, any AEAD that is used with QUIC requires

DTLS 1.3 does, though.

  This produces a relation that combines both encryption and decryption
  attempts with the same limit as that produced by the theorem for
  confidentiality alone.  For a target advantage of 2^-57, this results
  in:

  v + q <= 2^34.5 / l

  By setting "q = v", values for both confidentiality and integrity
  limits can be produced.  Endpoints that limit packets to 2^11 bytes
  therefore have both confidentiality and integrity limits of 2^26.5
  packets.  Endpoints that do not restrict packet size have a limit of
  2^21.5.

DTLS currently has text that does a dedicated computation for "q" and
then substitutes that established value into this last formula to
determine the limit for "v".  Should DTLS switch to using an analysis
more like the one presented here?  (Or vice versa, of course.)

[Ballot discuss]
(1) Rather a "discuss-discuss", but we seem to be requiring some changes
to TLS 1.3 that are arguably out of charter.  In particular, in Section
8.3 we see that clients are forbidden from sending EndOfEarlyData and it
(accordingly) does not appear in the handshake transcript.  The
reasoning for this is fairly sound; we explicitly index our application
data streams and any truncation will be filled in as a normal part of
the recovery process, so the attack that EndOfEarlyData exists to
prevent instrinsically cannot happen.  However, the only reason we'd be
required to send it in the first place is if the server sends the
"early_data" extension in EncryptedExtensions ... and we already have a
bit of unpleasantness relating to the "early_data" extension, in that we
have to use a sentinel value for max_early_data_size in NewSessionTicket
to indicate that the ticket is good for 0-RTT, with the actual maximum
amount of data allowed indicated elsewhere.  TLS extensions are cheap,
so a new "quic_early_data" flag extension valid in CH, EE, and NST would
keep us from conflating TLS and QUIC 0-RTT semantics, thus solving both
problems at the same time.  On the other hand, that would be requiring
implementations to churn just for process cleanliness, so we might also
consider other alternatives, such as finessing the language and/or
document metadata for how this specification uses TLS 1.3.
(There are a couple other places in the COMMENT where we might suffer
from scope creep regarding TLS behavior as well, but I did not mark them
as DISCUSS since they are not changing existing specified behavior.)

(2) Let's check whether the quic_transport_parameters TLS extension
should be marked as Recommended or not.  The document currently says
"Yes", and the live registry say 'N'.  That said, the earliest mention I
can see of using 'N' in the archives is in
https://mailarchive.ietf.org/arch/msg/tls-reg-review/z8MOW0bYNP2KIj4XcCXBe2IOKfI/
which seems to just be stating what IANA did when they changed what
codepoint (since there were issues with the initially selected value
'46') and not a reasoned decision.

The perhaps haphazard nature of that change notwithstanding, in my
opinion the 'N' actually is correct, since the extension is not
appropriate for general use *of TLS* (indeed, we require that TLS
implementations that support this document abort the connection if it is
used for non-QUIC connections).

[Ballot comment]
I've noted some potential editorial improvements in a local copy of the
markdown and have made a pull request with them, at
https://github.com/quicwg/base-drafts/pull/4473

The length of the remaining comments notwithstanding, this document is
generally quite well done and a sizeable chunk of my comments are just
relating to subtleties of TLS and our interaction with it; I plan to
change my position to Yes once the Discuss points have been
appropriately discussed.  My apologies in advance to the chairs who will
have to open github issues for all
of these!

We may want to make a pass through the document to normalize the way in
which we discuss 0-RTT.  For example, Section 4.5 mentions that
resumption "can be used without also enabling 0-RTT" as if 0-RTT should
be off by default, but much of the previous discussion involving 0-RTT
treats it as an expected and normal part of the protocl.  (For what
little it's worth, my own personal preference leans towards how RFC 8446
treats 0-RTT data, as an optional and potentially dangerous thing that
should be off by default and only enabled after careful consideration,
though in some ways it actually seems significantly safer in QUIC than
TLS.  Regardless, I do not see any value in re-litigating the question
at this point; I'm just hoping that the document can be consistent about
it.)

Section 2.1

  The 0-RTT handshake is only possible if the client and server have
  previously communicated.  In the 1-RTT handshake, the client is

Pedantically, RFC 8446 does allow the exchange of 0-RTT data for
externally provisioned PSKs (non-resumption), provided that the
necessary parameters are provisioned along with the PSK.

Section 3

Figure 3 shows "TLS Alerts" as being carried over QUIC Transport, but
per §4.8 TLS alerts are translated into QUIC connection errors and are
not sent natively.

  *  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.

I think that if we're going to talk about passing the server certificate
between TLS and QUIC components, we should be very clear about where/how
certificate validation occurs.  For example, it would be pretty
disasterous if TLS passed the certificate to QUIC expecting that QUIC
would do any validation of the peer identity, but QUIC assumed that TLS
would only provide a validated certificate.  Perhaps in §4.1 when we
mention the potential for "additional functions [...] to configure TLS",
we might mention "including certificate validation", if appropriate?

Section 4

  QUIC carries TLS handshake data in CRYPTO frames, each of which
  consists of a contiguous block of handshake data identified by an
  offset and length.  Those frames are packaged into QUIC packets and
  encrypted under the current TLS encryption level.  [...]

I'm not sure I understand the benefit of specifically calling this a
"TLS encryption level".  While it's true that the keys are being
provided by TLS, the cryptographic mechanisms being used are applied by
QUIC.  Furthermore, there's a 1:1 correspondence between the QUIC and
TLS encryption levels, so perhaps it is acceptable to not have a
qualifier at all (for just "under the current encryption level").

  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 packet
  number space.  [...]

I'm a bit confused as to what analogy is being made here.  It seems to
be equating TLS records and QUIC frames, but of course multiple DTLS
records can appear in a single UDP datagram, so the difference between
QUIC and DTLS does not seem quite so large as depicted here.  Of course,
if the analogy is supposed to be between TLS handshake messages and QUIC
frames, or TLS records and QUIC packets, then things would be different,
but I'm not sure what this is intended to say.

Section 4.1.3

  Once the handshake is complete, TLS becomes passive.  TLS can still
  receive data from its peer and respond in kind, but it will not need
  to send more data unless specifically requested - either by an
  application or QUIC.  [...]

(pedantic note) In some sense this is a forward-looking statement *about
TLS*, which is not something the QUIC WG is chartered to work on.  That
said, because of how TLS feature negotiation is done, any new kind of
data spontaneously emitted by TLS would need to be negotiated with an
extension in the handshake, but I don't think we are attempting to
specifically lock down the set of extensions in the TLS handshake for
QUIC connections, so in theory a change to the TLS implementation
defaults could result in QUIC connections that have TLS spontaneously
emit data.  On the gripping hand, I don't really see much need for a
text change here.

Section 4.1.5

Why does the server call Get Handshake twice between receiving the
client Initial and the client's second Hansdhake flight?  IIUC the
interface says that additional handshake data will only be supplied from
TLS in response to input handshake data (and thus, not in response to
TLS generating new keys, which is what the figure suggests to be a
proximal trigger for the second Get Handshake).  We should probably be
careful that the interfaces we document are capable of describing the
case where TLS provides both new keys and handshake bytes, and the
handshake bytes are split across encryption levels (as is the case for
the server's first flight), which may be the motivation for the two Get
Handshake calls depicted here.

Similarly, it's my understanding that the client should still call Get
Handshake after receiving the Initial (but would receive only keys and
not output handshake data at that point).  I'm not sure whether the
figure should indicate that (ineffectual) Get Handshake call.

Should the figure indicate the Handshake Confirmed operation in addition
to Handshake Complete?

Section 4.3

  The TLS implementation does not need to ensure that the ClientHello
  is sufficiently large.  QUIC PADDING frames are added to increase the
  size of the packet as necessary.

Should we reference Section 8.1 of [QUIC-TRANSPORT] for "sufficiently
large"?

Section 4.4

  A client MUST authenticate the identity of the server.  This
  typically involves verification that the identity of the server is
  included in a certificate and that the certificate is issued by a
  trusted entity (see for example [RFC2818]).

I assume that, per normal TLS semantics, this requirement can be met by
PSK authentication as well as certificate authentication.  PSK
authentication has often been an aspect of TLS that has not received
substantial attention, so we may want to preemtively pay some attention
to the PSK case.

  A server MUST NOT use post-handshake client authentication (as
  defined in Section 4.6.2 of [TLS13]), because the multiplexing

Do we want to say anything about not sending the "post_handshake_auth"
extension (defined in the numerologically similar section 4.2.6 of RFC
8446)?  Strictly speaking we don't need to say anything, but efficient
implementations would satisfy the existing QUIC requirement by not
sending the extension and relying on the TLS stack to reject
post-handshake authentication since the extension had not been offered.

Section 4.8

  The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
  generate alerts at the "warning" level.

This seems to be making a normative restriction on the operation of TLS,
which is not in the QUIC WG charter.  Perhaps we should instead
constrain the QUIC implementation to not accept such alerts (and what to
do if they are received) and note that the only closure alerts in RFC
8446 are "close_notify" and "user_cancelled", which are replaced by
equivalent QUIC-level functionality.

Section 4.9

  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

(nit/editorial) I believe that the "both" is meant to apply to "received
and acknowledged" and "when all CRYTO frames [...] have been
acknowledged", but the current formulation does not have parallel
structure between those clauses, so it ends up reading more naturally as
saying that the "both" refers to "received" and "acknowledged".  I don't
have a simple suggestion for fixing it, though (it might require a
significant restructuring to fix), so I'm leaving it here in my comments
rather than incorporating a fix into my editorial PR.  (Any drastic
rewording might consider the rest of the paragraph as well, as it seems
to leave the reader without a clear sense for when it definitely is safe
to discard old keys.)

  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.

Is there anything useful to say about whether it is advisable to make
retransmission packets have the same size as the original transmission?
("No" is a fine answer.)

Section 4.9.3

  0-RTT keys to allow decrypting reordered packets without requiring
  their contents to be retransmitted with 1-RTT keys.  After receiving
  a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;
  the RECOMMENDED time period is three times the Probe Timeout (PTO,
  see [QUIC-RECOVERY]).  A server MAY discard 0-RTT keys earlier if it

Just to check my understanding, the two endpoints will not necessarily
agree on the value of PTO at any given point in time, so this is a
heuristic and not some form of synchronized behavior where the server
replicates the client's loss-detection algorithm precisely?

Section 5

  *  Retry packets use AEAD_AES_128_GCM to provide protection against
      accidental modification or insertion by off-path adversaries; see
      Section 5.8.

[As noted by others, please check the terminology here against
[QUIC-TRANSPORT]; I think the latter uses "attacker" rather than
"adversary" and I haven't internalized the new on-path, limited on-path,
off-path terminology yet, either.]

  *  All other packets have strong cryptographic protections for
      confidentiality and integrity, using keys and algorithms
      negotiated by TLS.

(side note) the handshake keys are "strong" in a certain sense
(unpredictability) but weak in the sense that they are not authenticated
until the handshake has completed.  It may not be necessary to attempt
to express this subtlety in this point in the document, though.

Section 5.1

I think we should say something about the "Context" argument to
HKDF-Expand-Label here.  (I assume it is going to be the same
Transcript-Hash as used for TLS 1.3, but it is not currently specified,
as far as I can see.  I do note that we have some ongoing discussion in
the context of draft-ietf-emu-eap-tls13 that *exporters*, at least,
might better have been specified to use the full transcript including
client Finished, but I am not convinced that we should consider such
drastic changes for our usage, especially since it would neuter 0.5-RTT
unless we add a lot more complexity.)  We may also want to say that
the Length input is determined by the ciphersuite's requirements.
Alternately we could specify in terms of Derive-Secret(), but there's
not really a clear incentive to do so.

Section 5.2

  This secret is determined by using HKDF-Extract (see Section 2.2 of
  [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
  a 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.

[I was going to say something about all-zeros providing the same level
of cryptographic protection, but then I saw the discussion at
https://github.com/quicwg/base-drafts/issues/4325 and the note further
down that new versions of QUIC should pick different salt values.]
I assume this holds for the final RFC version as compared to the I-Ds,
and https://github.com/quicwg/base-drafts/pull/3711 suggests that a new
(random) salt should be chosen for the final RFC version, but I didn't
see an open issue in github for it, so I'll mention it here just in case
that helps.  (The retry key+nonce in §5.8 seem to be in a similar boat,
and the examples in the appendix would need to be adjusted as well, of
course.)

  initial_secret = HKDF-Extract(initial_salt,
                                client_dst_connection_id)

  client_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "client in", "",
                                            Hash.length)
  server_initial_secret = HKDF-Expand-Label(initial_secret,
                                            "server in", "",
                                            Hash.length)

(editorial) I wonder a bit if the rhetoric would be more clear if we did
not call the "initial_secret" a "secret", since it is just an
intermediate value used for constructing secrets and not used directly
to construct keys, itself.  (The idea would be to hew to the TLS 1.3
terminology where specific named Secrets are used to drive
Derive-Secret() calls but other cryptographic inputs are not named with
the word "secret".)

Section 5.3

  QUIC can use any of the cipher suites defined in [TLS13] with the
  exception of TLS_AES_128_CCM_8_SHA256.  [...]

It's a little interesting to use the RFC as the authority on
ciphersuites rather than the registry, but I guess the header protection
scheme requirement makes it more reasonable.  Also, for what it's worth,
there are MAC-only TLS 1.3 ciphersuites in the IANA registry.  I don't
know whether you want to say anything (to forbid?) such things from
being used as QUIC AEADs.

Section 5.4.x

Are we really sure that we want to use normative pseudocode?  I thought
(but cannot currently substantiate) that we typically preferred
normative prose and example pseudocode, since pseudocode somewhat
intrinsically has not-fully-specified semantics.  As some specific (but
not comprehensive!) examples, which bytes of the mask are used when the
packet number is encoded in fewer than 4 bytes, and the key/plaintext
inputs to AES-ECB seem to only be specified in the pseudocode.

Section 5.5

  Once an endpoint successfully receives a packet with a given packet
  number, it MUST discard all packets in the same packet number space
  with higher packet numbers if they cannot be successfully unprotected
  with either the same key, or - if there is a key update - the next
  packet protection key (see Section 6).  [...]

Pedantically, "the next packet protection key" seems to imply
specifically the one next key, not "any subsequent key".  A strict
reading of this text would thust require discarding all packets received
after a second key update, because this clause applies to the very first
packet successfully received, and the third key used is neither the
"same" or "next" key, from that reference point.  (I note that in §6.4
we merely talk about "either the same or newer packet protection keys".)

Section 5.6

  Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
  and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
  as they carry application data.  [...]

I guess STOP_SENDING is not listed as unsafe because it would be an
error to send it in 0-RTT anyway?

Section 5.7

  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 its 1-RTT packets coalesced with a Handshake
  packet containing a copy of the CRYPTO frame that carries the
  Finished message, until one of the Handshake packets is acknowledged.
  This enables immediate server processing for those packets.

This mostly only helps for unauthenticated clients, since for
authenticated clients the Finishsed isn't much good without the
Certificate+CertificateVerify, which are probably too big to include
with every packet.

Section 5.8

  The secret key and the nonce are values derived by calling HKDF-
  Expand-Label using
  0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
  the secret, with labels being "quic key" and "quic iv" (Section 5.1).

HKDF-Expand-Label also takes a "Context" argument; what value is used
for that?  (Presumably the ouput Length argument is set to the lengths
of the stated fields.)

  Retry Pseudo-Packet {
    ODCID Length (8),
    Original Destination Connection ID (0..160),
    Header Form (1) = 1,
    Fixed Bit (1) = 1,
    Long Packet Type (2) = 3,
    Type-Specific Bits (4),
    Version (32),
    DCID Len (8),
    Destination Connection ID (0..160),
    SCID Len (8),
    Source Connection ID (0..160),
    Retry Token (..),
  }

Should we say that the four bits before Version are Unused (not
Type-Specific Bits), as they are in the Retry packet itself?  (I assume
that the the arbitrary value in those bits does need to be preserved,
though.)

Section 6

I suggest noting that, in contrast to TLS, key updates are synchronized
between traffic directions; read keys are updated at the same time that
write keys are (and vice versa).

Section 6.3

  The process of creating new packet protection keys for receiving
  packets could reveal that a key update has occurred.  An endpoint MAY
  perform this process as part of packet processing, but this creates a
  timing signal that can be used by an attacker to learn when key
  updates happen and thus the value of the Key Phase bit in certain
  packets.  Endpoints MAY instead defer the creation of the next set of
  receive packet protection keys until some time after a key update
  completes, up to three times the PTO; see Section 6.5.

(editorial) I think this paragraph (and following) might need a rewrite,
since the phrase "new keys" in the context of a key update could be
ambiguous.  In particular, if we are considering the process of a key
update from generation M to generation N, this text only seems to make
sense if the "new keys" whose generation is being discussed is
generation O (i.e., ones that are not being used to send traffic yet by
anybody), but it is easy to misread "new keys" as being "the ones
installed/activated for use as part of the key update process".  Perhaps
the guidance that endpoints are to maintain both current and next keys
in normal operation should be moved earlier, with the context that you
need to be prepared to handle any valid incoming packets (which includes
those using both current and next keys, since the peer can initiate a
key update) without a timing channel for when key generation is
occurring.  (There may be some similar text in §9.5 that would be
updated in accordance with any changes made here.)

  Once generated, the next set of packet protection keys SHOULD be
  retained, even if the packet that was received was subsequently
  discarded.  [...]

What is "the packet" that was received?

Section 6.5

  An endpoint MAY allow a period of approximately the Probe Timeout
  (PTO; see [QUIC-RECOVERY]) after receiving a packet that uses the new
  key generation before it creates the next set of packet protection
  keys.  [...]

(editorial) Similarly to the previous section, I think the action being
described here might be more properly described as "promoting the 'next'
keys to be the 'current' keys (and thus starting the precomputation for
the subsequent 'next' keys)".  Surly this is not advocating waiting a
PTO before generating the keys you need to process a packet you just
received ... right?

Section 6.6

  The usage limits defined in TLS 1.3 exist for protection against
  attacks on confidentiality and apply to successful applications of
  AEAD protection.  The integrity protections in authenticated
  encryption also depend on limiting the number of attempts to forge
  packets.  TLS achieves this by closing connections after any record
  fails an authentication check.  In comparison, QUIC ignores any
  packet that cannot be authenticated, allowing multiple forgery
  attempts.

QUIC seems very analogous to DTLS in this regard, and DTLS 1.3 also has
similar text about AEAD limits for integrity.  Perhaps a brief mention
that they are essentially the same is useful?

  For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
  is 2^23 encrypted packets; see Appendix B.1.  For
  AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
  number of possible packets (2^62) and so can be disregarded.  For
  AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
  packets; see Appendix B.2.  Applying a limit reduces the probability
  that an attacker can distinguish the AEAD in use from a random
  permutation; see [AEBounds], [ROBUST], and [GCM-MU].
  [...]
  Note:  These limits were originally calculated using assumptions
      about the limits on TLS record size.  The maximum size of a TLS
      record is 2^14 bytes.  In comparison, QUIC packets can be up to
      2^16 bytes.  However, it is expected that QUIC packets will
      generally be smaller than TLS records.  Where packets might be
      larger than 2^14 bytes in length, smaller limits might be needed.

(This seems to say that we're just reusing the TLS numbers even though
in theory we do allow larger packets.  But if that's the case, why do
the actual numbers we present differ from the ones given for DTLS 1.3?
The actual text in Appendix B suggests that we are not actually reusing
the TLS numbers (since we use different estimates for l, and
furthermore, that [GCM-MU] allows larger limits than [AEBounds] as used
by TLS 1.3).)

  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.

DTLS 1.3 imposes essentially the same requirement.  IIUC it would be
acceptable to use the same limit for DTLS 1.3 and for QUIC, and we
should perhaps say that if a cipher is allowed for one it is allowed for
the other (with the same limit), though on second though, we really do
want the analysis to take into account the different assumptions about
the number of blocks in a packet..

Section 9

In various places (e.g., §4.1.4) we recommend to buffer (or "retain")
data that cannot be processed yet.  Perhaps it goes without saying, but
such buffering needs limits in place in order to avoid DoS.

It may be too banal to mention again here that the Initial secret/keys
are not particularly secure, but I'll mention it just in case we want
to.

Section 9.6

  The initial secrets 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.

Also for the Retry Integrity Tag key/nonce secret?

Appendix A.1, A.5

I think that RFC 8446 has us write just "" instead of _ to indicate a
zero-length Context.  I don't see the usage of _ explained anywhere.

Appendix A.2

  The client sends an Initial packet.  The unprotected payload of this
  packet contains the following CRYPTO frame, plus enough PADDING
  frames to make a 1162 byte payload:
  [...]
  The unprotected header includes the connection ID and a 4-byte packet
  number encoding for a packet number of 2:

  c300000001088394c8f03e5157080000449e00000002

If I'm reading this correctly, the variable-length integer encoding of
the packet Length is 0x449e which would indicate a 1182-byte payload
(including packet number), not 1162.

Appendix A.4

Should we mention specifically the Retry Token value?

Appendix B.1.1, B.1.2

I don't think that Theorem 4.3 of [GCM-MU] is the right reference for
both formulae.  (I actually had trouble matching up any of the formulae
in the paper with the ones here due to different variable names, and ran
out of time to dig further.)

Appendix B.2

  TLS [TLS13] and [AEBounds] do not specify limits on usage for
  AEAD_AES_128_CCM.  However, any AEAD that is used with QUIC requires

DTLS 1.3 does, though.

  This produces a relation that combines both encryption and decryption
  attempts with the same limit as that produced by the theorem for
  confidentiality alone.  For a target advantage of 2^-57, this results
  in:

  v + q <= 2^34.5 / l

  By setting "q = v", values for both confidentiality and integrity
  limits can be produced.  Endpoints that limit packets to 2^11 bytes
  therefore have both confidentiality and integrity limits of 2^26.5
  packets.  Endpoints that do not restrict packet size have a limit of
  2^21.5.

DTLS currently has text that does a dedicated computation for "q" and
then substitutes that established value into this last formula to
determine the limit for "v".  Should DTLS switch to using an analysis
more like the one presented here?  (Or vice versa, of course.)

[Ballot comment]
Thanks for a clear and complete document.

Section 17.4: For someone coming to this new, it might not be obvious why requiring the disabling of the spin bit on a fraction of connections is useful. This may be worth a sentence of explanation.

[Ballot comment]
- The third-to-last paragraph of Sec 4.1.3 implies that the transport parameters are not delivered until the handshake is complete. In 8.2 it says that the TPs are "available" but "not fully trusted" before completion. The latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a SETTINGS frame) without any indication of the client transport parameters. I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand.

- 5.8 says the ODCID field "mitigates an off-path attacker's ability to inject a Retry".

First, in quic-transport you defined an off-path attacker (21.1) as someone who can observe but not alter packets. I don't think that's what you mean here, so please use another a term here or explicitly define what you mean in this document. Come to think of it, there are some inconsistent usages of this term in quic-transport as well (14.2.1,17.2.1, 17.2.2 )

Secondly, it is not clear to me what protection this offers beyond the DCID field in the actual Retry Packet (which corresponds to the SCID of the Initial).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-quic-tls-32. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single, new value is to be registered as follows:

Value: [ TBD-at-Registration ]
Extension Name: quic_transport_parameters
TLS 1.3: CH, EE
Recommended: Y
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-quic-tls@ietf.org, magnus.westerlund@ericsson.com, quic@ietf.org, mnot@mnot.net, quic-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using TLS to Secure QUIC) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'Using TLS to Secure QUIC'
  as Proposed Standard

This document is part of a combined 26-day last call for multiple
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:

  - draft-ietf-quic-transport
  - draft-ietf-quic-recovery
  - draft-ietf-quic-tls
  - draft-ietf-quic-invariants
  - draft-ietf-quic-http
  - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review
comments are individually filed as issues in the WG repository at
https://github.com/quicwg/base-drafts if at all possible. A summary email with
URLs to the individual issue should then also be sent to the relevant mailing list
(primarily last-call@ietf.org and quic@ietf.org).

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


Abstract


  This document describes how Transport Layer Security (TLS) is used to
  secure QUIC.

Note to Readers

  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.

  Working Group information can be found at https://github.com/quicwg;
  source code and issues list for this draft can be found at
  https://github.com/quicwg/base-drafts/labels/-tls.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-tls/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF Stream)

The intention is to add this RFC to the downref registry
(https://datatracker.ietf.org/doc/downref/) after this last call.

AD review done. Some minor issues should be resolved prior to IETF Last Call.
Issues found during review: https://mailarchive.ietf.org/arch/msg/quic/AwY6pjElndlNhI8c9i31eoQKWqY/

IETF last call needs Downref for RFC 8439 with intention to add it to Downref registry after LC.
Also has Downref to RFC5869 and external references to NIST AES and SHA standard.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.