Re: Proposal: Run QUIC over DTLS

Leif Hedstrom <leif@ogre.com> Wed, 07 March 2018 18:21 UTC

Return-Path: <leif@ogre.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 1C4F11271DF for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 10:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ogre.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 Am8lbp0E82eh for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 10:21:32 -0800 (PST)
Received: from cosmo.ogre.com (cosmo4.ogre.com [71.6.165.248]) (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 F28C5120721 for <quic@ietf.org>; Wed, 7 Mar 2018 10:21:31 -0800 (PST)
Received: by cosmo.ogre.com (8.15.2/8.15.2) with ESMTPSA id w27ILToP015369 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Mar 2018 10:21:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogre.com; s=03062012; t=1520446889; bh=kUrgOksRff378aiRcCYH7jCzHU9Kf2cwNSbYUQGDohw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YwgSk4R/Dvzf4Zmr2Pp9SIGGKclnxxbf1kSzaxAig6GdERoDb3w1Ouz0EuhsoRDWj Z6eE0nELJ43zIGI0oFxkhDPRfGJssOKY387iOaBYzcTsOn/nYLfK4pt+z1anjmIvHP CoHzswUfbWLhNkzaieLN7yYLtFItEOaeQAe3dUFs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Proposal: Run QUIC over DTLS
From: Leif Hedstrom <leif@ogre.com>
In-Reply-To: <CAM4esxSkAhU2m6KiVAxibAYmCKFhBsyBCOMzJFfud6rQDMvHrA@mail.gmail.com>
Date: Wed, 7 Mar 2018 10:21:28 -0800
Cc: Ted Hardie <ted.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>, "quic@ietf.org" <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <17BE7149-8443-439D-993E-83368E5ECE8D@ogre.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> <CAM4esxSkAhU2m6KiVAxibAYmCKFhBsyBCOMzJFfud6rQDMvHrA@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ms_eCs0JB5YL8x1PvwlTdRHA1DY>
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 18:21:33 -0000


> On Mar 6, 2018, at 3:44 PM, Martin Duke <martin.h.duke@gmail.com>; wrote:
> 
> 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.


This was my initial reaction as well. TLS v1.3 being such a moving target for the last ~12 months has been one of the biggest challenges to QUIC interop / development. I don’t know what state the various TLS implementations are for DTLS v1.3, but I’d be concerned that we start that circus up all over again.

I think assessing the state of DTLS v1.3 specifications and implementations is critical before making a technical decision. [I’m saying this with very little knowledge of the DTLS v1.3 world :-].

Cheers,

— Leif