Subject: Re: Consensus Call on issues closed by the -02 drafts

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Apr 2017 14:34:38 +1000

Reminder: there is a consensus call for these issues outstanding, and we haven't had any discussion since the call, leading us to believe that everyone understands and agrees with the proposed resolutions. 

If you need clarification, to ask questions, or more time, please say so soon, otherwise we'll declare consensus.

Regards,

> On 17 Mar 2017, at 8:22 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
> 
> The -02 drafts incorporate the proposed resolutions to a number of issues that have been discussed. 
> 
> Those issues are listed below. Please have a look through them, and if there are any resolutions that you feel need more discussion, please bring it up, either here on the mailing list or in the issue itself.
> 
> Issues that we need to discuss more will be reopened. The remaining ones will be flagged as `has-consensus`.
> 
> There are a lot of them, so we're not going to do this until after the Chicago meeting (at the earliest) to give people a chance to discuss on the list as well as in the meeting.
> 
> See <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving-issues> for a reminder about the process we're using here. Even when we have consensus, we can reopen an issue if new information emerges (and that can take a variety of forms).
> 
> This list is also available at <https://github.com/quicwg/base-drafts/issues?utf8=✓&q=is%3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus>.
> 
> Cheers,
> 
> ## Transport
> 
> #35  - Starting packet number
> #40  - Variable-length fields
> #49  - Transport parameter advertisements
> #50  - Updating Transport parameters
> #51  - QUIC version number scheme
> #52  - Source address validation
> #55  - What can change in a different version
> #56  - Extending flags
> #57  - Advice on STOP_WAITING
> #59  - Define ICSL parameter
> #62  - Finding frame lengths
> #63  - ACK retransmission
> #64  - Path MTU Discovery
> #66  - Remove STOP_WAITING
> #67  - Picking packet number length
> #69  - Minimum packet size
> #70  - Move ACK/STOP_WAITING into the packet header
> #74  - Application-defined error codes
> #104 - Priority in QUIC Transport
> #108 - Maximum stream number
> #112 - Greasing version negotiation
> #114 - STREAM retransmission priority
> #116 - COPTs as empty transport parameters
> #117 - SCUP
> #118 - Source Address Token encoding
> #119 - Server-proposed connection ID
> #124 - Alt-Svc quic version hint
> #126 - Separate transport parameters for 0-RTT
> #133 - Connection ID in version negotiation
> #135 - DoS using Version Negotiation Packets
> #136 - First client packet size
> #139 - Minimum MTU
> #147 - Reflection Attack Resistance
> #148 - QUIC packet header complexity
> #157 - Updated information in retransmitted frames
> #158 - Padding between frames
> #159 - Time format
> #162 - RST_STREAM and flow control
> #163 - RST_STREAM and connection-level flow control
> #164 - Padding handshake packets
> #168 - Ordering of ACK Frame fields
> #174 - Stream Reservation
> #181 - Remove SETTINGS[_ACK]
> #185 - Reliable identification of the initial packet for a connection
> #201 - Do streams 0 and 1 count towards MSPC?
> #204 - Streams not contributing to connection-level flow control
> #243 - AEAD Associated Data
> #244 - Need a NONCE in version negotiation packets
> #262 - Don't encrypt client handshake with 1-RTT keys
> #285 - Policing packet number size
> #286 - Outstanding packets and packet number size
> #289 - Avoid using Public Reset where possible
> #291 - ACKing ACK
> #292 - Does any portion of the QUIC framing require 4 byte alignment?
> #293 - Does the connection id need to be in a consistent location?
> #295 - Connection ID on a version negotiation packet
> #308 - "retransmitting" old timestamps in ACK frames
> #323 - Smaller packet number representations
> #340 - Scale flow control offsets
> #341 - What does it mean to acknowledge something?
> #347 - Clarify meaning/definition of GOAWAY
> #349 - When should server-chosen connection IDs be sent and how are they indicated?
> #352 - Does GOAWAY need an error code
> 
> 
> ## Recovery
> 
> #63  - ACK retransmission
> #169 - Response to lost handshake packets
> 
> 
> ## TLS
> 
> #12  - Decouple QUIC version and ALPN 
> #25  - Key update forward secrecy
> #26  - Which bit can KEY_PHASE use?
> #27  - Fix KEY_PHASE for early data
> #34  - ACK rules and packet protection
> #87  - QUIC advertisement description
> #97  - Version Negotiation + TLS
> #226 - Authenticating public parts of the packet header
> #243 - AEAD Associated Data
> #262 - Don't encrypt client handshake with 1-RTT keys
> #272 - Signaling TLS handshake failure
> 
> 
> ## HTTP
> 
> 75  - SETTING syncronization
> 87  - QUIC advertisement description
> 95  - CONNECT
> 104 - Priority in QUIC Transport
> 124 - Alt-Svc quic version hint
> 127 - Frame header reserved bits
> 154 - HTTP Stream ID Size
> 173 - Size of HTTP Header Sequence Numbers
> 176 - RST_STREAM breaks HPACK
> 181 - Remove SETTINGS[_ACK]
> 202 - HTTP: Why are we defining CONNECT?
> 204 - Streams not contributing to connection-level flow control
> 229 - Use a quic= parameter for Alt-Svc rather than collide with existing use of v=
> 242 - HTTP extension mechanisms
> 297 - Remove the quic parameter from Alt-Svc
> 364 - Mid-frame close
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 11 Apr 2017 14:23:37 -0400

