Merge branch 'master' into push-id-seq

Author: MikeBishop

draft-ietf-quic-http.md

@@ -423,6 +423,10 @@ DATA frames MUST be associated with an HTTP request or response.  If a DATA
 frame is received on the control stream, the recipient MUST respond with a
 connection error ({{errors}}) of type HTTP_WRONG_STREAM.
 
+DATA frames MUST contain a non-zero-length payload.  If a DATA frame is received
+with a payload length of zero, the recipient MUST respond with a stream error
+({{errors}}) of type HTTP_MALFORMED_DATA.
+
 ### HEADERS {#frame-headers}
 
 The HEADERS frame (type=0x1) is used to carry part of a header set, compressed
@@ -1301,6 +1305,10 @@ The original authors of this specification were Robbie Shade and Mike Warres.
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-http-05
+
+- Made push ID sequential, add MAX_PUSH_ID, remove SETTINGS_ENABLE_PUSH (#709)
+
 ## Since draft-ietf-quic-http-04
 
 - Cite RFC 5234 (#404)
@@ -1309,7 +1317,7 @@ The original authors of this specification were Robbie Shade and Mike Warres.
 - SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
 - Restored GOAWAY (#696)
 - Identify server push using Push ID rather than a stream ID (#702,#281)
-- Made push ID sequential, add MAX_PUSH_ID, remove SETTINGS_ENABLE_PUSH (#709)
+- DATA frames cannot be empty (#700)
 
 ## Since draft-ietf-quic-http-03
 

draft-ietf-quic-recovery.md

@@ -733,6 +733,14 @@ This document has no IANA actions.  Yet.
 > **RFC Editor's Note:**  Please remove this section prior to
 > publication of a final version of this document.
 
+## Since draft-ietf-quic-recovery-04
+
+No significant changes.
+
+## Since draft-ietf-quic-recovery-03
+
+No significant changes.
+
 ## Since draft-ietf-quic-recovery-02
 
 - Integrate F-RTO (#544, #409)

draft-ietf-quic-tls.md

@@ -541,7 +541,7 @@ older than 1.3 is negotiated.
 
 QUIC requires that the initial handshake packet from a client fit within the
 payload of a single packet.  The size limits on QUIC packets mean that a record
-containing a ClientHello needs to fit within 1197 octets.
+containing a ClientHello needs to fit within 1171 octets.
 
 A TLS ClientHello can fit within this limit with ample space remaining.
 However, there are several variables that could cause this limit to be exceeded.
@@ -1262,25 +1262,27 @@ able to inject these packets.  Timing and packet retransmission information from
 `ACK` frames is critical to the functioning of the protocol, but these frames
 might be spoofed or altered.
 
-Endpoints MUST NOT use an unprotected `ACK` frame to acknowledge data that was
-protected by 0-RTT or 1-RTT keys.  An endpoint MUST ignore an unprotected `ACK`
-frame if it claims to acknowledge data that was sent in a protected packet.
-Such an acknowledgement can only serve as a denial of service, since an endpoint
+Endpoints MUST NOT use an `ACK` frame in an unprotected packet to acknowledge
+packets that were protected by 0-RTT or 1-RTT keys.  An endpoint MUST treat
+receipt of an `ACK` frame in an unprotected packet that claims to acknowledge
+protected packets as a connection error of type OPTIMISTIC_ACK.  An endpoint
 that can read protected data is always able to send protected data.
 
-ISSUE:
+Note:
 
-: What about 0-RTT data?  Should we allow acknowledgment of 0-RTT with
-  unprotected frames?  If we don't, then 0-RTT data will be unacknowledged until
-  the handshake completes.  This isn't a problem if the handshake completes
-  without loss, but it could mean that 0-RTT stalls when a handshake packet
-  disappears for any reason.
+: 0-RTT data can be acknowledged by the server as it receives it, but any
+  packets containing acknowledgments of 0-RTT data cannot have packet protection
+  removed by the client until the TLS handshake is complete.  The 1-RTT keys
+  necessary to remove packet protection cannot be derived until the client
+  receives all server handshake messages.
 
-An endpoint SHOULD use data from unprotected or 0-RTT-protected `ACK` frames
-only during the initial handshake and while they have insufficient information
-from 1-RTT-protected `ACK` frames.  Once sufficient information has been
-obtained from protected messages, information obtained from less reliable
-sources can be discarded.
+An endpoint SHOULD use data from `ACK` frames carried in unprotected packets or
+packets protected with 0-RTT keys only during the initial handshake.  All `ACK`
+frames contained in unprotected packets that are received after successful
+receipt of a packet protected with 1-RTT keys MUST be discarded.  An endpoint
+SHOULD therefore include acknowledgments for unprotected and any packets
+protected with 0-RTT keys until it sees an acknowledgment for a packet that is
+both protected with 1-RTT keys and contains an `ACK` frame.
 
 
 ### Updates to Data and Stream Limits
@@ -1559,6 +1561,14 @@ many others.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-tls-04
+
+- Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
+
+## Since draft-ietf-quic-tls-03
+
+No significant changes.
+
 ## Since draft-ietf-quic-tls-02
 
 - Updates to match changes in transport draft

draft-ietf-quic-transport.md

@@ -522,6 +522,10 @@ from the triggering client packet.  This allows clients some assurance that the
 server received the packet and that the Version Negotiation packet was not
 carried in a packet with a spoofed source address.
 
+A Version Negotiation packet is never explicitly acknowledged in an ACK frame by
+a client.  Receiving another Client Initial packet implicitly acknowledges a
+Version Negotiation packet.
+
 The payload of the Version Negotiation packet is a list of 32-bit versions which
 the server supports, as shown below.
 
@@ -570,11 +574,11 @@ the packet contents increment the packet number by one, see
 ({{packet-numbers}}).
 
 The payload of a Client Initial packet consists of a STREAM frame (or frames)
-for stream 0 containing a cryptographic handshake message, plus any PADDING
-frames necessary to ensure that the packet is at least the minimum PMTU size
-(see {{packetization}}).  The stream in this packet always starts at an offset
-of 0 (see {{stateless-retry}}) and the complete cyptographic handshake message
-MUST fit in a single packet (see {{handshake}}).
+for stream 0 containing a cryptographic handshake message, with enough PADDING
+frames that the packet is at least 1200 octets (see {{packetization}}).  The
+stream in this packet always starts at an offset of 0 (see {{stateless-retry}})
+and the complete cyptographic handshake message MUST fit in a single packet (see
+{{handshake}}).
 
 The client uses the Client Initial Packet type for any packet that contains an
 initial cryptographic handshake message.  This includes all cases where a new
@@ -595,6 +599,10 @@ The packet number and connection ID fields echo the corresponding fields from
 the triggering client packet.  This allows a client to verify that the server
 received its packet.
 
+A Server Stateless Retry packet is never explicitly acknowledged in an ACK frame
+by a client.  Receiving another Client Initial packet implicitly acknowledges a
+Server Stateless Retry packet.
+
 After receiving a Server Stateless Retry packet, the client uses a new Client
 Initial packet containing the next cryptographic handshake message.  The client
 retains the state of its cryptographic handshake, but discards all transport
@@ -1084,11 +1092,17 @@ idle_timeout (0x0003):
 : The idle timeout is a value in seconds that is encoded as an unsigned 16-bit
   integer.  The maximum value is 600 seconds (10 minutes).
 
-stateless_reset_token (0x0005):
+A server MUST include the following transport parameters:
+
+stateless_reset_token (0x0006):
 
 : The Stateless Reset Token is used in verifying a stateless reset, see
   {{stateless-reset}}.  This parameter is a sequence of 16 octets.
 
+A client MUST NOT include a stateless reset token.  A server MUST treat receipt
+of a stateless_reset_token transport parameter as a connection error of type
+TRANSPORT_PARAMETER_ERROR.
+
 An endpoint MAY use the following transport parameters:
 
 omit_connection_id (0x0004):
@@ -1106,7 +1120,7 @@ max_packet_size (0x0005):
   the endpoint is willing to receive, encoded as an unsigned 16-bit integer.
   This indicates that packets larger than this limit will be dropped.  The
   default for this parameter is the maximum permitted UDP payload of 65527.
-  Values below 1252 are invalid.  This limit only applies to protected packets
+  Values below 1200 are invalid.  This limit only applies to protected packets
   ({{packet-protected}}).
 
 
@@ -1199,6 +1213,15 @@ client MUST terminate with a VERSION_NEGOTIATION_ERROR error code if
 version negotiation occurred but it would have selected a different version
 based on the value of the supported_versions list.
 
+When an endpoint accepts multiple QUIC versions, it can potentially interpret
+transport parameters as they are defined by any of the QUIC versions it
+supports.  The version field in the QUIC packet header is authenticated using
+transport parameters.  The position and the format of the version fields in
+transport parameters MUST either be identical across different QUIC versions, or
+be unambiguously different to ensure no confusion about their interpretation.
+One way that a new format could be introduced is to define a TLS extension with
+a different codepoint.
+
 
 ## Stateless Retries {#stateless-retry}
 
@@ -1918,6 +1941,10 @@ Unlike TCP SACKs, QUIC ACK blocks are irrevocable.  Once a packet has
 been acknowledged, even if it does not appear in a future ACK frame,
 it remains acknowledged.
 
+A client MUST NOT acknowledge Version Negotiation or Server Stateless Retry
+packets.  These packet types contain packet numbers selected by the client, not
+the server.
+
 QUIC ACK frames contain a timestamp section with up to 255 timestamps.
 Timestamps enable better congestion control, but are not required for correct
 loss recovery, and old timestamps are less valuable, so it is not guaranteed
@@ -2268,19 +2295,18 @@ An endpoint MUST NOT reduce their MTU below this number, even if it receives
 signals that indicate a smaller limit might exist.
 
 Clients MUST ensure that the first packet in a connection, and any
-retransmissions of those octets, has a QUIC packet size of least 1232 octets for
-an IPv6 packet and 1252 octets for an IPv4 packet.  In the absence of extensions
-to the IP header, padding to exactly these values will result in an IP packet
-that is 1280 octets.
+retransmissions of those octets, has a QUIC packet size of least 1200 octets.
+The packet size for a QUIC packet includes the QUIC header and integrity check,
+but not the UDP or IP header.
 
-The initial client packet SHOULD be padded to exactly these values unless the
+The initial client packet SHOULD be padded to exactly 1200 octets unless the
 client has a reasonable assurance that the PMTU is larger.  Sending a packet of
 this size ensures that the network path supports an MTU of this size and helps
 reduce the amplitude of amplification attacks caused by server responses toward
 an unverified client address.
 
 Servers MUST ignore an initial plaintext packet from a client if its total size
-is less than 1232 octets for IPv6 or 1252 octets for IPv4.
+is less than 1200 octets.
 
 If a QUIC endpoint determines that the PMTU between any pair of local and remote
 IP addresses has fallen below 1280 octets, it MUST immediately cease sending
@@ -3193,8 +3219,22 @@ Issue and pull request numbers are listed with a leading octothorp.
 
 ## Since draft-ietf-quic-transport-04
 
-- Introduce STOP_SENDING frame (#165)
-- Removed GOAWAY (#696)
+- Introduce STOP_SENDING frame, RST_STREAM only resets in one direction (#165)
+- Removed GOAWAY; application protocols are responsible for graceful shutdown
+  (#696)
+- Reduced the number of error codes (#96, #177, #184, #211)
+- Version validation fields can't move or change (#121)
+- Removed versions from the transport parameters in a NewSessionTicket message
+  (#547)
+- Clarify the meaning of "bytes in flight" (#550)
+- Public reset is now stateless reset and not visible to the path (#215)
+- Reordered bits and fields in STREAM frame (#620)
+- Clarifications to the stream state machine (#572, #571)
+- Increased the maximum length of the Largest Acknowledged field in ACK frames
+  to 64 bits (#629)
+- truncate_connection_id is renamed to omit_connection_id (#659)
+- CONNECTION_CLOSE terminates the connection like TCP RST (#330, #328)
+- Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
 
 ## Since draft-ietf-quic-transport-03