Re: Proposal: Run QUIC over DTLS

Ted Hardie <ted.ietf@gmail.com> Tue, 06 March 2018 23:26 UTC

Return-Path: <ted.ietf@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 5DF80126CB6 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 15:26:28 -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 UYNWe06YRxMZ for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 15:26:26 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 1354F1200FC for <quic@ietf.org>; Tue, 6 Mar 2018 15:26:26 -0800 (PST)
Received: by mail-oi0-x22a.google.com with SMTP id c83so312632oib.1 for <quic@ietf.org>; Tue, 06 Mar 2018 15:26:26 -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=ftIWpH6cuNd5MawOCtYF3BHhW+7+WHiBtN56C8hGNzs=; b=U4bKB2sWHxRaC9LYfu1c1Ikz+hXwrk6EcpZ3P8X2oP8u5352DI2NOarDHosSJ/Vvxe Mej2hAQ9TBlKuHSduvUHxuQo8RVNCO2VrYvcwxusHwgFgfhSbE5uT0ZUjoq8Ij3hLcVr K/bhAD9X/UFSdIvMcKpmUygQh8JaQ5+RO78l47wesANi5zDUqOaTuHNdYHTfjd3N5aKz ABaq8Q6PhhdoN9quO6ChuLvcyBt9/wUyA/T7ETZH6eNMGC6zniNA6otEeMwehXP+ESCb GCdorFB2ONEd9LbGkNf4t7uA7TlX3P5077KNhFu04j9wBucufI4QVlPnuUmyryzN8vVx INng==
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=ftIWpH6cuNd5MawOCtYF3BHhW+7+WHiBtN56C8hGNzs=; b=AcK+PsiSqsTZe0B5goFz+aSslufzQSTUlBb9Xv7SY3/OBhQap4GegmVV9K1gJxIBtb wRzu9uNloqAfjjsbVFw9Is8tU85jlQLhFEE1l0nGZ98F3SkitGU+xW60znWDTy9OWEct c/K2OORxHzFhG047VAe89h6xj/6IXDZGao+LZyXGsvMRxmD1tjLu7qHQW/r6VTFTudWE xzPrW/PNXuimnaZ91YyFD0j2Vbp/Zx7tAMBa/ABbNNgPYU6LV+ilILFcDUy61C+ntxyS BYlD9Z5BX2iNxH4c60yfJ++HnuAtlSbMxRkiH/nj4pTn7MB9vS7uBBtqXTjVA9l3ejx0 /f6A==
X-Gm-Message-State: APf1xPBqPN+A8XKe4lq8wOnY2dXVOSRcfc0vhBmVKYMutcQwOJrsjYyb fnnCC8PX+bkAkQJ0TzmJfhLynEFbVrRfXL6Yrrh1Og==
X-Google-Smtp-Source: AG47ELtnkdHZQA9zb3QVfZzBNT+AKS/JDcgmrBRxnc0w4xMGSecrP474v12OBaqA93h1PZ3c0vgYF/AGR6N1Rs3/fgg=
X-Received: by 10.202.15.21 with SMTP id 21mr13396873oip.216.1520378785134; Tue, 06 Mar 2018 15:26:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.7.27 with HTTP; Tue, 6 Mar 2018 15:25:54 -0800 (PST)
In-Reply-To: <CABcZeBMyKY8d3OUwF11NqYvgNswD7F1S8R7rXrKYXTaNPTkOxw@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>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 06 Mar 2018 15:25:54 -0800
Message-ID: <CA+9kkMBKE46GNHevhcnvBwJ1cbOb369-NKvtzQ7wDcnEZezg+Q@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <ekr@rtfm.com>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f4f5e808d70c697de70566c6c5e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ndz7D3Bwe01JU3T3twB31rkwlDM>
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:26:28 -0000

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