Re: Proposal: Run QUIC over DTLS

Martin Duke <martin.h.duke@gmail.com> Tue, 06 March 2018 23:45 UTC

Return-Path: <martin.h.duke@gmail.com>
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 8ECB512E036 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 15:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 dRd4aO6jysep for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 15:45:06 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 504E012DA08 for <quic@ietf.org>; Tue, 6 Mar 2018 15:45:02 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id z81so1411781wmb.4 for <quic@ietf.org>; Tue, 06 Mar 2018 15:45:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GzlgY+Y+ot34aEWVSITNN/1aHc9ovSHcca6R1k+Pfcg=; b=Tf0vN1cqpGbrx5pavx77jQcIbfc/EeWaT4e8OcCB9TsqiwIVp7u/2Hs2twLk6oaZfY +FNxZXVevQ1+g4RxatumkDo3WkUZRC1w2KwzNPK25D0nRTS7AqD6+6cn1cgB2j/nddNi DEqlM8XLLTyj1LiO/xfGqPiinPv3aBFG3+UZ6UZpuaz/7HjUJCKLEfOTgYfbdDgNMZU4 wS5f4//jSDTcWlaBo5inxUBmkZn/IU4bJn7VEe4qyPhdNmmtgamh4td8c0KbPdCsgXNR yX7CqhjWroh63dz3nWaLNRmFilpaPrHFuJIgFIqcoeE3nyBzLpybxCrsyYXl+fD6qRZP BLCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GzlgY+Y+ot34aEWVSITNN/1aHc9ovSHcca6R1k+Pfcg=; b=ELWj6IVfZ+B/Rq+tReVf2yYPiYWywczycphdrvqNLJGHDKwN9v9H8OcSUShi8tYwXl iS9BFLpvjf8SHbs0rNuwVEygZGV56MgLmXREzt8f7TafWx/OhYMWROZ6Wxm0yIOpHx4z QZG9Rm2CUdAJA/W14+y0gGaxbEioxBxTJdgyA4DaboufIAk+o0juYULCAKVsupzpEpXL p6jVUEW0Uerl3Tbd1Em2shGqksJU5qEzmgHZq1oXl6gxhlGaoVGJ3bvXTpY5PgA4fs1M fxJMabti6D9zLR0N9RLx36T07ihx9OLxHNENpWl7qu5Irv91dlG5W6ogk6HFlE63d0zy kjxw==
X-Gm-Message-State: AElRT7GaT+iPzR30dW4RygRuEr8YubeojL96SlB4S6wEe198Y6JQAQFt c7PAPhpCE0261xvtEQCYyD0OL5XBzMZV3Wg+5mo=
X-Google-Smtp-Source: AG47ELsRKvwuu14R1/+ahASLr4dmVIwDqWPALVwuVCJR3wdhacSgYP9PPuFofDD9zpPoVksznc7XdJ5qdGaJu3xq5mU=
X-Received: by 10.28.150.138 with SMTP id y132mr13309048wmd.104.1520379900712; Tue, 06 Mar 2018 15:45:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.166.71 with HTTP; Tue, 6 Mar 2018 15:44:59 -0800 (PST)
In-Reply-To: <CA+9kkMBKE46GNHevhcnvBwJ1cbOb369-NKvtzQ7wDcnEZezg+Q@mail.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> <CABcZeBMyKY8d3OUwF11NqYvgNswD7F1S8R7rXrKYXTaNPTkOxw@mail.gmail.com> <CA+9kkMBKE46GNHevhcnvBwJ1cbOb369-NKvtzQ7wDcnEZezg+Q@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 6 Mar 2018 15:44:59 -0800
Message-ID: <CAM4esxSkAhU2m6KiVAxibAYmCKFhBsyBCOMzJFfud6rQDMvHrA@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114b3b0ce7db490566c707f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9G--oDVgCvumUxtxb3-uFbxOTJw>
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 23:45:10 -0000

I like the QUIC-over-DTLS architecture, and if it had come out a year ago,
I might have been a supporter. However, I think the idea that we could
possibly stay on schedule with this change is a fantasy.

1. For all its problems, the QUIC handshake is one thing that pretty much
all the implementations have working. We've overcome the design inelegance,
and would now have to redo the handshake without really reducing
implementation time going forward, with the possible exception of not
needing to handle key phase.

2. DTLS 1.3 is apparently less mature, as a standard, than TLS1.3, and even
less so if we're about to go add a bunch of requirements.

3. In our case, the DTLS 1.3 implementation is much earlier in its roadmap
than TLS1.3, which is being driven by TCP use cases. I can't even guess
when I would have a conforming DTLS implementation, and I suspect I'm not
the only one. It's great that picotls is willing to move fast, but many of
us have other constraints.

