Re: Proposal: Run QUIC over DTLS

Benjamin Kaduk <bkaduk@akamai.com> Wed, 07 March 2018 04:14 UTC

Return-Path: <bkaduk@akamai.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 14C84126CC7 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 20:14:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 wNX5KVwOOSKw for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 20:14:29 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E29BE124BE8 for <quic@ietf.org>; Tue, 6 Mar 2018 20:14:28 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w274CQkF010805; Wed, 7 Mar 2018 04:14:27 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=2nEk1tt5sZ2NdVbqSTrUDSMOdMF/F4myIgJvPSKIwbM=; b=NzHnmQ+tIL4+E5qZ0CMhSCiRt1lBC3HmuFqmJDaFQtsUl/OAPTut4niQ+7viCldgcQ1z nB0QUjF1BzTcXXDyjNWIVFcu2zrJrIvjJvmvc46k+bqkZbwe3QOpMKyKvYkO4/6nLzxD 49T66+VsluhiTCUKcTRrThmud0GKyoDxZB5J8HeYNyS8WrFOOrTVx636OJHWvx9L1/8L mLKs4zdl9+vJxkQxtfLhRCURynFuR8crXx4Zp0+WvRwjgtpAkGofFVgkWfcfWigiabBx Oqsa3lERcsLG/KnyxXlKt7jL6inVz54McSUw3OFvJvwdETEc7HxalYE87Lp734Zr2y1R gQ==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2gj2w10v2h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Mar 2018 04:14:27 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w274C4OI013339; Tue, 6 Mar 2018 23:14:26 -0500
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2gfqx19d36-1; Tue, 06 Mar 2018 23:14:26 -0500
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 061FF2006C; Wed, 7 Mar 2018 04:14:25 +0000 (GMT)
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <ekr@rtfm.com>
Cc: "quic@ietf.org" <quic@ietf.org>
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: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <8c19058a-7220-5948-6c98-ec339dba53ab@akamai.com>
Date: Tue, 06 Mar 2018 22:14:25 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMBKE46GNHevhcnvBwJ1cbOb369-NKvtzQ7wDcnEZezg+Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F5E1134EB7E9E0C4F904184D"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-07_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803070047
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-07_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803070047
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IQS_GVHSlyLTjNCjLomt-n8ugS0>
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: Wed, 07 Mar 2018 04:14:31 -0000

I am apparently even slower than Ted at reading the document and the
discussion so far, but I largely agree with his conclusions (and there
is of course a lot of overlap with other opinions expressed thus far).

The draft does do a good job of pointing out some flaws in the current
setup, especially relating to "stream 0", but also the version
negotiation roughness (which, to be fair, we've mentioned occasionally
already).

While we do retain the ability to change the DTLS header format (well,
we think we do) in ways that TLS has ossified, as others have pointed
out, we don't actually have as much data about that as we do for QUIC,
and I also think part of the appeal of QUIC to me is that we would not
be starting from something with as much baggage as (D)TLS and could
really shake things up.  Likewise for QUIC-as-transport vs.
DTLS-as-transport, this feels like a step backwards in terms of innovation.

These are definitely interesting ideas to think about, and I expect the
issues raised here to improve the work we end up with, but I'm worried
that redoing the layering like this would make it nearly impossible to
meet our timeline goals.

-Ben

On 03/06/2018 05:25 PM, Ted Hardie 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
> <mailto: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
>
>
>
>