RE: Proposal: Run QUIC over DTLS

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Tue, 06 March 2018 13:47 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 1CBDC1270A3 for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 05:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N_VXslIlzdgo for <quic@ietfa.amsl.com>; Tue, 6 Mar 2018 05:47:03 -0800 (PST)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074E51200B9 for <quic@ietf.org>; Tue, 6 Mar 2018 05:47:02 -0800 (PST)
Received: from BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w26Dl1n4023297; Tue, 6 Mar 2018 13:47:01 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 13:47:00 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Eric Rescorla <ekr@rtfm.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Proposal: Run QUIC over DTLS
Thread-Topic: Proposal: Run QUIC over DTLS
Thread-Index: AQHTtNasRSJyGeXsQkuB73WZyQ8CZKPCTlazgAAP2ICAANs6gA==
Date: Tue, 06 Mar 2018 13:47:00 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE656C@bgb01xud1012>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAE6477@bgb01xud1012> <CABcZeBO+H3Tqr5_eVON6jcUkfZEwVtFZ2NMP=-1AtFTwOzEbbg@mail.gmail.com>
In-Reply-To: <CABcZeBO+H3Tqr5_eVON6jcUkfZEwVtFZ2NMP=-1AtFTwOzEbbg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23702.007
x-tm-as-result: No--32.022600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE656Cbgb01xud1012_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/dN8cJmG7thH8NegvpyGTrhH8BGc>
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 13:47:05 -0000

Hi,

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: 06 March 2018 00:42
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Proposal: Run QUIC over DTLS

On Mon, Mar 5, 2018 at 3:58 PM, Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> wrote:
Hi EKR,

This is a very interesting proposal, especially because I have little experience with DTLS. (I also have little experience with QUIC's use of TLS 1.3 so can't comment too strongly in that regard).

One aspect of the current QUIC design I like is the separation between key exchange and packet protection. Which allows some alternative use cases. So I read your draft and was not sure if DTLS maintains that possibility or not. Section 6.4 seems to touch on this topic but I wasn't sure if you are asserting the flexibility exists nor or could exist with some work. The link to draft-putman-tls13-preshared-dh "Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs" is quite well aligned to to the use case I was thinking of. It would be nice to leverage such work rather than have to reinvent it for QUIC's current design.

Hi Lucas,

DTLS and TLS have pretty similar designs in this respect (DTLS is primarily a thin reliability layer on the TLS handshake), and in general TLS has key exchange and packet protection separated, in much the same way things are in the current QUIC design, just with a different packet encryption.

TLS is explicitly designed to allow for flexibility in the crypto core, so I would imagine we're going to see a bunch of innovation there over the next few years. The putman draft is one example of what people are looking at, but I'm aware of others as well.

-Ekr


Thanks for the clarification!

Lucas



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------