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

[Lucas Pardue <[e-mail]>]

Hi Ben,

Thanks for the review. I've captured your comments as issues on the QUIC WG
GItHub repository. Links to each are provided as in-line responses.

On Tue, Jan 5, 2021 at 4:56 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> 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?
>

https://github.com/quicwg/base-drafts/issues/4508


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

https://github.com/quicwg/base-drafts/issues/4509


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

https://github.com/quicwg/base-drafts/issues/4510


> 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?
>

https://github.com/quicwg/base-drafts/issues/4511


> 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.)
>
>
https://github.com/quicwg/base-drafts/issues/4512

Cheers,
Lucas
On behalf of QUIC WG Chairs