Version-Independent Properties of QUIC
draft-ietf-quic-invariants-13

[Ballot comment]
Oooh, thank you for this document -- it is a really useful doc, and I hope to see more of these in the future...

[Ballot comment]
Martin has indicated that my discuss issue will be resolved as an update to the quic transport draft (https://github.com/quicwg/base-drafts/pull/4471), hence clearing the discuss on the invariants draft ...

[Ballot comment]
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,

Regards,

-éric

== COMMENTS ==

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]".

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

[Ballot comment]
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.

[Ballot discuss]
Hi,

A trivial discuss that should hopefully be easy to resolve, and it is plausible that the resolution may end up being in the QUIC transport document:

In this document, the unused bits are defined as:

                  Figure 4: Version Negotiation Packet

  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.

In the QUIC transport document, they are defined as this:

                  Figure 14: Version Negotiation Packet

  The value in the Unused field is selected randomly by the server.
  Clients MUST ignore the value of this field.  Servers SHOULD set the
  most significant bit of this field (0x40) to 1 so that Version
  Negotiation packets appear to have the Fixed Bit field.

I would have expected that these two should be consistent as to whether the Fixed Bit SHOULD be set to 1 or not.  Given draft-thomson-quic-bit-grease-00, it might be better if the SHOULD is removed from QUIC transport, but I will defer to the experts here.

Regards,
Rob

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-quic-invariants-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG
To: IETF-Announce
CC: quic@ietf.org, magnus.westerlund@ericsson.com, quic-chairs@ietf.org, mnot@mnot.net, draft-ietf-quic-invariants@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Version-Independent Properties of QUIC) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'Version-Independent Properties of QUIC'
  as Proposed Standard

This document is part of a combined 26-day last call for multiple
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:

  - draft-ietf-quic-transport
  - draft-ietf-quic-recovery
  - draft-ietf-quic-tls
  - draft-ietf-quic-invariants
  - draft-ietf-quic-http
  - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review
comments are individually filed as issues in the WG repository at
https://github.com/quicwg/base-drafts if at all possible. A summary email with
URLs to the individual issue should then also be sent to the relevant mailing list
(primarily last-call@ietf.org and quic@ietf.org).

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


Abstract


  This document defines the properties of the QUIC transport protocol
  that are expected to remain unchanged over time as new versions of
  the protocol are developed.



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-invariants/


No IPR declarations have been submitted directly on this I-D.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.