Benjamin Kaduk's Yes on draft-ietf-quic-invariants-12: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-quic-invariants-12: 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-invariants/



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

My PR at https://github.com/quicwg/base-drafts/pull/4473
contains one editorial suggestion for this document.

Section 5.2

Should we call out that the short header admits a zero-length
Destination Connection ID, implying that there will not always be a
visible connection ID?

Section 5.3

In the discussion of DTLS 1.2 connection IDs we had a fair bit of
discussion about what "opaque" means, whether any internal structure
(e.g., when variable-length CIDs are used) must be self-delineating,
which endpoint(s) need to know the self-delineating format, etc..  This
was largely in the context of what data is used as input to the MAC for
non-AEAD cipher modes (in the document as sent to the IESG by the WG,
the party that does not know the CID structure could be convinced to
generate a MAC using a modified CID and create a MAC value that would be
valid for a different plaintext, leading to a change in where the
cid_length field is placed in the input), and I don't expect the topics
we discussed to lead to any change in the text here.  The only possible
thing I could think of is that the field is "opaque" at the protocol
level but may have internal structure known to the endpoint that chooses
it (but that's arguably self-evident).

Section 6

   Only the most significant bit of the first byte of a Version
   Negotiation packet has any defined value.  The remaining 7 bits,
   labeled Unused, can be set to any value when sending and MUST be
   ignored on receipt.

What's the motivation behind leaving it totally free for the sender to
pick values, as opposed to recommending or mandating that the bits be
set to zero?

   Version Negotiation packets do not use integrity or confidentiality
   protection.  Specific QUIC versions might include protocol elements
   that allow endpoints to detect modification or corruption in the set
   of supported versions.

Are these protocol elements expected to be in the version negotiation
packet or elsewhere?

   randomly selected by a client.  Echoing both connection IDs gives
   clients some assurance that the server received the packet and that
   the Version Negotiation packet was not generated by an off-path
   attacker.

(I agree with Martin D about the terminology question here and in
Section 7, which is the location he remarked upon.)

Section 7

   The Version Negotiation packet described in this document is not
   integrity-protected; it only has modest protection against insertion
   by off-path attackers.  An endpoint MUST authenticate the contents of
   a Version Negotiation packet if it attempts a different QUIC version
   as a result.

Can we give some indication of how this authentication might be done?

Appendix A

   *  The Version field in a QUIC long header is the same in both
      directions

(I note that this implicitly assumes there are only two directions.  We do
explicitly assume there are only two parties involved, so perhaps this
is acceptable.)