Version-Independent Properties of QUIC
RFC 8999

Note: This ballot was opened for revision 12 and is now closed.

Benjamin Kaduk Yes

Comment (2021-01-04 for -12)
My PR at
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

(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

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

Erik Kline Yes

Martin Duke Yes

Comment (2020-12-29 for -12)
Due to the discussion in quic-transport, some of the description of the VN packet here may turn out to be misleading (as “supported versions” fields may be used for other things). We should reevaluate once that is resolved.

Again, the use of “off-path attacker” in sec 7 is inconsistent with the other documents.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2021-01-05 for -12)
I concur with Barry's observation about references.

Robert Wilton (was Discuss) No Objection

Comment (2021-01-06 for -12)
Martin has indicated that my discuss issue will be resolved as an update to the quic transport draft (, hence clearing the discuss on the invariants draft ...

Roman Danyliw No Objection

Comment (2021-01-05 for -12)
No email
send info
Thank you to Yoav Nir for the SECDIR review.

Warren Kumari No Objection

Comment (2021-01-06 for -12)
Oooh, thank you for this document -- it is a really useful doc, and I hope to see more of these in the future...

Éric Vyncke No Objection

Comment (2021-01-05 for -12)
Thank you for the work put into this document. I find the idea of having an 'invariant' document interesting.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,




Should the use of UDP transport be also an invariant ?

-- Abstract --
I have hard time to reconciliate "...that are expected to remain unchanged..." with the intended status of standards track... and later with the sentence "A protocol that does not conform to the properties described in this document is not QUIC" in section 5.4.

-- Section 1 --
Are we really sure that QUIC will always between TWO endpoints ? I.e., no multicast at all ?

-- Section 3 --
I second Barry's point, the presence of "This document uses terms and notational conventions from [QUIC-TRANSPORT]." renders QUIC-TRANSPORT as a normative reference

-- Section 4 --
Isn't this section somehow redundant as the last paragraph of section 3 states "This document uses ... notational conventions from [QUIC-TRANSPORT]".

(Alissa Cooper; former steering group member) Yes

Yes (2021-01-05 for -12)
I made a couple of suggestions for clarity at <>.

(Magnus Westerlund; former steering group member) Yes

Yes ( for -12)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2021-01-04 for -12)
Not at DISCUSS level, but I do question whether quic-transport should be a normative reference, as none of this really makes much sense without that.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -12)
No email
send info