Hi Radia, thank you for the review. I've opened a GitHub issue for any discussion related to this review: https://github.com/quicwg/base-drafts/issues/4323
There is also a milestone at https://github.com/quicwg/base-drafts/milestone/7. Thanks, Lars > On 2020-11-1, at 4:40, Radia Perlman <[email protected]> wrote: > > 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
