Forwarding to the WG. Begin forwarded message: > > From: Radia Perlman <[email protected]> > Subject: Secdir review of draft-ietf-quic-tls-48 > Date: November 1, 2020 at 4:40:47 GMT+2 > To: [email protected], The IESG <[email protected]>, > [email protected] > Resent-From: <[email protected]> > Resent-To: [email protected], [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], [email protected] > > 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 >
signature.asc
Description: Message signed with OpenPGP
