Rename and consolidate packet types

draft-ietf-quic-tls.md

@@ -665,8 +665,8 @@ protected with secrets derived from the client's connection ID. Specifically:
 The HKDF for the handshake secrets and keys derived from them uses the SHA-256
 hash function {{FIPS180}}.
 
-The salt value is a 16 octet sequence shown in the figure in hexadecimal
-notation.  Future versions of QUIC SHOULD generate a new salt value, thus
+The salt value is a 20 octet sequence shown in the figure in hexadecimal
+notation. Future versions of QUIC SHOULD generate a new salt value, thus
 ensuring that the keys are different for each version of QUIC. This prevents a
 middlebox that only recognizes one version of QUIC from seeing or modifying the
 contents of handshake packets from future versions.
@@ -798,7 +798,7 @@ connection.  For example, if TLS is using the TLS_AES_128_GCM_SHA256, the
 AEAD_AES_128_GCM function is used.
 
 All QUIC packets other than Version Negotiation and Stateless Reset packets are
-protected with an AEAD algorithm {{!RFC5116}}. Handshake packets are protected
+protected with an AEAD algorithm {{!AEAD}}. Cleartext packets are protected
 with AEAD_AES_128_GCM and a key derived from the client's connection ID (see
 {{handshake-secrets}}).  This provides protection against off-path attackers and
 robustness against QUIC version unaware middleboxes, but not against on-path

draft-ietf-quic-transport.md

@@ -417,8 +417,6 @@ The following packet types are defined:
 | 0x03 | Retry                         | {{packet-retry}}            |
 | 0x04 | Handshake                     | {{packet-handshake}}        |
 | 0x05 | 0-RTT Protected               | {{packet-protected}}        |
-| 0x06 | 1-RTT Protected (key phase 0) | {{packet-protected}}        |
-| 0x07 | 1-RTT Protected (key phase 1) | {{packet-protected}}        |
 {: #long-packet-types title="Long Header Packet Types"}
 
 The header form, packet type, connection ID, packet number and version fields of
@@ -572,9 +570,9 @@ unless it has received a packet from the server.  If the client has received a
 packet from the server, the connection ID field uses the value provided by the
 server.
 
-The packet number used for Initial packets is initialized with a random value
-each time the new contents are created for the packet.  Retransmissions of the
-packet contents increment the packet number by one, see ({{packet-numbers}}).
+The first Initial packet that is sent by a client contains a random
+31-bit value.  All subsequent packets contain a packet number that is
+incremented by one, see ({{packet-numbers}}).
 
 The payload of a Initial packet consists of a STREAM frame (or frames)
 for stream 0 containing a cryptographic handshake message, with enough PADDING
@@ -604,11 +602,11 @@ A Retry packet is never explicitly acknowledged in an ACK frame
 by a client.  Receiving another Initial packet implicitly acknowledges a Retry
 packet.
 
-After receiving a Retry packet, the client uses a new Initial packet containing
-the next cryptographic handshake message.  The client retains the state of its
-cryptographic handshake, but discards all transport state.  The new Initial
-packet includes a newly randomized packet number, STREAM frames on stream 0 that
-start again at an offset of 0, and the original connection ID.
+After receiving a Retry packet, the client uses a new 
+Initial packet containing the next cryptographic handshake message.  The client
+retains the state of its cryptographic handshake, but discards all transport
+state.  The Initial packet that is generated in response to a Retry packet 
+includes STREAM frames on stream 0 that start again at an offset of 0.
 
 Continuing the cryptographic handshake is necessary to ensure that an attacker
 cannot force a downgrade of any cryptographic parameters.  In addition to
@@ -652,15 +650,11 @@ that are used to remove packet protection.
 Packets protected with 0-RTT keys use a type value of 0x05.  The connection ID
 field for a 0-RTT packet is selected by the client.
 
-The client can send 0-RTT packets after having received a packet from the server
-if that packet does not complete the handshake.  Even if the client receives a
-different connection ID from the server, it MUST NOT update the connection ID it
-uses for 0-RTT packets.  This enables consistent routing for all 0-RTT packets.
-
-Packets protected with 1-RTT keys that use long headers use a type value of 0x06
-for key phase 0 and 0x07 for key phase 1; see {{QUIC-TLS}} for more details on
-the use of key phases.  The connection ID field for these packet types MUST
-contain the value selected by the server, see {{connection-id}}.
+The client can send 0-RTT packets after receiving a Handshake packet
+({{packet-server-cleartext}}), if that packet does not complete the handshake.
+Even if the client receives a different connection ID in the Handshake
+packet, it MUST continue to use the connection ID selected by the client for
+0-RTT packets, see {{connection-id}}.
 
 The version field for protected packets is the current QUIC version.
 
@@ -680,18 +674,21 @@ using the CONNECTION_ID flag.  When present, the Connection ID is in the same
 location in all packet headers, making it straightforward for middleboxes, such
 as load balancers, to locate and use it.
 
-The client MUST choose a random connection ID and use it in Initial packets
-({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).  If the client
-has received any packet from the server, it uses the connection ID it received
-from the server for all packets other than 0-RTT packets.
+The client MUST choose a random connection ID and use it in Initial
+packets ({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).
 
 When the server receives a Initial packet and decides to proceed with the
 handshake, it chooses a new value for the connection ID and sends that in a
-Handshake packet.  The server MAY choose to use the value that the client
-initially selects.
+Handshake packet ({{packet-handshake}}).  The server MAY choose to
+use the value that the client initially selects.
+
+Once the client receives the connection ID that the server has chosen, it MUST
+use it for all subsequent Handshake ({{packet-handshake}}) and
+1-RTT ({{packet-protected}}) packets but not for 0-RTT packets
+({{packet-protected}}).
 
-Server's Version Negotiation ({{packet-version}}) and Stateless Retry
-({{packet-server-stateless}}) packets MUST use connection ID selected by the
+Server's Version Negotiation ({{packet-version}}) and Retry
+({{packet-retry}}) packets MUST use connection ID selected by the
 client.
 
 
@@ -752,16 +749,6 @@ The first set of packets sent by an endpoint MUST include the low 32-bits of the
 packet number.  Once any packet has been acknowledged, subsequent packets can
 use a shorter packet number encoding.
 
-A client that receives a Version Negotiation ({{packet-version}}) or Retry
-packet ({{packet-retry}}) MUST generate a new initial packet number.  This
-ensures that the first transmission attempt for a Initial packet
-({{packet-initial}}) always contains a randomized packet number, but packets
-that contain retransmissions increment the packet number.
-
-A client MUST NOT generate a new initial packet number if it discards the server
-packet.  This might happen if the information the client retransmits its Client
-Initial packet.
-
 
 ## Handling Packets from Different Versions {#version-specific}