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