Re: Stream0 Design Team Proposal

[Christian Huitema <[e-mail]>]

I like the proposal. In particular, I really like the encryption of
handshake packets with the handshake key, as it does close a number of
avenues for attacks. And I like that it solves the "ack promotion" issue
that I was complaining against for some time. Turns out that in the
current draft, it is very hard to contain that problem if you enable
client auth.


On the other hand, I agree with Martin that a lot of the additions to
transmission recovery should be moved to separate PRs. I am not
enthusiastic with the EMPTY ACK mechanism, or with the proposed
"implicit acknowledgement" of a lower crypto stream by a higher level
ack. In any case, starting as simple as possible would help having the
first implementations and tests.


On 5/22/2018 8:26 PM, Subodh Iyengar wrote:
>
> As an implementor of fizz, I support this design and am willing to
> implement this as well.
>
>
> While this is a change in the API that TLS classically exposes, I
> think this is the right tradeoff because it helps make things way more
> explicit which will prevent several other bugs from happening in the
> future.
>
>
> Subodh
>
> ------------------------------------------------------------------------
> *From:* QUIC <[e-mail]> on behalf of Martin Thomson
> <[e-mail]>
> *Sent:* Tuesday, May 22, 2018 8:00:40 PM
> *To:* Ian Swett
> *Cc:* [e-mail]; QUIC WG
> *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://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_base-2Ddrafts_stream0_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=ususmtxI3BTaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&e=
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j6SwHY8_edit&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=jDNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wVGg&e=
>
>
> > 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
>