Draft: draft-ietf-quic-manageability

Commentary: As noted in the " The QUIC Handshake " is written in a way that could cause readers to assume things such as there 's only one datagram containing a Client Initial . This PR changes the naming from ' Client / Server Initial / Finished datagram ' to ' Client / Server Initial / Finished flight ' and makes related changes to make it read correctly . The diagrams have not been fully updated yet . 
 QUIC handshakes may or may not coalesce packets , which is stated , but I 'm worried it could be missed by a reader . I think it 'd be good to clarify that any portion of the server or client flight could span multiple datagrams . In particular , I 'm worried this paragraph could mislead people , because unless the connection is resumed , the Handshake CRYPTO data typically spans multiple datagrams . Similarly , the client or server 's Initial can span multiple datagrams , though that 's not currently common : 
 I think some clarity about multiple packets / datagrams would be helpful in the Extracting SNI section as well : Specifically : 1 ) Client initial data can span multiple datagrams , and the SNI could be in any of them . 2 ) A single client Initial packet can contain multiple CRYPTO frames , and there 's no strict requirement they 're in order of offset . 
 can you maybe propose a PR ? :-) 
 Yes , possibly later today after I finish reviewing the draft . 
 are you still planning to do a PR here ? 
 I will unless someone beats me to it , but I 've been on paternity leave for 10 days . had some suggested text for the SNI section , but I can try to fix " The QUIC Handshake " and assume  's text is a good start for SNI . 
 While writing the PR , I discovered a problem I 'm not sure how to fix , which is how does an observer know when the handshake is complete for the server , given the server can start using 1 - RTT keys immediately after receiving the client hello ? Receipt of the client 's 1 - RTT packet does n't guarantee anything , because the server ca n't process it if it does n't have keys . 
 lgtm , one potential diagram nit .
