Using TLS to Secure QUIC
Note: This ballot was opened for revision 33 and is now closed.
Martin Duke Yes
Comment (2020-12-22 for -33)
- 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).
Benjamin Kaduk (was Discuss) Yes
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/
Magnus Westerlund Yes
Deborah Brungard No Objection
Alissa Cooper (was No Record, Yes) No Objection
Roman Danyliw No Objection
Comment (2021-01-05 for -33)
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?
Erik Kline No Objection
Murray Kucherawy No Objection
Warren Kumari No Objection
Comment (2021-01-06 for -33)
Thank you for a well written and easy to understand document. Also thanks to Sarah for the OpsDir review!
Barry Leiba No Objection
Alvaro Retana No Objection
Martin Vigoureux No Objection
Robert Wilton No Objection
Comment (2021-01-05 for -33)
Thank you for a well written document.