Ballot for draft-ietf-quic-tls
Yes
No Objection
Note: This ballot was opened for revision 33 and is now closed.
Thank you to Radia Perlman for the SECDIR review and the ensuing discussion about this review. Two areas of recommended clarity: ** Section 4. Recommend a bit more text up front describing the notion of “encryption levels”. This section first introduces the concept by noting that “Those frames are packaged into QUIC packets and encrypted under the current TLS encryption level”. Later in Section 4.1.3, it is noted that “Four encryption levels are used, producing keys for Initial, 0-RTT, Handshake, and 1-RTT packets” which makes these “levels” seem only like categories. In describing specific processing there is text such as “When TLS provides keys for a higher encryption level …” which now describes a relatively ordering perhaps with something have having or less. I might be helpful to include an early narrative on what “higher” and “lower” and encryption “levels” means and how level changes occur (i.e., explicitly linking them to changes in the QUIC state machine). ** Section 4.4. Per the peer authentication text, should it be acknowledged that due the general-purpose nature of the protocol, peer validation practices may will need to be further defined by applications?
Thank you for a well written and easy to understand document. Also thanks to Sarah for the OpsDir review!
Thanks for the updates and discussion prompted by my initial review comments. For reference, those comments and the corresponding github issue links are available at https://mailarchive.ietf.org/arch/msg/quic/D4Bc7u5BBAbiZMSOkirIS5uM5is/
- The third-to-last paragraph of Sec 4.1.3 implies that the transport parameters are not delivered until the handshake is complete. In 8.2 it says that the TPs are "available" but "not fully trusted" before completion. The latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a SETTINGS frame) without any indication of the client transport parameters. I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand. - 5.8 says the ODCID field "mitigates an off-path attacker's ability to inject a Retry". First, in quic-transport you defined an off-path attacker (21.1) as someone who can observe but not alter packets. I don't think that's what you mean here, so please use another a term here or explicitly define what you mean in this document. Come to think of it, there are some inconsistent usages of this term in quic-transport as well (14.2.1,17.2.1, 17.2.2 ) Secondly, it is not clear to me what protection this offers beyond the DCID field in the actual Retry Packet (which corresponds to the SCID of the Initial).
Thank you for a well written document.