Martin Duke's Yes on draft-ietf-quic-tls-33: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-quic-tls-33: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-tls/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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