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

[Benjamin Kaduk <[e-mail]>]

Hi Lucas, Martin,

Due to a screw-up on my end with the datatracker "send mail" interstitial,
my reballot to add a couple more comments didn't get sent out as planned
(before you made your pass through them and sent this note).

They are still available in the datatracker, but for simplicity I'll just
paste them here.  Hopefully my error did not cause too much disruption in
your workflow, and thank you again for doing the translation into github
issues.

-Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I think we would benefit from some clarity about the client's response
to a Retry.  Specifically, is the client expected to use the same
ClientHello from the first Initial, in the Initial generated in response
to the Retry?  I did not see any notes about, e.g., transport parameter
values sent by the client changing in response to Retry, and since the
Connection IDs change it seems that we might fall under the Random (and
key share) reuse considerations for TLS.

Abstract

I think this document also specifies some generic bits about how QUIC
uses cryptography, that are not directly related to TLS integration.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On Wed, Jan 06, 2021 at 03:31:22AM +0000, Lucas Pardue wrote:
> 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