Stream0 Proposal: EMPTY_ACK

[Jana Iyengar <[e-mail]>]

(Forking this discussion off from the main thread.)

On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <[e-mail]> wrote:

> 2018-05-23 14:29 GMT+09:00 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.
>
> At the moment I do not have a strong opinion on the Empty ACK mechanism.
>
> However, regarding how we close the Initial and Handshake contexts, my
> preference goes to using implicit ACKs (i.e. use the successful
> receipt of a packet that is protected under a higher level of
> encryption key as the signal) rather than explicitly ACKing the last
> flight of data.
>
> As I see, there are two downsides in the Explicit ACKing approach.
>
> * Explicit ACKing requires sending two additional packets during the
> handshake, which means that we would have more AES operations plus
> somewhere around 60 bytes of overhead on the wire.
> * Explicit ACKing requires more signaling from the TLS stack. In case
> of implicit ACKing, the TLS stack need to only provide the AEAD
> contexts and the messages, whereas in case of explicit ACKing, the TLS
> stack also needs to provide a signal indicating the end of the
> transmission at each encryption level.
>
> The downside of the implicit ACKing approach is that the server needs
> to signal the termination of the Handshake context using a special
> frame sent using a 1-RTT packet.
>
> But even taking that into consideration, I think that implicit ACKing
> is still easier to implement, considering the need for the additional
> signal in the explicit ACK case that have been described above.
>
>
> > 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
> >
> >
>
>
>
> --
> Kazuho Oku
>
>