Re: Stream0 Proposal: EMPTY_ACK

[Christian Huitema <[e-mail]>]

I dislike the EMPTY_ACK because they are "responses to something that
could not be decrypted". You don't know where the packet came from, it
could be spoofed. So you have on one hand a possible optimization, on
the other hand a possible vulnerability, and in all cases additional
complexity.


On 5/23/2018 4:27 PM, Jana Iyengar wrote:
> (Moving more discussions from main thread)
>
> ---------- Forwarded message ----------
> From: *Subodh Iyengar* <[e-mail] <mailto:[e-mail]>>
> Date: Wed, May 23, 2018 at 3:37 PM
> Subject: Re: Stream0 Design Team Proposal
> To: Mike Bishop <[e-mail] <mailto:[e-mail]>>,
> Christian Huitema <[e-mail] <mailto:[e-mail]>>,
> "[e-mail] <mailto:[e-mail]>" <[e-mail]
> <mailto:[e-mail]>>
>
>
> FWIW I see EMPTY_ACKs as being very similar to a Duplicate ack. We
> thought about using Duplicate acks as well but we thought that
> EMPTY_ACks would be simpler to implement and be able to convey
> similar information.
>
>
> Subodh
>
> ------------------------------------------------------------------------
> *From:* QUIC <[e-mail] <mailto:[e-mail]>> on
> behalf of Mike Bishop <[e-mail] <mailto:[e-mail]>>
> *Sent:* Wednesday, May 23, 2018 3:26:35 PM
> *To:* Christian Huitema; [e-mail] <mailto:[e-mail]>
> *Subject:* RE: Stream0 Design Team Proposal
>  
>
> Christian, can you expand on why you dislike the EMPTY_ACK?  Being
> able to say “I’ve received some packets from you, but am unable to
> process any of them because I’m missing some handshake data” seems
> like a useful way to short-circuit timeouts on clients.  It also
> doesn’t commit the server to holding any state – IIUC, a server could
> form a packet containing an EMPTY_ACK and then discard its internal
> state until it gets the retransmitted (or delayed) Initial packet.
>
>  
>
>
>
>
> On Wed, May 23, 2018 at 4:25 PM, Jana Iyengar <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     (Forking this discussion off from the main thread.)
>
>     On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         2018-05-23 14:29 GMT+09:00 Christian Huitema
>         <[e-mail] <mailto:[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]
>         <mailto:[e-mail]>> on behalf of Martin Thomson
>         > <[e-mail] <mailto:[e-mail]>>
>         > Sent: Tuesday, May 22, 2018 8:00:40 PM
>         > To: Ian Swett
>         > Cc: [e-mail] <mailto:[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
>         <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=
>         <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]
>         <mailto:[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=
>         <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
>         <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
>
>
>