4. Personally, I take a somewhat dim view of the mucking around we've done
with the public header since GQUIC in the name of privacy. However, the
group as a whole clearly wants to have that discussion, and
administratively it will be hard for the same participants to have these
arguments in TLSWG instead.

I'm not married to any particular schedule for QUIC, so if the benefits are
worth the schedule delay that's OK with me. But we should acknowledge the
schedule delay will be significant.

On Tue, Mar 6, 2018 at 3:25 PM, Ted Hardie <ted.ietf@gmail.com>; wrote:

> Howdy,
>
> I've now had a chance to read the document, and I think you have
> identified a legitimate pain point with the treatment of stream 0.  At the
> very, least renaming it so that the differences between its behavior and
> other streams are less surprising seems warranted.  Like Christian, I would
> also be interested in seeing the PR you sketch out below.
>
> I think, however, that the proposal to re-layer on top of DTLS should be
> dropped.  I am even, frankly, reluctant to see a presentation of it at IETF
> 101, since I suspect the 20 minutes will eat a good bit more mental time
> than that.
>
> I have two basic reasons for that, similar to those put forward by
> others.  The first is that this will require additional time and
> coordination.  DTLS has some modest changes to do, and there are some
> not-at-all modest changes to both specification and code required on the
> QUIC side.  Though your proposal is complete enough to give a good idea of
> what to expect, there is enough to nail down (like carrying the transport
> parameters) that it will take multiple cycles of discussion and testing to
> go from here back to where we are in terms of implementations
> interoperating.  While your proposal may well reduce implementation
> complexity, I didn't see any user-impacting feature that was gained (and if
> I missed it, my apologies).  "Done" is a user-impacting feature.  Without a
> balancing user-impacting feature, the delay for relayering doesn't seem to
> be at the right place in the hierarchy of concerns.
>
> The second reason relates to WebRTC.  As you note, there is interest on
> the WebRTC side in adopting QUIC and relayering would make the current
> version of the data channel (SCTP over DTLS) easy to run side-by-side with
> a later QUIC over DTLS.  While I agree, I think the appetite for change in
> WebRTC is a bit larger and that it includes potentially running the media
> over a version of QUIC that supports partial reliability and multipath.  I
> believe, as a result, that having a full-on effort that tackles WebRTC over
> QUIC may result in some trade-off choices that we will not make correctly
> if we tackle only the data channel parallel now.  If we try to do it all
> together (Transport, HTTP and WebRTC), I suspect the delay will simply push
> this into a downward spiral of attention and effort.
>
> My last reason is not so basic, because it is a concern about
> ossification.  You noted in your message to the list:
>
>     We are designing a protocol that will be used long into the future, so
>     having the right architecture is especially important.
>
> While we hope that the protocol will be useful long into the future, we
> are also trying to demonstrate that building a new transport on top of UDP
> can be done and deployed widely.  That should open up the possibility of
> deploying more as time goes on.  If we get caught up trying to make this
> version perfect because we believe it is our last chance, we may find
> ourselves with the deployment timeline of v6 instead of gQUIC.
>
> I do appreciate your making the effort to consider this in a different
> layering and your presenting the results to the working group.  I think the
> effort will improve the handshake and the treatment of stream 0, but I
> personally believe it should do so within the framework we have already
> laid out.
>
> thanks,
>
> Ted
>
> On Tue, Mar 6, 2018 at 7:12 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
>
>> FWIW it is possible to move the style of version negotiation from my
>> draft directly into the current draft if we so wanted. It's just that it's
>> necessary if QUIC is at the bottom of the stack and so is a nice extra win.
>>
>> Specifically, we would have the version in the long header In Initial
>> refer not to the QUIC version we want to negotiate but rather to the
>> version whose obfuscation method we are using (probably the client's
>> minimum). The CH would then have an extension which contained the QUIC
>> versions we support (as in TLS.supported_versions) and then the SH would
>> contain both selected versions. We could have the remaining obfuscated long
>> header packets could use *either* obfuscation version. The encrypted long
>> header packets would of course use the negotiated versions.
>>
>> A few notes:
>>
>> - The CH always comes in one packet so that you don't have to worry about
>> it being immediately available to the server
>> - The SH may be broken up but as noted above, the obfuscation version
>> isn't part of the negotiation.
>>
>> As with my draft, this would give you 1-RTT negotiation if the client
>> obfuscated with a version the server knew and 2-RTT if the client
>> obfuscated with a version the server didn't know, as opposed to always
>> having 2-RTT
>>
>> If people think they like this idea, I'd be happy to write it up a
>> separate PR.
>>
>> -Ekr
>>
>>
>>
>>
>