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 < nore...@ietf.org> 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
