Move crypto to stream 0

draft-ietf-quic-http.md

@@ -186,14 +186,14 @@ the HTTP framing layer. A QUIC receiver buffers and orders received STREAM
 frames, exposing the data contained within as a reliable byte stream to the
 application.
 
-QUIC reserves Stream 1 for crypto operations (the handshake, crypto config
-updates). Stream 3 is reserved for sending and receiving HTTP control frames,
+QUIC reserves Stream 0 for crypto operations (the handshake, crypto config
+updates). Stream 1 is reserved for sending and receiving HTTP control frames,
 and is analogous to HTTP/2's Stream 0.
 
 When HTTP headers and data are sent over QUIC, the QUIC layer handles most of
 the stream management. An HTTP request/response consumes a pair of streams: This
-means that the client's first request occurs on QUIC streams 5 and 7, the second
-on stream 9 and 11, and so on. The server's first push consumes streams 2 and 4.
+means that the client's first request occurs on QUIC streams 3 and 5, the second
+on stream 7 and 9, and so on. The server's first push consumes streams 2 and 4.
 This amounts to the second least-significant bit differentiating the two streams
 in a request.
 

draft-ietf-quic-tls.md

@@ -170,8 +170,8 @@ out specially.
 {: #schematic title="QUIC and TLS Interactions"}
 
 The initial state of a QUIC connection has packets exchanged without any form of
-protection.  In this state, QUIC is limited to using stream 1 and associated
-packets.  Stream 1 is reserved for a TLS connection.  This is a complete TLS
+protection.  In this state, QUIC is limited to using stream 0 and associated
+packets.  Stream 0 is reserved for a TLS connection.  This is a complete TLS
 connection as it would appear when layered over TCP; the only difference is that
 QUIC provides the reliability and ordering that would otherwise be provided by
 TCP.
@@ -266,15 +266,15 @@ document:
 
 # TLS Usage
 
-QUIC reserves stream 1 for a TLS connection.  Stream 1 contains a complete TLS
+QUIC reserves stream 0 for a TLS connection.  Stream 0 contains a complete TLS
 connection, which includes the TLS record layer.  Other than the definition of a
 QUIC-specific extension (see Section-TBD), TLS is unmodified for this use.  This
 means that TLS will apply confidentiality and integrity protection to its
 records.  In particular, TLS record protection is what provides confidentiality
 protection for the TLS handshake messages sent by the server.
 
 QUIC permits a client to send frames on streams starting from the first packet.
-The initial packet from a client contains a stream frame for stream 1 that
+The initial packet from a client contains a stream frame for stream 0 that
 contains the first TLS handshake messages from the client.  This allows the TLS
 handshake to start with the first packet that a client sends.
 
@@ -288,7 +288,7 @@ TLS, QUIC manages its own key schedule.
 ## Handshake and Setup Sequence
 
 The integration of QUIC with a TLS handshake is shown in more detail in
-{{quic-tls-handshake}}.  QUIC `STREAM` frames on stream 1 carry the TLS
+{{quic-tls-handshake}}.  QUIC `STREAM` frames on stream 0 carry the TLS
 handshake.  QUIC performs loss recovery {{QUIC-RECOVERY}} for this stream and
 ensures that TLS handshake messages are delivered in the correct order.
 
@@ -365,16 +365,16 @@ Additional functions might be needed to configure TLS.
 ### Handshake Interface
 
 In order to drive the handshake, TLS depends on being able to send and receive
-handshake messages on stream 1.  There are two basic functions on this
+handshake messages on stream 0.  There are two basic functions on this
 interface: one where QUIC requests handshake messages and one where QUIC
 provides handshake packets.
 
 A QUIC client starts TLS by requesting TLS handshake octets from
 TLS.  The client acquires handshake octets before sending its first packet.
 
-A QUIC server starts the process by providing TLS with stream 1 octets.
+A QUIC server starts the process by providing TLS with stream 0 octets.
 
-Each time that an endpoint receives data on stream 1, it delivers the octets to
+Each time that an endpoint receives data on stream 0, it delivers the octets to
 TLS if it is able.  Each time that TLS is provided with new data, new handshake
 octets are requested from TLS.  TLS might not provide any octets if the
 handshake messages it has received are incomplete or it has no data to send.
@@ -388,7 +388,7 @@ the server might wish to provide additional or updated session tickets to a
 client.
 
 When the handshake is complete, QUIC only needs to provide TLS with any data
-that arrives on stream 1.  In the same way that is done during the handshake,
+that arrives on stream 0.  In the same way that is done during the handshake,
 new data is requested from TLS after providing received data.
 
 Important:
@@ -685,7 +685,7 @@ packet number limit.  An endpoint MUST initiate a key update ({{key-update}})
 prior to exceeding any limit set for the AEAD that is in use.
 
 TLS maintains a separate sequence number that is used for record protection on
-the connection that is hosted on stream 1.  This sequence number is not visible
+the connection that is hosted on stream 0.  This sequence number is not visible
 to QUIC.
 
 
@@ -903,7 +903,7 @@ server.
 
 # Pre-handshake QUIC Messages {#pre-hs}
 
-Implementations MUST NOT exchange data on any stream other than stream 1 without
+Implementations MUST NOT exchange data on any stream other than stream 0 without
 packet protection.  QUIC requires the use of several types of frame for managing
 loss detection and recovery during this phase.  In addition, it might be useful
 to use the data acquired during the exchange of unauthenticated messages for
@@ -952,9 +952,9 @@ fatal error.
 
 ### STREAM Frames
 
-`STREAM` frames for stream 1 are permitted.  These carry the TLS handshake
+`STREAM` frames for stream 0 are permitted.  These carry the TLS handshake
 messages.  Once 1-RTT keys are available, unprotected `STREAM` frames on stream
-1 can be ignored.
+0 can be ignored.
 
 Receiving unprotected `STREAM` frames for other streams MUST be treated as a
 fatal error.
@@ -993,12 +993,12 @@ sources can be discarded.
 
 `WINDOW_UPDATE` frames MUST NOT be sent unprotected.
 
-Though data is exchanged on stream 1, the initial flow control window is
+Though data is exchanged on stream 0, the initial flow control window is
 sufficiently large to allow the TLS handshake to complete.  This limits the
 maximum size of the TLS handshake and would prevent a server or client from
 using an abnormally large certificate chain.
 
-Stream 1 is exempt from the connection-level flow control window.
+Stream 0 is exempt from the connection-level flow control window.
 
 
 ### Denial of Service with Unprotected Packets
@@ -1340,6 +1340,10 @@ many others.
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-tls-01:
+
+- Moved TLS handshake to QUIC Stream 0
+
 ## Since draft-ietf-quic-tls-00:
 
 - Changed bit used to signal key phase.

draft-ietf-quic-transport.md

@@ -211,10 +211,10 @@ QUIC relies on a combined crypto and transport handshake for setting up a secure
 transport connection.  QUIC connections are expected to commonly use 0-RTT
 handshakes, meaning that for most QUIC connections, data can be sent immediately
 following the client handshake packet, without waiting for a reply from the
-server.  QUIC provides a dedicated stream (Stream ID 1) to be used for
+server.  QUIC provides a dedicated stream (Stream ID 0) to be used for
 performing the crypto handshake and QUIC options negotiation.  The format of the
 QUIC options and parameters used during negotiation are described in this
-document, but the handshake protocol that runs on Stream ID 1 is described in
+document, but the handshake protocol that runs on Stream ID 0 is described in
 the accompanying crypto handshake draft {{QUIC-TLS}}.
 
 ## Stream Multiplexing
@@ -665,12 +665,12 @@ be revalidated once the cryptographic handshake has completed (see
 ## Crypto and Transport Handshake {#handshake}
 
 QUIC relies on a combined crypto and transport handshake to minimize connection
-establishment latency.  QUIC provides a dedicated stream (Stream ID 1) to be
+establishment latency.  QUIC provides a dedicated stream (Stream ID 0) to be
 used for performing a combined connection and security handshake (streams are
 described in detail in {{streams}}).  The crypto handshake protocol encapsulates
 and delivers QUIC's transport handshake to the peer on the crypto stream.  The
 first QUIC packet sent by client to the server MUST carry handshake information
-as data on Stream ID 1.
+as data on Stream ID 0.
 
 ### Transport Parameters and Options
 
@@ -1621,10 +1621,9 @@ as an ordered byte-stream.  Data received out of order MUST be buffered for
 later delivery, as long as it is not in violation of the receiver's flow control
 limits.
 
-The crypto handshake stream, Stream 1, MUST NOT be subject to congestion control
-or connection-level flow control, but MUST be subject to stream-level flow
-control. An endpoint MUST NOT send data on any other stream without consulting
-the congestion controller and the flow controller.
+The crypto handshake stream, Stream 0, MUST NOT be subject to congestion control
+or flow control. An endpoint MUST NOT send data on any other stream without
+consulting the congestion controller and the flow controller.
 
 Flow control is described in detail in {{flow-control}}, and congestion control
 is described in the companion document {{QUIC-RECOVERY}}.
@@ -1990,6 +1989,13 @@ thanks to all.
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-transport-01:
+
+- Moved crypto handshake to Stream 0
+
+- Removed ability to exclude application streams from connection-level
+  flow-control
+
 ## Since draft-ietf-quic-transport-00:
 
 - Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag