Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA163129C6C for ; Wed, 23 May 2018 16:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuxTHNywp3_M for ; Wed, 23 May 2018 16:27:15 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2DE1273B1 for ; Wed, 23 May 2018 16:27:14 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id d73-v6so93520iog.3 for ; Wed, 23 May 2018 16:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z1xzU1lE5M7B4q8royO+EZRokKVW/97l8AclQRZlbF0=; b=QwNuxvvhXRfHgioGk+iKGIGbG01gDi8Wm9k+LdBOjJNlWWGeA4R65FoAd/gGSTxTme 5s6FOhXiwr5ucCxBAAnY5P/nt/n34v36zAq5jyG/8S3f0krGFOzF7LUM6ZX+ikc+M3Iv K1HlqsavBiI7jlSnv3sszurkgx3PEoa559m5eA0CmLxNSHC4+fzoofw1SYi69YDMLeMH l8PQOCYAH7TX+OsJVIHgswO/KUX6SxWMI+v/kGjsVK+bky4Rj5yc7CtMAMwTL4DbuEVI emF9SEXmRXMh3QDbSkt8yO7STICzEzK1dEn7OVCCvSDX88eqeSnWrvmVusR3PpJ1GMoX /BVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z1xzU1lE5M7B4q8royO+EZRokKVW/97l8AclQRZlbF0=; b=PyDwoZd2q6QvCA/sXmgztuRsj2FZhkj5QOndwH8hSDkotgEv5ZcA8fwxKmA+r1sOtY /y7mBc6eXqrNhCdRf3JWixN11oIfxVOlXi5+W/a8C4AfUjf2siz8drweGOL3AuqyxYft HhesjpB/x1zSTe4IOvsZM62hWX/s7Zgoi2aZbXHycI1H15MD1gqJtV6vwLwTdzdQ3fbR 2F945JKa92K8xkfBIXMWbTwIIadY4nzG7Ext47hQ4/9drZywNYXU1JFxXL7/rX2HJDIS PvmQ6RmkMNiiROvNUCesKY2M1DqE+K07ZXWon9GxzqSLuKpoz/dPv0Rr/ZTamzNi+bA0 ZFfg== X-Gm-Message-State: ALKqPwcT64Y18qKbJwbpYdGWjhS2fyqKfTwJheIJNWMdlw0klkR9YjDq 6fkHBACtrPYoXL8QPnWJTEcNv+0jQUHLUYwhCY9xlg== X-Google-Smtp-Source: ADUXVKJZ1G7lvM3xa8ZJaa5sviF91sgCoJ88PBphhi4/D990y7AcPE1qlc9hG+IdB9OptQBTFOGCLXWkYV+kvJEd05Q= X-Received: by 2002:a6b:4119:: with SMTP id n25-v6mr4723806ioa.59.1527118033869; Wed, 23 May 2018 16:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:27d4:0:0:0:0:0 with HTTP; Wed, 23 May 2018 16:27:13 -0700 (PDT) From: Jana Iyengar Date: Wed, 23 May 2018 16:27:13 -0700 Message-ID: Subject: Re: Stream0 Proposal: EMPTY_ACK To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f066d9056ce7df35" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 23:27:19 -0000 --000000000000f066d9056ce7df35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Moving more discussions from main thread) ---------- Forwarded message ---------- From: Subodh Iyengar Date: Wed, May 23, 2018 at 3:37 PM Subject: Re: Stream0 Design Team Proposal To: Mike Bishop , Christian Huitema < huitema@huitema.net>, "quic@ietf.org" 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 on behalf of Mike Bishop < mbishop@evequefou.be> *Sent:* Wednesday, May 23, 2018 3:26:35 PM *To:* Christian Huitema; quic@ietf.org *Subject:* RE: Stream0 Design Team Proposal Christian, can you expand on why you dislike the EMPTY_ACK? Being able to say =E2=80=9CI=E2=80=99ve received some packets from you, but am unable to = process any of them because I=E2=80=99m missing some handshake data=E2=80=9D seems like a = useful way to short-circuit timeouts on clients. It also doesn=E2=80=99t commit the serv= er to holding any state =E2=80=93 IIUC, a server could form a packet containing a= n 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 wrote: > (Forking this discussion off from the main thread.) > > On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku wrote: > >> 2018-05-23 14:29 GMT+09:00 Christian Huitema : >> > 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" iss= ue >> > 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 thin= k >> 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 on behalf of Martin Thomson >> > >> > Sent: Tuesday, May 22, 2018 8:00:40 PM >> > To: Ian Swett >> > Cc: ekr@mozilla.com; 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 t= o >> > 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 enti= re >> > document set: >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__quicwg. >> github.io_base-2Ddrafts_stream0_&d=3DDwIBaQ&c=3D5VD0RTtNlTh3ycd4 >> 1b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7fQ&m=3D_vGK3zTKFrMOkFihJnPn >> tLYw1T0_NEMiHYSM0Q_u1JA&s=3DususmtxI3BTaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&= e=3D >> > >> > It seems like there are some core changes here and a bunch of separabl= e >> 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 t= o >> get >> > to the bottom of each before we continue. >> > >> > At a minimum, the PR we land first should include just the core change= s. >> > As you say, reviewing a monster PR like this will only make GitHub wee= p >> > unicorns, but we might be able to cut this into smaller pieces. >> > >> > On Wed, May 23, 2018 at 11:31 AM Ian Swett > > 40google.com@dmarc.ietf.org> 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, a= nd >> > Mint) are willing and able to do the work necessary.. A number of stac= ks >> > are currently working on implementations of this new approach, which w= e >> > 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=3Dhttps-3A__docs.go >> ogle.com_document_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j >> 6SwHY8_edit&d=3DDwIBaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHt >> wg-wAyN7fQ&m=3D_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s=3Dj >> DNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wVGg&e=3D >> > >> > >> >> 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 P= R >> > 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 lis= t >> and >> > refrain from making PR comments. >> > >> > >> >> See you in Kista! >> > >> > >> >> Ian and Eric >> > >> > >> >> >> >> -- >> Kazuho Oku >> >> > --000000000000f066d9056ce7df35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Moving more discussions from main thread)
=
---------- Forwarded message ----------
From:=C2=A0Subodh Iyengar=C2=A0<subodh@fb.com>
Date: Wed, May 23, 2018 at 3:37 PM
Subject: Re: Stream0 Design Tea= m Proposal
To: Mike Bishop <m= bishop@evequefou.be>, Christian Huitema <huitema@huitema.net>, "quic@ietf.org" <quic@i= etf.org>


