Using TLS to Secure QUIC
draft-ietf-quic-tls-34

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

Comment (2021-01-14)
No email
send info
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)
No email
send info
Thank you for a well written document.