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

[Benjamin Kaduk <[e-mail]>]

Gah, double-screwup.  This was meant for -tls, not -invariants.

Sorry again, and will resend properly (third time lucky!).

-Ben

On Tue, Jan 05, 2021 at 09:47:23PM -0800, Benjamin Kaduk wrote:
> 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