Re: Proposal: Run QUIC over DTLS

Eric Rescorla <ekr@rtfm.com> Tue, 06 March 2018 00:42 UTC

Return-Path: <ekr@rtfm.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 5C79D12EA59 for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 16:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qsvsnf6uwKWG for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 16:42:46 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 B77BB12D7FC for <quic@ietf.org>; Mon, 5 Mar 2018 16:42:39 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id s198so22976325qke.5 for <quic@ietf.org>; Mon, 05 Mar 2018 16:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XBfHh5YLscAVnmE4yprictJ9Mqo/WGuU8QmgNEb8r7U=; b=VcSDlMnzajk5mKLez1R4gjgjkM8oZ7YBlAwUccqCXeZcAM+cKrZR8kAjBfQXc/R59u oK+gH+mTHjcwWRTtefnXTgPISlK0RiVkhnQ4sy9baxuDyGV/x3Wov7XQZQUJH6VGTxPz apN8q9U+gnFslHLSA+toMwxfd/DGo+uwb8CEVcGMU+pyQorFox0PvMKSURFXwRK3kj8R 8CUmYorFJXLCBk/Cg8+pENll2uz70gDGklOCGdr3sIZiOUg9bA+8h7doGEVJx4vDrsA2 slA7pw5e/fza98JEQmtCFnXtcQc/4BP1bKWECNvlU2Zy1pYbkm31Cv+ZE1HenXjaPO3k fFXw==
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=XBfHh5YLscAVnmE4yprictJ9Mqo/WGuU8QmgNEb8r7U=; b=TvEYBqJIIIwg0wgMFfoexsA8QX50TTlPrvPhkQcKiDzaA7rKtvi7+0m8qjR1Ydb1q5 jd430w+JqDwYPidTUwGEcltkFVRJ1jDlGVZiJdYaQ2e87PguEZ9yVpP00pMnig4OLrJh /OcXniQMKeFYUyXZXq1benOtXl72he3+caeORIB0D7TT6USwazGjkDdEFmPXXPGOJURt SCAXTHTIgNjiaUtAllQKQtIQsbfzasI11G6UH7z1LJ2ZVvb9V/bxXnKmBNjHtwy7kGx6 PytKh2GpVqyzgv92gSKvkiTCIRRvjtrqi97CyQDmFPUiWOvx6QHSWc0+yN9hDdnNJ/nj 6/Aw==
X-Gm-Message-State: AElRT7GVY4r0Nmyh4TulsQu0F5cgDY9qaUnZRTvY4sONjfQQX9DJKMae C+6RkO/1+tTRULI3KZtoRoEarpbNqj8r1vHFMAwWF38+
X-Google-Smtp-Source: AG47ELu2QHUYcm/d10VC3fYz5UPotDny6mprGhFBAweFxZW19JssAPre5bjBOzaJjJ16V4gXemD94Hd4xsXE2sCwUaA=
X-Received: by 10.55.43.220 with SMTP id r89mr25013307qkr.152.1520296958592; Mon, 05 Mar 2018 16:42:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 5 Mar 2018 16:41:57 -0800 (PST)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAE6477@bgb01xud1012>
References: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAE6477@bgb01xud1012>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 5 Mar 2018 16:41:57 -0800
Message-ID: <CABcZeBO+H3Tqr5_eVON6jcUkfZEwVtFZ2NMP=-1AtFTwOzEbbg@mail.gmail.com>
Subject: Re: Proposal: Run QUIC over DTLS
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1149442c2b9eda0566b3b83c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pWI2s1bJOqsWNcibdA4RO8lWk5c>
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 00:42:52 -0000
X-List-Received-Date: Tue, 06 Mar 2018 00:42:52 -0000

On Mon, Mar 5, 2018 at 3:58 PM, Lucas Pardue <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


>
> Regards
> Lucas
> ------------------------------
> *From:* QUIC [quic-bounces@ietf.org] on behalf of Eric Rescorla [
> ekr@rtfm.com]
> *Sent:* 05 March 2018 23:05
> *To:* IETF QUIC WG
> *Subject:* Proposal: Run QUIC over DTLS
>
> Hi folks,
>
> Sorry to be the one randomizing things again, but the asymmetric
> conn-id thing went well, so here goes....
>
> TL;DR.
> I'd like to discuss refactoring things to run QUIC over DTLS.
>
> DETAILS
> When we originally designed the interaction between TLS and QUIC,
> there seemed like a lot of advantages to embedding the crypto
> handshake on stream 0, in particular the ability to share a common
> reliability and congestion mechanism. However, as we've gotten further
> along in design and implementation, it's also become clear that it's
> archictecturally kind of crufty and this creates a bunch of problems,
> including:
>
>   * Stream 0 is unencrypted at the beginning of the connection, but
>     encrypted after the handshake completes, and you still need
>     to service it.
>
>   * Retransmission of stream 0 frames from lost packets needs special
>     handling to avoid accidentally encrypting them.
>
>   * Stream 0 is not subject to flow control; it can exceed limits and
>     goes into negative credit after the handshake completes.
>
>   * There are complicated rules about which packets can ACK other
>     packets, as both cleartext and ciphertext ACKs are possible.
>
>   * Very tight coupling between the crypto stack and the transport
>     stack, especially in terms of knowing where you are in the
>     crypto state machine.
>
> I've been looking at an alternative design in which we instead adopt a
> more natural layering of putting QUIC on top of DTLS. The basic
> intuition is that you do a DTLS handshake and just put QUIC frames
> directly in DTLS records (rather than QUIC packets). This
> significantly reduces the degree of entanglement between the two
> components and removes the corner cases above, as well as just
> generally being a more conventional architecture. Of course, no design
> is perfect, but on balance, I think this is a cleaner structure.
>
> I have a draft for this at:
> https://datatracker.ietf.org/doc/draft-rescorla-quic-over-dtls/
>
> And a partial implementation of it in Minq at:
>
> Mint: https://github.com/ekr/mint/tree/dtls_for_quic
> Minq: https://github.com/ekr/minq/tree/quic_over_dtls
>
>
> I can't speak for anyone else's implementation, but at least in my
> case, the result was considerable simplification.
>
> It's natural at this point to say that this is coming late in the
> process after we have a lot invested in the current design, as well as
> to worry that it will delay the process. That's not my intention, and
> as I say in the draft, many of the issues we have struggled over
> (headers especially) can be directly ported into this architecture (or
> perhaps just reused with QUIC-over-DTLS while letting ordinary DTLS do
> its thing) and this change would allow us to sidestep issued we are
> still fighting with, so on balance I believe we can keep the schedule
> impact contained.
>
> We are designing a protocol that will be used long into the future, so
> having the right architecture is especially important. Our goal has
> always been to guide this effort by implementation experience and we
> are learning about the deficiencies of the Stream 0 design as we go
> down our current path. If the primary concern to this proposal is
> schedule we should have an explicit discussion about those relative
> priorities in the context of the pros and cons of the proposal.
>
> The hackathon would be a good opportunity to have a face to face chat
> about this in addition to on-list discussion.
>
> Thanks in advance for taking a look,
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>