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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 04 Jan 2021 20:56:39 -0800

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Jan 2021 03:31:22 +0000

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.

> https://datatracker.ietf.org/doc/draft-ietf-quic-invariants/

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

> it (but that's arguably self-evident).

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

> Section 7, which is the location he remarked upon.)

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

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

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

> explicitly assume there are only two parties involved, so perhaps this
https://github.com/quicwg/base-drafts/issues/4512

Cheers,
Lucas
On behalf of QUIC WG Chairs

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Jan 2021 21:47:17 -0800

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.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Jan 2021 21:48:20 -0800

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

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

-Ben