FWIW I see EMPTY_ACKs as being very similar to a Dupli= cate 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=C2= =A0information.


Subodh

From:=C2=A0QUIC &= lt;quic-bounces@ietf.org> on behalf of Mike Bishop &l= t;mbishop@evequefou.be>
Sent:=C2=A0Wednesday, May 23, 2018 3:26:35 PM
To:=C2=A0Chri= stian Huitema;=C2=A0quic@ietf.org
Subject:=C2=A0RE: Stream0 Design Team Proposal
=C2=A0

Christian, can you expand on wh= y you dislike the EMPTY_ACK?=C2=A0 Being able to say =E2=80=9CI=E2=80=99ve = received some packets from you, but am unable to process any of them becaus= e I=E2=80=99m missing some handshake data=E2=80=9D seems like a useful way = to short-circuit timeouts on clients.=C2=A0 It also doesn=E2=80=99t commit = the server to holding any state =E2=80=93 IIUC, a server could form a packe= t containing an EMPTY_ACK and then discard its internal state until it gets= the retransmitted (or delayed) Initial packet.

=C2=A0=




On Wed, May 23, 2018 = at 4:25 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:
(Forking this discussion off f= rom the main thread.)

On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <<= a href=3D"mailto:kazuhooku@gmail.com" target=3D"_blank">kazuhooku@gmail.com= > wrote:
2018-05-23 1= 4:29 GMT+09:00 Christian Huitema <huitema@huitema.net>:
> 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 cu= rrent
> draft, it is very hard to contain that problem if you enable client au= th.
>
>
> On the other hand, I agree with Martin that a lot of the additions to<= br> > transmission recovery should be moved to separate PRs. I am not enthus= iastic
> with the EMPTY ACK mechanism, or with the proposed "implicit
> acknowledgement" of a lower crypto stream by a higher level ack.<= br>
At the moment I do not have a strong opinion on the Empty ACK mechan= ism.

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 imp= lement
> this as well.
>
>
> While this is a change in the API that TLS classically exposes, I thin= k this
> is the right tradeoff because it helps make things way more explicit w= hich
> will prevent several other bugs from happening in the future.
>
>
> Subodh
>
> ________________________________
> From: QUIC <quic-bounces@ietf.org> on behalf of Martin Thomson
> <mart= in.thomson@gmail.com>
> Sent: Tuesday, May 22, 2018 8:00:40 PM
> To: Ian Swett
> Cc: ekr@mozilla.c= om; QUIC WG
> Subject: Re: Stream0 Design Team Proposal
>
> First of all, thanks to the design team for the work they have done.= =C2=A0 I
> haven't digested everything yet, but I think that I have a good se= nse of
> the shape of the proposal.
>
> Overall, this looks like a workable design.=C2=A0 It's a lot more = invasive of
> the cryptographic handshake implementation than I had thought people w= ere
> willing to stomach originally.=C2=A0 But it's clear that we've= run into problems
> with the current, more abstract API and this is a fairly natural way t= o
> split TLS.=C2=A0 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.= =C2=A0 The proof
> will be in the pudding there though.
>
> In looking at the PR, I really appreciate seeing all the c= hanges 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).=C2=A0 The actua= l 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.c= om/v2/url?u=3Dhttps-3A__quicwg.github.io_base-2Ddrafts_stream0_&a= mp;d=3DDwIBaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7fQ&m=3D_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA&s= =3DususmtxI3BTaLlBWe_HkQUWRH4sBI0Cggj1oWZMBHak&e=3D
>
> It seems like there are some core changes here and a bunch of separabl= e or
> at least secondary changes.=C2=A0 I'm sure that each one has its o= wn
> 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.=C2=A0 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 change= s.
> As you say, reviewing a monster PR like this will only make GitHub wee= p
> unicorns, but we might be able to cut this into smaller pieces.
>
> On Wed, May 23, 2018 at 11:31 AM Ian Swett <ianswett=3D
> 40goo= gle.com@dmarc.ietf.org> 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. Th= e
> 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, a= nd
> Mint) are willing and able to do the work necessary.. A number of stac= ks
> are currently working on implementations of this new approach, which w= e
> 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=3Dhttps-3A__docs.go= ogle.com_document_d_1fRsJqPinJl8N3b-2DbflDRV6auojfJLkxddT93j6SwHY= 8_edit&d=3DDwIBaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7= mHtwg-wAyN7fQ&m=3D_vGK3zTKFrMOkFihJnPntLYw1T0_NEMiHYSM0Q_u1JA= &s=3DjDNnz34hmWvLSQnHkSnYdihW-jG-0xZ-YYqKq30wVGg&e=3D=
>
>
>> A PR making the changes to the QUIC documents can be found at:
>
>> https://github.com/quicwg/base-drafts/p= ull/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.=C2=A0 A consistent choice was made in the PR and these issues ar= e
> mentioned in Appendix B of the design doc.
>
>
>> As always, comments and questions welcome. That said, this is a bi= g 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 g= ithub
> from falling over, we ask people to keep discussion on the mailing lis= t and
> refrain from making PR comments.
>
>
>> See you in Kista!
>
>
>> Ian and Eric
>
>



--
Kazuho Oku



--000000000000f066d9056ce7df35--