Re: Stream0 Proposal: EMPTY_ACK

Christian Huitema <huitema@huitema.net> Thu, 24 May 2018 03:55 UTC

Return-Path: <huitema@huitema.net>
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 5AA89120721 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 20:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AnB9ZFN31-QU for <quic@ietfa.amsl.com>; Wed, 23 May 2018 20:55:02 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7F11200C1 for <quic@ietf.org>; Wed, 23 May 2018 20:55:01 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fLhL8-0003I4-4C for quic@ietf.org; Thu, 24 May 2018 05:55:00 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fLhKy-0000UL-T6 for quic@ietf.org; Wed, 23 May 2018 23:54:55 -0400
Received: (qmail 8906 invoked from network); 24 May 2018 03:54:47 -0000
Received: from unknown (HELO [IPv6:2607:fb90:b283:e8b0:fcd4:75c0:abeb:ab5b]) (Authenticated-user:_huitema@huitema.net@[172.58.45.19]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 24 May 2018 03:54:47 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-2FAE5C97-5E51-4915-ACEA-732E3CDD4E6C
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <CABcZeBPtjbMVL2RQMyLZJg_QyHcgA5E_g8SAgoHUqjpLrJRA4g@mail.gmail.com>
Date: Wed, 23 May 2018 20:54:45 -0700
Cc: Jana Iyengar <jri.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <C48DFD01-BB1F-418D-A2A6-E2BD80407465@huitema.net>
References: <CACpbDcckRvyn18qowWbLRT+sX2EGj3_yPtoS2d-h6ypg4dFrVQ@mail.gmail.com> <6d80b771-ba07-cab7-fa86-d4e31d56b919@huitema.net> <CABcZeBPtjbMVL2RQMyLZJg_QyHcgA5E_g8SAgoHUqjpLrJRA4g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Subject: Re: Stream0 Proposal: EMPTY_ACK
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5k06TzfMM85Y7mlql7PakSN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViH/FbFIcIrL/KevcFV68rXs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1XpqFDyTB1Bz0n/bLAAUYB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWbjljpzcldG5bc9h0NLkX5F8FcHzzV3acxBudgYcInb4dOoCMnLjP/ 8RAg0e+WyFCZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZN1zg8T9ahw4hquQDupK1jlwBl1z1+w2zS/h3e6UiVRdDYX3tuq4/d4fO KwjajcIDGlUh000z6J0XX7zaLZaVX2eqA47D/juB1cx4exzYk7wfjirBnMSvLt+oZCsKZvqt647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Vr-dCiNA7LM5hbTbaZuXsyccOzs>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 03:55:06 -0000

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 <ekr@rtfm.com> wrote:
> 
> 
> 
>> On Wed, May 23, 2018 at 7:10 PM, Christian Huitema <huitema@huitema.net> 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 <subodh@fb.com>
>>> Date: Wed, May 23, 2018 at 3:37 PM
>>> Subject: Re: Stream0 Design Team Proposal
>>> To: Mike Bishop <mbishop@evequefou.be>, Christian Huitema <huitema@huitema.net>, "quic@ietf.org" <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 <quic-bounces@ietf.org> 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 “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 <jri.ietf@gmail.com> wrote:
>>>> (Forking this discussion off from the main thread.)
>>>> 
>>>>> On Wed, May 23, 2018 at 2:13 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>>> 2018-05-23 14: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 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 <quic-bounces@ietf.org> on behalf of Martin Thomson
>>>>> > <martin.thomson@gmail.com>
>>>>> > 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 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=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=
>>>>> > 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, 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=
>>>>> >
>>>>> >
>>>>> >> 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
>>>>> 
>>>> 
>>> 
>> 
>