Paragraph (version A):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams labelled "Client Initial", "Server Initial", and
"Client Completion", and "Server Completion", in the illustration
shown in fig-handshake.
Paragraph (version A):
Packets in the handshake belong to three separate cryptographic and
transport contexts ("Initial", which contains observable payload, and
"Handshake" and "1-RTT", which do not).  QUIC packets in separate
contexts during the handshake are generally coalesced (see coalesced)
in order to reduce the number of UDP datagrams sent during the
handshake.
Paragraph (version A):
A typical handshake starts with the client sending of a Client
Initial datagram as shown in fig-client-initial, which elicits a
Server Initial datagram as shown in fig-server-initial typically
containing three packets: an Initial packet with the beginning of the
server's side of the TLS handshake, a Handshake packet with the rest
of the server's side of the TLS handshake, and 1-RTT data, if
present.
Paragraph (version A):
The Client Completion datagram contains at least one Handshake packet
and could also include an Initial packet.
Paragraph (version B):
The QUIC handshake can normally be recognized on the wire through
four flights of datagrams labelled "Client Initial", "Server
Initial", "Client Completion", and "Server Completion", in the
illustration shown in fig-handshake.
Paragraph (version B):
Packets in the handshake belong to three separate cryptographic and
transport contexts ("Initial", which contains observable payload, and
"Handshake" and "1-RTT", which do not).  QUIC packets in separate
contexts during the handshake can be coalesced (see coalesced) in
order to reduce the number of UDP datagrams sent during the
handshake.  QUIC packets can be lost and reordered, so packets within
a flight might not be sent close in time, though the sequence of the
flights will not change, because one flight depends upon the peer's
previous flight.
Paragraph (version B):
A handshake starts with the client sending one or more datagrams
containing Initial packets as shown in fig-client-initial, which
elicits the Server Initial response as shown in fig-server-initial
typically containing three types of packets: Initial packet(s) with
the beginning of the server's side of the TLS handshake, Handshake
packet(s) with the rest of the server's portion of the TLS handshake,
and 1-RTT packet(s), if present.
Paragraph (version B):
The Client Completion flight contains at least one Handshake packet
and could also include an Initial packet.
Paragraph (version A):
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant.  They are therefore
considered visible in this illustration.  The content of QUIC
Handshake packets are encrypted using keys established during the
initial handshake exchange, and are therefore not visible.
Paragraph (version A):
Initial, Handshake, and the 1-RTT packets transmitted after the
handshake belong to cryptographic and transport contexts.  The Client
Completion fig-init-complete and the Server Completion fig-hs-
complete datagrams finish these first two contexts, by sending the
final acknowledgment and finishing the transmission of CRYPTO frames.
Paragraph (version A):
The Client Initial datagram exposes version number, source and
destination connection IDs without encryption.  Information in the
TLS Client Hello frame, including any TLS Server Name Indication
(SNI) present, is obfuscated using the Initial secret.  Note that the
location of PADDING is implementation-dependent, and PADDING frames
might not appear in a coalesced Initial packet.
Paragraph (version A):
The Server Initial datagram also exposes version number, source and
destination connection IDs in the clear; information in the TLS
Server Hello message is obfuscated using the Initial secret.
Paragraph (version A):
The Client Completion datagram does not expose any additional
information; however, as the destination connection ID is server-
selected, it usually is not the same ID than in the Client Initial
datagram.  Client Completion datagram can be used to determine that a
handshake has completed (see sec-confirm), and for three-way
handshake RTT estimation as in sec-rtt.
Paragraph (version A):
When the client uses 0-RTT connection resumption, the Client Initial
datagram can also carry 0-RTT data, as shown in fig-client-initial-
0rtt.
Paragraph (version A):
In a 0-RTT Client Initial datagram, the PADDING frame is only present
if necessary to increase the size of the datagram with 0-RTT data to
at least 1200 bytes.  Additional datagrams containing only 0-RTT
packets with long headers could be sent from the client to the server
after the Client Initial datagram, containing the rest of the 0-RTT
data.  The amount of 0-RTT protected data that can be sent in the
first flight is limited by the initial congestion window, typically
to around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Paragraph (version B):
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant and considered
visible in this illustration.  The content of QUIC Handshake packets
are encrypted using keys established during the initial handshake
exchange, and are therefore not visible.
Paragraph (version B):
Initial, Handshake, and 1-RTT packets belong to different
cryptographic and transport contexts.  The Client Completion fig-
init-complete and the Server Completion fig-hs-complete flights
conclude the Initial and Handshake contexts, by sending final
acknowledgments and CRYPTO frames.
Paragraph (version B):
A Client Initial packet exposes the version, source and destination
connection IDs without encryption.  The payload of the Initial packet
is obfuscated using the Initial secret.  The complete TLS Client
Hello, including any TLS Server Name Indication (SNI) present, is
sent in one or more CRYPTO frames across one or more QUIC Initial
packets.
Paragraph (version B):
The Server Initial datagram also exposes version number, source and
destination connection IDs in the clear; the payload of the Initial
packet(s) is obfuscated using the Initial secret.
Paragraph (version B):
The Client Completion flight does not expose any additional
information; however, as the destination connection ID is server-
selected, it usually is not the same ID than in the Client Initial.
Client Completion flights contain 1-RTT packets which indicate the
handshake has completed (see sec-confirm) on the client, and for
three-way handshake RTT estimation as in sec-rtt.
Paragraph (version B):
When the client uses 0-RTT connection resumption, the Client Initial
flight can also include one or more 0-RTT packets, as shown in fig-
client-initial-0rtt.
Paragraph (version B):
When a 0-RTT packet is coalesced with an Initial packet, the datagram
will be padded to 1200 byes.  Additional datagrams containing only
0-RTT packets with long headers can be sent after the client Initial
packet(s), containing more 0-RTT data.  The amount of 0-RTT protected
data that can be sent in the first flight is limited by the initial
congestion window, typically to around 10 packets (see Section 7.2 of
QUIC-RECOVERY).