Draft: draft-ietf-quic-transport

Commentary: This takes some of the concepts that in and massages those into the introduction . The net effect is two - fold : a little more substance in this section and the addition of prominent , early references to the key supporting documents . It removes the bullet feature list and puts that into the abstract as a single sentence . I have also reordered this slightly . There is no perfect ordering here , but this no longer slavishly adheres to the document structure . 
 I have reviewed this document as part of the security directorate 's ongoing effort to review all IETF documents being processed by the IESG . These comments were written primarily for the benefit of the security area directors . Document editors and WG chairs should treat these comments just like any other last call comments . This document specifies the cryptographic exchanges and formats associated with the QUIC protocol , which in turn is an ambitious protocol that could over time replace TCP . quic - transport , quic - tls , and quic - recovery represent a triple of I - Ds that are always used together and could be combined into a single spec , though the length of the existing specs is already daunting . In many cases , it is impossible to evaluate them independently . As an interested outsider , I see these protocols as exceptionally well designed and the specs exceptionally well written . I could not find even any nits in a very long spec . It is misleading to regard this as a specification of running QUIC over TLS . It is related to TLS in the same way that DTLS is related to TLS : it imports much of the syntax , but there are many differences and its security must be evaluated largely independently . My initial reaction to this spec was to wonder why it did not simply run QUIC over DTLS . I believe the answer is that careful integration improves the performance and is necessary for some of the address agility / transition design . Given its potential importance , this deserves a thorough review by our best security people . Fortunately , from the acknowledgements list , it appears it has gotten that . There are a few aspects of the design that might raise eyebrows . For example : 1 ) TLS exchanges start out in cleartext until a key can be negotiated . QUIC data is always encrypted . The initial packets are encrypted with fixed keys whose derivation is specified in the I - D until fresh keys are negotiated . This is n't a security will just surprise people . 2 ) Applications using TLS can usually be configured to run over TCP in contexts where cryptographic protection is not needed . ( e.g. , use HTTP instead of HTTPS ) . Applications using QUIC can not . That is likely to mean in practice that it will more frequently be the case that applications using QUIC will need to connect to servers without certificates signed by a CA trusted by the client ( because that 's the substitute when connecting to a server without a certificate ) . It 's not clear what the spec should say about that , but perhaps the problem should be acknowledged . Radia 
 ( 2 ) is the only comment here that raises a possible text change , and it 's editorial - only . I 'm not certain it 's properly a security issue with the protocol , but a note in Security Considerations that people might be more inclined to do self - signed certs with a transport that does n't let them opt out of TLS would n't break anything . 
 Proposing to do nothing . The only comment that raises concerns ( 2 ) is not unique to QUIC , but a pre - existing concern with TLS as well . 
 I agree with now clearly that TLS is integrated with QUIC . 
 I agree with too . 
 The proposed resolution was to close to with action , which was signalled to the appropriate review channel . Hearing no pushback , I 'm closing this . 
 Section 1 provides an ultrafast introduction to the problem , and very little on the fundamentals of how the protocol works . It would be useful if there a process by which the reader is gradually immersed in the detail . 
 That is , in fact , the intended structure of the document . Section 1 provides an extremely high - level view of the protocol ; section 1.1 lays out how these high - level concepts are discussed in greater depth in Sections 2 - 14 , with wire - level details reserved for Sections 15 - 20 . Is the suggestion that there should be a new Section 2 which goes into more detail than Section 1 , but less detail than Sections 2 - 14 ? Or is the suggestion more detail in Section 1.1 about the concepts before the forward references ? 
 What said above . The draft is already super long , so while we can make additions for clarity , I 'd want to keep it as short as possible . 
 Adding the text in a new section 2 would be a good idea . Whilst the draft is long , it has to be readable by readers that are not yet experts on the protocol . My overall impression during my review was that it was a draft written by people that understood the protocol for people that understood the protocol , but the target audience for a major new IETF transport protocol is much wider than that . It is also the same with the very abbreviated text on some important design decisions . This is fine whilst the original designers are around , but the work has a lifetime longer than the participation lifetime of the original designers , and a few words now save a lot of discussion and more importantly mistakes and complexity as the design is developed , possibly decades in the future .
Paragraph (version A):
This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation.
Paragraph (version B):
This document defines the core of the QUIC transport protocol.  QUIC
provides applications with flow-controlled streams for structured
communication, low-latency connection establishment, and network path
migration.  QUIC includes security measures that ensure
confidentiality, integrity, and availability in a range of deployment
circumstances.  Accompanying documents describe the integration of
TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.
Paragraph (version A):
QUIC establishes a connection, which is a stateful interaction
between a client and server.  The primary purpose of a connection is
to support the structured exchange of data by an application
protocol.
Paragraph (version B):
QUIC is a secure general-purpose transport protocol.  This document
defines version 1 of QUIC, which conforms to the version-independent
properties of QUIC defined in QUIC-INVARIANTS.
Paragraph (version B):
QUIC is a connection-oriented protocol that creates a stateful
interaction between a client and server.
Paragraph (version B):
The QUIC handshake combines negotiation of cryptographic and
transport parameters.  QUIC integrates the TLS (TLS13) handshake,
although using a customized framing for protecting packets.  The
integration of TLS and QUIC is described in more detail in QUIC-TLS.
The handshake is structured to permit the exchange of application
data as soon as possible.  This includes an option for clients to
send data immediately (0-RTT), which might require prior
communication to enable.
Paragraph (version B):
Endpoints communicate in QUIC by exchanging QUIC packets.  Most
packets contain frames, which carry control information and
application data between endpoints.  QUIC authenticates all packets
and encrypts as much as is practical.  QUIC packets are carried in
UDP datagrams (UDP) to better facilitate deployment in existing
systems and networks.
Paragraph (version A):
The QUIC handshake combines negotiation of cryptographic and
transport parameters.  The handshake is structured to permit the
exchange of application data as soon as possible.  This includes an
option for clients to send data immediately (0-RTT), which might
require prior communication to enable.
Paragraph (version A):
QUIC connections are not strictly bound to a single network path.
Connection migration uses connection identifiers to allow connections
to transfer to a new network path.
Paragraph (version A):
Frames are used in QUIC to communicate between endpoints.  One or
more frames are assembled into a QUIC packet.  QUIC authenticates all
packets and encrypts as much as is practical.  QUIC packets are
carried in UDP datagrams (UDP) to better facilitate deployment in
existing systems and networks.
Paragraph (version B):
QUIC provides the necessary feedback to implement reliable delivery
and congestion control.  An algorithm for detecting and recovering
from loss of data is described in QUIC-RECOVERY.  QUIC depends on
congestion control to avoid network congestion.  An exemplary
congestion control algorithm is also described in QUIC-RECOVERY.
Paragraph (version B):
QUIC connections are not strictly bound to a single network path.
Connection migration uses connection identifiers to allow connections
to transfer to a new network path.  Only clients are able to migrate
in this version of QUIC.  This design also allows connections to
continue after changes in network topology or address mappings, such
as might be caused by NAT rebinding.