Using TLS to Secure QUIC
RFC 9001

Note: This ballot was opened for revision 33 and is now closed.

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/

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).

Alvaro Retana No Objection

Erik Kline No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

Comment (2021-01-05 for -33)
No email
send info
Thank you for a well written document.

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?

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!

(Magnus Westerlund; former steering group member) Yes

Yes ( for -33)
No email
send info

(Alissa Cooper; former steering group member) (was No Record, Yes) No Objection

No Objection (2021-01-04 for -33)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -33)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -33)
No email
send info