Re: Stream0 Design Team Proposal

[Eric Rescorla <[e-mail]>]

On Wed, May 23, 2018 at 3:23 PM, Mike Bishop <[e-mail]> wrote:

> So I think that’s roughly six PRs we should expect to see out of the
> design team’s proposal.  A few of them have dependencies on each other, but
> they seem mostly separable.  It sounds like several of them have consensus
> in the design team, but not all of them, and it would be good to be able to
> discuss them separately
>

Hi Mike,

The vast majority of the proposal had consensus in the design team. It's
true that there are a few pieces that had somewhat less support and we just
made a decision in the interest of having a coherent proposal. These points
are called out explicitly in the Overview document.

With that said, I think it would be better to resist the urge to try to
decompose the proposal into its minimal constituent pieces. In many cases,
even when a piece is in theory independent from other pieces, there are
interactions and so we made a conscious decision to present it as a whole
proposal. Obviously, if there are explicit things that people object to,
they should raise them, but I think trying to break the proposal up into
pieces and consider them individually -- while intellectually interesting
--  isn't going to be that productive.

-Ekr



>
> -----Original Message-----
> From: QUIC <[e-mail]> On Behalf Of Martin Thomson
> Sent: Tuesday, May 22, 2018 8:01 PM
> To: Ian Swett <ianswett=[e-mail]>
> Cc: [e-mail]; QUIC WG <[e-mail]>
> Subject: Re: Stream0 Design Team Proposal
>
>
>
> First of all, thanks to the design team for the work they have done.  I
> haven't digested everything yet, but I think that I have a good sense of
> the shape of the proposal.
>
>
>
> Overall, this looks like a workable design.  It's a lot more invasive of
> the cryptographic handshake implementation than I had thought people were
> willing to stomach originally.  But it's clear that we've run into problems
> with the current, more abstract API and this is a fairly natural way to
> split TLS.  I've spent a little time thinking about how this might be
> implemented and I think that it's not going to be *too* painful.  The proof
> will be in the pudding there though.
>
>
>
> In looking at the PR, I really appreciate seeing all the changes together.
>
> BTW, the link above points to the wrong PR, so be careful (it appears to
> have the same content, but that's not guaranteed).  The actual PR is here:
>
> https://github.com/quicwg/base-drafts/pull/1377
>
>
>
> I've pushed a branch to the main repo so that you can preview the entire
> document set: https://quicwg.github.io/base-drafts/stream0/
>
>
>
> It seems like there are some core changes here and a bunch of separable or
> at least secondary changes.  I'm sure that each one has its own
> justification, but that isn't always clear. The following changes seem like
> they are separable:
>
>
>
> * The use of separate packet number spaces
>
> * The Retry packet changes (and NEW_TOKEN)
>
> * EMPTY_ACK
>
> * The TLS extension for flow control
>
>
>
> Right now, some of these appear to be entirely gratuitous.  I'd like to
> get to the bottom of each before we continue.
>
>
>
> At a minimum, the PR we land first should include just the core changes.
>
> As you say, reviewing a monster PR like this will only make GitHub weep
> unicorns, but we might be able to cut this into smaller pieces.
>
>
>
> On Wed, May 23, 2018 at 11:31 AM Ian Swett <ianswett=
> [e-mail]> wrote:
>
>
>
> > Dear QUIC WG,
>
>
>
>
>
> > On behalf of the Stream 0 Design Team, I am pleased to report that we
>
> have consensus on a proposed approach to share with the WG. The DT's
> proposal will make QUIC and TLS work closer together and incorporates ideas
> from DTLS, but it does not use the DTLS protocol itself.
>
>
>
>
>
> > The DT believes this solves the important open Stream 0 issues. The
>
> proposal will be a bit more invasive in TLS, but we believe it is the
> right long-term direction and several TLS stacks (BoringSSL, PicoTLS, NSS,
> and
>
> Mint) are willing and able to do the work necessary.. A number of stacks
> are currently working on implementations of this new approach, which we
> hope to have in time for the Interim meeting.
>
>
>
>
>
> > A design document describing the overall approach can be found at:
>
>
>
>
>
> https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6au
> ojfJLkxddT93j6SwHY8/edit
>
>
>
>
>
> > A PR making the changes to the QUIC documents can be found at:
>
>
>
> > https://github.com/quicwg/base-drafts/pull/1377
>
>
>
>
>
> > A few design details did not have clear consensus, but it was felt it
>
> would be better to discuss those in the wider WG than delay the design
> team.  A consistent choice was made in the PR and these issues are
> mentioned in Appendix B of the design doc.
>
>
>
>
>
> > As always, comments and questions welcome. That said, this is a big PR
>
> and we recognize that some editorial work is going to be needed before
> merging. In the interest of letting people follow along, and to keep github
> from falling over, we ask people to keep discussion on the mailing list and
> refrain from making PR comments.
>
>
>
>
>
> > See you in Kista!
>
>
>
>
>
> > Ian and Eric
>
>
>