Re: Stream0 Proposal: EMPTY_ACK

[Eric Rescorla <[e-mail]>]

On Wed, May 23, 2018 at 8:54 PM, Christian Huitema <[e-mail]>
wrote:

> What vulnerability? At a minimum, reflection Dos.
> Send UDP packet with "0rtt" content. Trigger emty-ack.
>

Given that you can already trigger transmission of the full cert chain with
CH, this doesn't seem very interesting.

-Ekr


> -- Christian Huitema
>
> On May 23, 2018, at 7:45 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Wed, May 23, 2018 at 7:10 PM, Christian Huitema <[e-mail]>
> wrote:
>
>> 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.
>>
> What's the vulnerability? Anything more than a spurious retransmit?
>
> -Ekr
>
>
>> On 5/23/2018 4:27 PM, Jana Iyengar wrote:
>>
>> (Moving more discussions from main thread)
>>
>> ---------- Forwarded message ----------
>> From: Subodh Iyengar <[e-mail]>
>> Date: Wed, May 23, 2018 at 3:37 PM
>> Subject: Re: Stream0 Design Team Proposal
>> To: Mike Bishop <[e-mail]>, Christian Huitema <
>> [e-mail]>, "[e-mail]" <[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]> on behalf of Mike Bishop <
>> [e-mail]>
>> *Sent:* Wednesday, May 23, 2018 3:26:35 PM
>> *To:* Christian Huitema; [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]> wrote:
>>
>>> (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=5VD0RTtNlTh3ycd4
>>>> 1b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T
>>>> 0_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.go
>>>> ogle.com_document_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j
>>>> 6SwHY8_edit&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHt
>>>> wg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=j
>>>> DNnz34hmWvLSQnHkSnYdihW-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
>>>> >
>>>> >
>>>> >> 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
>>>>
>>>>
>>>
>>
>>
>