Re: Proposal: Run QUIC over DTLS
Christian Huitema <huitema@huitema.net> Tue, 06 March 2018 18:00 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 42563129C53 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 10:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 hEdIQJRKXDP7 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 10:00:27 -0800 (PST)
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 8E46212946D for <quic@ietf.org>; Tue, 6 Mar 2018 10:00:27 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1etGsy-00011X-Rv for quic@ietf.org; Tue, 06 Mar 2018 19:00:25 +0100
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1etGsu-0003ls-60 for quic@ietf.org; Tue, 06 Mar 2018 13:00:21 -0500
Received: (qmail 3685 invoked from network); 6 Mar 2018 18:00:18 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.195]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <kazuhooku@gmail.com>; 6 Mar 2018 18:00:18 -0000
To: Patrick McManus <pmcmanus@mozilla.com>, "Lubashev, Igor" <ilubashe@akamai.com>
Cc: "ekr@rtfm.com" <ekr@rtfm.com>, "subodh@fb.com" <subodh@fb.com>, "quic@ietf.org" <quic@ietf.org>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <CANatvzyevZrZciO3fTWFspp9utjKv9Z+PQ5F=yHKNBabssEsNw@mail.gmail.com> <MWHPR15MB182183BE8E6E0C3A97795315B6D90@MWHPR15MB1821.namprd15.prod.outlook.com> <CANatvzzARjNdr6Rms0r0yVn41JwtU6p9uNueq_ZROVzU19-1+A@mail.gmail.com> <b32d00a03ca148eca5a16e572d1030a0@usma1ex-dag1mb5.msg.corp.akamai.com> <CAOdDvNo-gjMioyOMHRw9bJpckTa5bKbE6zBFgvx9HTpr4mepRg@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <9f2d6810-5be7-24eb-e284-720483cf8a74@huitema.net>
Date: Tue, 06 Mar 2018 10:00:15 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAOdDvNo-gjMioyOMHRw9bJpckTa5bKbE6zBFgvx9HTpr4mepRg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1CE5E5182FF0CE0DEEF89CF0"
Content-Language: en-US
Subject: Re: Proposal: Run QUIC over DTLS
X-Originating-IP: 168.144.250.223
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.27)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sTstWzScG7LEbjZ+OHSsf1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViDTR5SR60zJIegz0y3BkqpM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB6nkU4uouGtaIPSwAALHVjh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYAgYwqmEqm4ZFj2/WNU6F gcDhGYu2lf0XwbmOrH5BsKAm63EouGktFvX6M8aKWc8Ctv9aQTw42VIrOVtuhg6nrGj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBENq HXIoSsvffuCdDqwWbJR1D/7Rwl5fb+U9Gl2IOh9znlIQFAvOyFgBflfxRgpty/bQ+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amRbl6gc+xGfFxqO6pPmlSScERpFEqF2lExBUp1VMiBudJzjv VlSk5R4XVB7M44lU2DF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qB0f8XFIghog8iZznnBoPsRp59k>
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: Tue, 06 Mar 2018 18:00:30 -0000
On 3/6/2018 6:56 AM, Patrick McManus wrote: > > I'm thinking about this question as "Is Stream 0 a Design Flaw?".. The > DTLS part is largely putting a solution to that problem out front and > isn't really the determining question to me. Its a flashy distraction. > > The nominal value of Stream 0 is more or less a replacement for TCP to > run a well known and trusted (and therefore to some degree opaque) TLS > over - a reliable in-order congestion controlled stream. It certainly was thought from the start as a compromise. But there is a big reason behind it: avoid creating a new key negotiation protocol from scratch; avoid running two TLS-like stacks in parallel, on for TCP, one for QUIC. There is beauty in having exactly the same code run in both cases. Think attack surface, ease of patching, etc. There is also beauty in *not* having a layered architecture, for the reasons that Kazuho and Mirja mentioned. It is great to see transport functions like acknowledgement or flow control fully contained in the Quic transport. Quic is about transport innovation, and that pretty much requires direct access to the network API. In practice, layered implementation hide that API, so the transport developers have to constantly negotiate with the intermediate layer developers. This direct access to the network interface is a big gain for Quic. > > It turns out not to do that very well. > > 1. Acknowledgements are heavily intertwined with handshake state - > both in sending and receiving. This results in duplicating acks > both in protected and unprotected contexts and implementations > dropping acknowledgments that they need after keying material has > been established. The interactions with loss are very bad. > Yes. That comes out regularly as a source of bugs in the interops. On the other hand, most implementations have fixed that by now, and the new applications have plenty of reference code to test with. > 1. The acknowledgment problem is also going to rear its head when we > make use of the key phase bit, which again. > 2. which brings me to the 'opaque' things that happen on stream 0 > when we just reuse the tls stack there. They aren't opaque. > 1. key phases - you better be aware of these > 2. session tickets - you better annotate these with source > validation information > 3. retry - you better not send these in stream 0 > 4. tls alert - you better change your state machine and generate > a quic level frame here too > 3. there are more.. > > There isn't much disagreement that this stream 0 behavior is ugly. > however as a WG I think we're subtly taking on the mindset that these > are established roadblocks we need to work around (i.e. a middlebox > mentality). We're designing a protocol we expect to have for a long > time and we agreed initially that what was in -00 was not to be given > undue weight simply because it in was in -00. > > so the question to me is - can we fix stream 0 in a way that is a > significant net positive to the protocol? I think the draft makes a > pretty decent case for that. The opaque things that you mention correspond to state changes in TLS. I am not sure that accessing those correspond to a "middlebox" mentality. In fact, as we were learning about these problems, I have been working with Kazuho to get the appropriate API exposed in Picotls. Such as API to export the 0-RTT secrets when ready, expose change of state after handshake message, or provide access to session tickets. The TLS Mapping draft presents some of that, but not quite all of it. For example, there is not much in that draft about the interaction between TLS-HRR and QUIC Handshake/Stateless Retry. I must say it is partly my fault -- I have worked a lot on the transport draft, not so much on the TLS mapping. But let's come back to the string of bytes model of stream 0. One downside of it is that it obscures the state transitions. For example, the sequence of stream zero bytes could well contain the server's second flight and some other message, such as a dummy change_cipher_spec record in compatibility mode. Since the transport only sees a stream of bytes, it has to submit a blob of bytes to TLS, and find out that a transition is happening in the middle of the blob. The other downside, as you note, is the interaction with acknowledgements. For example, the Server Hello is an implicit acknowledgement of the Client Hello. The Client's Finished is an implicit acknowledgement of the Server's second flight. But this is hidden from the transport machinery. So yes, maybe we should think of an alternative framing for TLS messages. But let's not throw out the baby with the bath water... -- Christian Huitema
- Proposal: Run QUIC over DTLS Eric Rescorla
- RE: Proposal: Run QUIC over DTLS Lucas Pardue
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Salz, Rich
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mark Nottingham
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Ian Swett
- Re: Proposal: Run QUIC over DTLS Kazuho Oku
- Re: Proposal: Run QUIC over DTLS Subodh Iyengar
- RE: Proposal: Run QUIC over DTLS Hannes Tschofenig
- RE: Proposal: Run QUIC over DTLS Mikkel Fahnøe Jørgensen
- Re: Proposal: Run QUIC over DTLS Kazuho Oku
- Re: Proposal: Run QUIC over DTLS Marten Seemann
- Re: Proposal: Run QUIC over DTLS Mirja Kühlewind
- RE: Proposal: Run QUIC over DTLS Lubashev, Igor
- RE: Proposal: Run QUIC over DTLS Lucas Pardue
- Re: Proposal: Run QUIC over DTLS Patrick McManus
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Eggert, Lars
- Re: Proposal: Run QUIC over DTLS Roberto Peon
- RE: Proposal: Run QUIC over DTLS Mike Bishop
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Victor Vasiliev
- Re: Proposal: Run QUIC over DTLS Subodh Iyengar
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Martin Duke
- Re: Proposal: Run QUIC over DTLS Benjamin Kaduk
- Re: Proposal: Run QUIC over DTLS Phillip Hallam-Baker
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- RE: Proposal: Run QUIC over DTLS Hannes Tschofenig
- Re: Proposal: Run QUIC over DTLS Christopher Wood
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- Re: Proposal: Run QUIC over DTLS Leif Hedstrom
- RE: Proposal: Run QUIC over DTLS Gabriel Montenegro
- Re: Proposal: Run QUIC over DTLS Christian Huitema
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mirja Kühlewind
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Eric Rescorla
- Re: Proposal: Run QUIC over DTLS Mikkel Fahnøe Jørgensen
- Re: Proposal: Run QUIC over DTLS Ted Hardie
- Re: Proposal: Run QUIC over DTLS Brian Trammell (IETF)
- Re: Proposal: Run QUIC over DTLS Philipp S. Tiesel
- Re: Proposal: Run QUIC over DTLS Mark Nottingham
- Re: Proposal: Run QUIC over DTLS Eric Rescorla