Re: Stream0 Design Team Proposal

[Kazuho Oku <[e-mail]>]

2018-05-24 7:14 GMT+09:00 Mike Bishop <[e-mail]>:
> While a HS_DONE frame sent under 1-RTT would simplify some things, I'm not sure that it's required.  There's a very clear synchronization point which already exists.
>
> The client can't send 1-RTT messages until it has sent Client Finished.  The server can send, but not process, 1-RTT messages prior to receiving Client Finished.  (This is a spec requirement rather than a crypto limitation, however, so a buggy server might violate it.)  Thus, an ACK for any 1-RTT packet from the client implicitly acknowledges the client's entire handshake.  Receipt of any 1-RTT packet from the client implicitly acknowledges the server's entire handshake.

That is true.

However, I think that the issue remains in case where 0-RTT is
involved. If the client sends it's request using a 0-RTT packet and
the server ACKs and sends a response in 0.5-RTT, there will be no
1-RTT packets from server after ClientFinished is delivered to the
server.

> -----Original Message-----
> From: QUIC <[e-mail]> On Behalf Of Kazuho Oku
> Sent: Wednesday, May 23, 2018 2:14 AM
> To: Christian Huitema <[e-mail]>
> Cc: IETF QUIC WG <[e-mail]>
> Subject: Re: Stream0 Design Team Proposal
>
> 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=h3Ju9EBS7mH
>> twg-wAyN7fQ&m=_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=ususmtxI3B
>> TaLlBWe_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_d
>> ocument_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j6SwHY8_edit&d=DwIBaQ
>> &c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=_vGK3zTKFrMOkFihJ
>> nPntLYw1T0_NEMiHYSM0Q_u1JA&s=jDNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wV
>> Gg&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
>



-- 
Kazuho Oku