Subject: Re: Stream0 Proposal: EMPTY_ACK

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 16:27:13 -0700

(Moving more discussions from main thread)

---------- Forwarded message ----------
From: Subodh Iyengar <[email-masked]>
Date: Wed, May 23, 2018 at 3:37 PM
Subject: Re: Stream0 Design Team Proposal
To: Mike Bishop <[email-masked]>, Christian Huitema <
[email-masked]>, "[email-masked]" <[email-masked]>

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 <[email-masked]> on behalf of Mike Bishop <
[email-masked]>
*Sent:* Wednesday, May 23, 2018 3:26:35 PM
*To:* Christian Huitema; [email-masked]
*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 <[email-masked]> wrote:

> (Forking this discussion off from the main thread.)
>
> On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <[email-masked]> wrote:
>
>> 2018-05-23 14:29 GMT+09:00 Christian Huitema <[email-masked]>:
>> > 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 <[email-masked]> on behalf of Martin Thomson
>> > <[email-masked]>
>> > Sent: Tuesday, May 22, 2018 8:00:40 PM
>> > To: Ian Swett
>> > Cc: [email-masked]; 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=_vGK3zTKFrMOkFihJnPn
>> tLYw1T0_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=
>> > [email-masked]> 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=
>> >
>> >
>> >> 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
>>
>>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 May 2018 19:10:12 -0700

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:
> From: *Subodh Iyengar* <[email-masked] <mailto:[email-masked]>>
> To: Mike Bishop <[email-masked] <mailto:[email-masked]>>,
> Christian Huitema <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>
>
> 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 <[email-masked] <mailto:[email-masked]>> on
> behalf of Mike Bishop <[email-masked] <mailto:[email-masked]>>
> *To:* Christian Huitema; [email-masked] <mailto:[email-masked]>
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         2018-05-23 14:29 GMT+09:00 Christian Huitema
>         <[email-masked] <mailto:[email-masked]>>:
>         > 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.
>         >
>         >
>         > transmission recovery should be moved to separate PRs. I am
>         not enthusiastic
>         > 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
>         > From: QUIC <[email-masked]
>         <mailto:[email-masked]>> on behalf of Martin Thomson
>         > <[email-masked] <mailto:[email-masked]>>
>         > Cc: [email-masked] <mailto:[email-masked]>; QUIC WG
>         > the cryptographic handshake implementation than I had
>         thought people were
>         > willing to stomach originally.  But it's clear that we've
>         run into problems
>         > implemented and I think that it's not going to be *too*
>         painful.  The proof
>         > In looking at the PR, I really appreciate seeing all the
>         changes together..
>         > have the same content, but that's not guaranteed).  The
>         actual PR is here:
>         <https://github.com/quicwg/base-drafts/pull/1377>
>         >
>         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
>         > justification, but that isn't always clear. The following
>         changes seem like
>         > they are separable:
>         >
>         > Right now, some of these appear to be entirely gratuitous. 
>         I'd like to get
>         > [email-masked]
>         <mailto:[email-masked]>> wrote:
>         >
>         >> Dear QUIC WG,
>         >
>         >
>         > proposal will make QUIC and TLS work closer together and
>         incorporates ideas
>         > proposal will be a bit more invasive in TLS, but we believe
>         it is the right
>         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=>
>         >
>         >
>         <https://github.com/quicwg/base-drafts/pull/1377>
>         >
>         >
>         > 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 19:45:37 -0700

On Wed, May 23, 2018 at 7:10 PM, Christian Huitema <[email-masked]>
wrote:

> 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

>>> > While this is a change in the API that TLS classically exposes, I
>>> think this
>>> 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
>>> > Right now, some of these appear to be entirely gratuitous.  I'd like
>>> to get
>>> > from falling over, we ask people to keep discussion on the mailing
>>> list and

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 May 2018 20:54:45 -0700

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

-- Christian Huitema 

> On May 23, 2018, at 7:45 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Wed, May 23, 2018 at 7:10 PM, Christian Huitema <[email-masked]> 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.
>> 
>>> To: Mike Bishop <[email-masked]>, Christian Huitema <[email-masked]>, "[email-masked]" <[email-masked]>
>>> 
>>> 
>>> 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 <[email-masked]> on behalf of Mike Bishop <[email-masked]>
>>> Sent: Wednesday, May 23, 2018 3:26:35 PM
>>> To: Christian Huitema; [email-masked]
>>> 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.
>>> 
>>>  
>>> 
>>> 
>>> 
>>> 
>>>>> > 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.
>>>>> >
>>>>> >
>>>>> > transmission recovery should be moved to separate PRs. I am not enthusiastic
>>>>> > 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
>>>>> > the cryptographic handshake implementation than I had thought people were
>>>>> > willing to stomach originally.  But it's clear that we've run into problems
>>>>> > implemented and I think that it's not going to be *too* painful.  The proof
>>>>> > In looking at the PR, I really appreciate seeing all the changes together..
>>>>> > have the same content, but that's not guaranteed).  The actual PR is here:
>>>>> > It seems like there are some core changes here and a bunch of separable or
>>>>> > justification, but that isn't always clear. The following changes seem like
>>>>> > they are separable:
>>>>> >
>>>>> > Right now, some of these appear to be entirely gratuitous.  I'd like to get
>>>>> > proposal will make QUIC and TLS work closer together and incorporates ideas
>>>>> > proposal will be a bit more invasive in TLS, but we believe it is the right
>>>>> > 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 20:59:34 -0700

> 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

>> 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
>> 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