Draft: draft-ietf-quic-manageability

Commentary: least four datagrams we 'll call " QUIC Client Hello " , " QUIC   " , and " Initial Completion " , and " Handshake Completion " , for purposes of this illustration , as shown in { { fig - handshake } } . I mean , you can call them that for reference purposes , but there 's no such thing as a " QUIC Client Hello " ( or ClientHello ) . Calling something " Initial Completion " when it might not contain any Initial packets might confuse people when they go looking for more details . Maybe " Client Initial , " " Server Initial , " " Client Finished , " and " Server Finished " ? It mixes layers , but those are at least things that occur in the referenced packets . 
 Or , to avoid using TLS message names consistently , s / Finished / Confirmation 
 Should I conclude from the absence of comment since February that we are all reasonably content with " Client Initial " , " Server Initial " , " Client Completion " , and " Server Completion " ? If so I 'm happy to create the PR to save  a job . But I do n't want to do that if these are not the best names . 
 This was assigned to  has he wanted to take a stab . 
 That 's fine I 'll leave it to  .
Paragraph (version A):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams we'll call "QUIC Client Hello", "QUIC Server
Hello", and "Initial Completion", and "Handshake Completion", for
purposes of this illustration, as shown in fig-handshake.
Paragraph (version B):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams we'll call "Client Initial", "Server Initial",
and "Client Completion", and "Server Completion", for purposes of
this illustration, as shown in fig-handshake.
Paragraph (version A):
A typical handshake starts with the client sending of a QUIC Client
Hello datagram as shown in fig-client-hello, which elicits a QUIC
Server Hello datagram as shown in fig-server-hello typically
containing three packets: an Initial packet with the Server Hello, a
Handshake packet with the rest of the server's side of the TLS
handshake, and initial 1-RTT data, if present.
Paragraph (version A):
The Initial Completion datagram contains at least one Handshake
packet and some also include an Initial packet.
Paragraph (version A):
Datagrams that contain a QUIC Initial Packet (Client Hello, Server
Hello, and some Initial Completion) contain at least 1200 octets of
UDP payload.  This protects against amplification attacks and
verifies that the network path meets the requirements for the minimum
QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is
accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Paragraph (version A):
The content of QUIC Initial packets are 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 B):
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 Server Initial,
a Handshake packet with the rest of the server's side of the TLS
handshake, and initial 1-RTT data, if present.
Paragraph (version B):
The Client Completion datagram contains at least one Handshake packet
and some also include an Initial packet.
Paragraph (version B):
Datagrams that contain a Client Initial Packet (Client Initial,
Server Initial, and some Client Completion) contain at least 1200
octets of UDP payload.  This protects against amplification attacks
and verifies that the network path meets the requirements for the
minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This
is accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Paragraph (version B):
The content of Client Initial packets are 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 Short Header packets transmitted after
the handshake belong to cryptographic and transport contexts.  The
Initial Completion fig-init-complete and the Handshake 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 Hello 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 Hello 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 Initial Completion datagram does not expose any additional
information; however, recognizing it 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):
Similar to Initial Completion, Handshake Completion also exposes no
additional information; observing it serves only to determine that
the handshake has completed.
Paragraph (version A):
When the client uses 0-RTT connection resumption, 0-RTT data may also
be seen in the QUIC Client Hello datagram, as shown in fig-client-
hello-0rtt.
Paragraph (version A):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data that can be sent
in the first round is limited by the initial congestion window,
typically around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Paragraph (version B):
Initial, Handshake, and the Short Header 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 B):
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 B):
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 B):
The Client Completion datagram does not expose any additional
information; however, recognizing it 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 B):
Similar to Client Completion, Server Completion also exposes no
additional information; observing it serves only to determine that
the handshake has completed.
Paragraph (version B):
When the client uses 0-RTT connection resumption, 0-RTT data may also
be seen in the Client Initial datagram, as shown in fig-client-
initial-0rtt.
Paragraph (version B):
In a 0-RTT Client Initial datagram, the PADDING frame is only present
if necessary to increase the size of the datagram with 0RTT data to
at least 1200 bytes.  Additional datagrams containing only 0-RTT
protected long header packets may 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 round is limited by the initial congestion window,
typically around 10 packets (see Section 7.2 of QUIC-RECOVERY).