On Mon, Nov 2, 2020 at 1:39 AM Lars Eggert <[email protected]> wrote: > 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. > > I found these statements by Radia the most useful:
> 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. > > Good luck in reading. Behcet > > 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 > > > > >
