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