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