Last Call Review of draft-ietf-quic-tls-32
review-ietf-quic-tls-32-secdir-lc-perlman-2020-11-05-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.



This document specifies the cryptographic exchanges and formats associated
with the QUIC protocol, which in turn is an ambitious protocol that could
over time replace TCP. quic-transport, quic-tls, and quic-recovery
represent a triple of I-Ds that are always used together and could be
combined into a single spec, though the length of the existing specs is
already daunting. In many cases, it is impossible to evaluate them
independently.



As an interested outsider, I see these protocols as exceptionally well
designed and the specs exceptionally well written. I could not find even
any nits in a very long spec.



It is misleading to regard this as a specification of running QUIC over
TLS. It is related to TLS in the same way that DTLS is related to TLS: it
imports much of the syntax, but there are many differences and its security
must be evaluated largely independently. My initial reaction to this spec
was to wonder why it did not simply run QUIC over DTLS . I believe the
answer is that careful integration improves the performance and is
necessary for some of the address agility/transition design.



Given its potential importance, this deserves a thorough review by our best
security people. Fortunately, from the acknowledgements list, it appears it
has gotten that.



There are a few aspects of the design that might raise eyebrows. For
example:



1) TLS exchanges start out in cleartext until a key can be negotiated. QUIC
data is always encrypted. The initial packets are encrypted with fixed keys
whose derivation is specified in the I-D until fresh keys are negotiated.
This isn't a security problem...it will just surprise people.



2) Applications using TLS can usually be configured to run over TCP in
contexts where cryptographic protection is not needed. (e.g., use HTTP
instead of HTTPS). Applications using QUIC cannot. That is likely to mean
in practice that it will more frequently be the case that applications
using QUIC will need to connect to servers without certificates signed by a
CA trusted by the client (because that's the substitute when connecting to
a server without a certificate). It's not clear what the spec should say
about that, but perhaps the problem should be acknowledged.


Radia