> #126 - Separate transport parameters for 0-RTT

I am not certain we are ready to fully close #126.  I have expressed some
concerns about the complexity of the current approach on the list some time
before, and proposed a simplified scheme
(<https://www.ietf.org/mail-archive/web/quic/current/msg01496.html>).

  -- Victor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Apr 2017 10:52:59 -0700

I concur with Victor that this could use additional discussion, though I
would
want to consider yet another pattern, in which the client always gets its
params from the server and in 0-RTT tells the server "this is what you
said last time" as we do with ALPN. In any case, needs more discussion.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Apr 2017 11:09:42 -0700

I have reviewed all the transport issues. I believe that nearly all
of them can be marked closed, modulo the ones noted below. I am still
reviewing the issues for the other drafts, but there is a lot of
duplication, so I expect to get to them today.

I had requested that this document the existing Google version numbers,
but this does not seem to have happened, and it should.

I am fine with closing this for now, but it is tied directly to the
question of packet format and in particular how to handle packet
number and connection ID, so it will need revision if we decide
to adopt an encrypted packet number/conn-id proposal (which I
intend to make in Paris if not before).

As I noted previously, it seems like it would be be better to make
padding a security layer function. We could then use the TLS-style
padding (or whatever). I'm not sure we have consensus on this point
yet.

Why don't we put the SETTINGS frame in a TLS extension. That would
remove a bunch of race conditions. I have filed an issue for this.

https://github.com/quicwg/base-drafts/issues/436

-Ekr

On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham <[email-masked]> wrote:

> Those issues are listed below. Please have a look through them, and if
> there are any resolutions that you feel need more discussion, please bring
> it up, either here on the mailing list or in the issue itself.
>
> There are a lot of them, so we're not going to do this until after the
> Chicago meeting (at the earliest) to give people a chance to discuss on the
> list as well as in the meeting.
>
> See <https://github.com/quicwg/base-drafts/blob/master/
> CONTRIBUTING.md#resolving-issues> for a reminder about the process we're
> using here. Even when we have consensus, we can reopen an issue if new
> information emerges (and that can take a variety of forms).
>
> This list is also available at <https://github.com/quicwg/
> base-drafts/issues?utf8=✓&q=is%3Aissue%20is%3Aclosed%
> 20label%3Adesign%20-label%3Ahas-consensus
> <https://github.com/quicwg/base-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus>
> >.
>
> Cheers,
>
> ## Transport
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Apr 2017 19:56:19 +0000

Re: SETTINGS in TLS, rather than putting another new extension, the more general form of this would be to say that, just as the TLS extension carries an opaque blob that QUIC uses for settings, the QUIC blob also contains an application-specified blob.  Reserve a QUIC settings value for “application-specified data” and let each application define the layout as they desired.

From: QUIC [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, April 13, 2017 11:10 AM
To: Mark Nottingham <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: Consensus Call on issues closed by the -02 drafts

https://github.com/quicwg/base-drafts/issues/436<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F436&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=IWH4qd8Q%2BpFtf%2F12WB9BdJMwCyA4ExBE7cy8LJGHDmI%3D&reserved=0>

-Ekr

On Fri, Mar 17, 2017 at 2:22 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
Everyone,

See <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving-issues<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fblob%2Fmaster%2FCONTRIBUTING.md%23resolving-issues&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=%2BDPPUV0Hcqo6HJ6rv6U5sc%2F%2B3%2B0XAq46VgAY9WWD9I4%3D&reserved=0>> for a reminder about the process we're using here. Even when we have consensus, we can reopen an issue if new information emerges (and that can take a variety of forms).

This list is also available at <https://github.com/quicwg/base-drafts/issues?utf8=✓&q=is%3Aissue%20is%3Aclosed%20label%3Adesign%20-label%3Ahas-consensus<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%3Futf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2520is%253Aclosed%2520label%253Adesign%2520-label%253Ahas-consensus&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=46V3qzH1p29I%2B7mBtU23OVP%2BsyS2VITrvuuXCmRaVls%3D&reserved=0>>.

Cheers,

## Transport

## Recovery

#63  - ACK retransmission

## TLS

## HTTP

--
Mark Nottingham   https://www.mnot.net/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=ENc544Qg%2FqUdn0JdglK94LjDbv3J5sKxi7tEjh7CC3k%3D&reserved=0>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Apr 2017 13:51:45 -0700

On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop <[email-masked]>
wrote:

> Re: SETTINGS in TLS, rather than putting another new extension, the more
> general form of this would be to say that, just as the TLS extension
> carries an opaque blob that QUIC uses for settings, the QUIC blob also
> contains an application-specified blob.  Reserve a QUIC settings value for
> “application-specified data” and let each application define the layout as
> they desired.
>

Yes, this would be a reasonable design.

An alternative would be simply to allocate both sets of settings out of the
same code point space.

-Ekr

>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, April 13, 2017 11:10 AM
> *To:* Mark Nottingham <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>
> *Subject:* Re: Consensus Call on issues closed by the -02 drafts
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F436&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=IWH4qd8Q%2BpFtf%2F12WB9BdJMwCyA4ExBE7cy8LJGHDmI%3D&reserved=0>
>
>
>
> -Ekr
>
>
>
>
>
> CONTRIBUTING.md#resolving-issues
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fblob%2Fmaster%2FCONTRIBUTING.md%23resolving-issues&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=%2BDPPUV0Hcqo6HJ6rv6U5sc%2F%2B3%2B0XAq46VgAY9WWD9I4%3D&reserved=0>>
> for a reminder about the process we're using here. Even when we have
> consensus, we can reopen an issue if new information emerges (and that can
> take a variety of forms).
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%3Futf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2520is%253Aclosed%2520label%253Adesign%2520-label%253Ahas-consensus&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=46V3qzH1p29I%2B7mBtU23OVP%2BsyS2VITrvuuXCmRaVls%3D&reserved=0>
> >.
>
> Cheers,
>
> ## Transport
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cb5527f46365749aa1b1c08d482985f51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277038587188465&sdata=ENc544Qg%2FqUdn0JdglK94LjDbv3J5sKxi7tEjh7CC3k%3D&reserved=0>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Apr 2017 13:56:45 -0700

Replying to myself...
I have gone through all the issues and I believe that aside from the issues
listed above and the emails I just sent to the list, I believe we can
provisionally
close the issues you list.

-Ekr

On Thu, Apr 13, 2017 at 11:09 AM, Eric Rescorla <[email-masked]> wrote:

>> See <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUT
>> ING.md#resolving-issues> for a reminder about the process we're using
>> here. Even when we have consensus, we can reopen an issue if new
>> This list is also available at <https://github.com/quicwg/bas
>> e-drafts/issues?utf8=✓&q=is%3Aissue%20is%3Aclosed%20label%3A
>> design%20-label%3Ahas-consensus

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Apr 2017 21:23:24 +0000

Mmm, perhaps.  But remember you need to accommodate multiple applications.  We could carve off part of the space to be app-controlled and each app define its own meanings for values in that range, as we’ve done for error codes, I suppose.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, April 13, 2017 1:52 PM
To: Mike Bishop <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; IETF QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: Consensus Call on issues closed by the -02 drafts

On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Re: SETTINGS in TLS, rather than putting another new extension, the more general form of this would be to say that, just as the TLS extension carries an opaque blob that QUIC uses for settings, the QUIC blob also contains an application-specified blob.  Reserve a QUIC settings value for “application-specified data” and let each application define the layout as they desired.

-Ekr

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Thursday, April 13, 2017 11:10 AM
To: Mark Nottingham <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>
Subject: Re: Consensus Call on issues closed by the -02 drafts

-Ekr

Cheers,

## Transport

## Recovery

#63  - ACK retransmission

## TLS

## HTTP

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Apr 2017 14:24:02 -0700

On Thu, Apr 13, 2017 at 2:23 PM, Mike Bishop <[email-masked]>
wrote:

> Mmm, perhaps.  But remember you need to accommodate multiple
> applications.  We could carve off part of the space to be app-controlled
> and each app define its own meanings for values in that range, as we’ve
> done for error codes, I suppose.
>

Correct.

That's what I had in mind, but I'm not picky about the encoding.

-Ekr

>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Thursday, April 13, 2017 1:52 PM
> *To:* Mike Bishop <[email-masked]>
> *Cc:* Mark Nottingham <[email-masked]>; IETF QUIC WG <[email-masked]>; Lars
> Eggert <[email-masked]>
>
> On Thu, Apr 13, 2017 at 12:56 PM, Mike Bishop <
> [email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 15:37:04 +1000

> said last time" as we do with ALPN. In any case, needs more discussion.

I don't think that this is exactly how TLS works.  In TLS, the client
sends its usual ALPN list and the server is expected to remember from
last time which it chose.  The server negotiates ALPN as normal -
though this might be biased by the possibility of 0-RTT - and it only
accepts 0-RTT if the ALPN choice is the same.  Note that the client
has to include ALPN as normal in case the server decides differently
this time (for instance, maybe it supports h2 over http/1.1).

In any case, I agree that this model is a better design.  I see two
options that vary only slightly and are superior to both Victor's
proposed design and the current one (which I agree is broken):

1. the client remembers from last time
2. the server sends new 0-RTT-specific parameters with its session
ticket and the client remembers these instead

In both cases, both client and server are required to remember. If the
server is unhappy with the choices that it remembers, then it rejects
0-RTT.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 19 Apr 2017 15:52:21 +1000

Based upon feedback, I've reopened the following issues:

#51, #55, #126, #158, #181

The remaining issues listed below have been marked `has-consensus`.

Going through the issues list, I see we missed a handful of issues (mostly early ones). I'll send out a separate call for them shortly, just to close the loop.

Cheers,