Re: Proposal: Run QUIC over DTLS

Mark Nottingham <> Wed, 14 March 2018 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6E4F129C70 for <>; Wed, 14 Mar 2018 03:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.821
X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Pvn/v9rT; dkim=pass (2048-bit key) header.b=GJw7KXkM
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w8hEDVOAec4b for <>; Wed, 14 Mar 2018 03:43:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB23C129C6E for <>; Wed, 14 Mar 2018 03:43:13 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 9CEF120FD4; Wed, 14 Mar 2018 06:32:10 -0400 (EDT)
Received: from frontend2 ([]) by compute3.internal (MEProxy); Wed, 14 Mar 2018 06:32:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Qk3gPzWtSjewB1iRNRpPqK/N73jPD SbUhcRbA7i9NF0=; b=Pvn/v9rTZDEPn/aEqrA2n0zJB4fdGXE/f/Pwbf/tIDXD1 xWb7Zm7MhIGc44LPB02XFAlmsSgi4wVavRsvHbe3Ju6zovnlj17tBkCFw36w2ews VigtHVVHFeoJSo+Wm0pYa9hOTnb+qrQdgEUSM0W31DkwDlL1S73x8gCuXRj4ZHyw keX4xTXt+Fgsq8bsEXoYHTBYv4a9ZSAHz6mUtuvpX5X+331PvTQrJPnyLJ320mJc onOURnceBftJvOWoG4E9z86SEeF5hoVk5+1dxYCOEOHABozptZ1YI8Q1HvAtz6Wu caER0zaHN00lbZxbtT6yib0SwmEpgIy8phjz09qyg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Qk3gPz WtSjewB1iRNRpPqK/N73jPDSbUhcRbA7i9NF0=; b=GJw7KXkM8FEQ04csH8vBZJ oGnsMknePmhQwrdaVkPIYk7JsJytasJQzYIk6zWxN9s0FmQV+4SW9J0dn5mf6HRJ /yTfEZuTy4WqZg48xVtQjmjUhojk/ns5p39djoqcOLGr9PFE6HYr4hd0wzTAjJcX K0eomIxItbh/2FA6/CkfEorqpQ5PssYHgkgMKClOQLy9IcdNDZsKOgR/IkODJ2n8 5bJpTZC0w7a/v3fWEya9qvIqLz8GcXigQBP8DCP6Ujm2bbmYgDkOZElNIG+lLpBp j0021Lfrgwb4Di4t8RkbY/ojXZ4pMo4W/CQ51al5gt5OEncs7KoykD5gIC138wJA ==
X-ME-Sender: <xms:KvqoWsz-dYPfUf9Ksvmjp6NLUTcfTPeuSd2dT6-5G2kTLSNSKi4FgA>
Received: from [] (unknown []) by (Postfix) with ESMTPA id 4E032240DC; Wed, 14 Mar 2018 06:32:09 -0400 (EDT)
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: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 14 Mar 2018 10:32:07 +0000
Cc: Eric Rescorla <>, Lars Eggert <>, IETF QUIC WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Mar 2018 10:43:17 -0000

At this point, I think we will still benefit from having some face-to-face time devoted to this these issues, even if many people feel we shouldn't take the DTLS proposal wholesale. 

Having said that, the recent re-statement of the issues as 1) stream 0 and 2) the layering question seems most appropriate. EKR, can you make sure your presentation focuses on them, with DTLS as one possible solution? I'll adjust the title in the agenda accordingly.


> On 13 Mar 2018, at 6:30 pm, Mirja Kühlewind <> wrote:
> Hi Mark,
> coming back to this initial mail, I believe that it is clear that people are interested in the problem(s) that this proposal is addressing but not the actually solution as there is a strong feeling that it is too late for such a fundamental change in the process.
> I just looked at the draft agenda and it (still) say "QUIC over DTLS Proposal". Is there a plan to change this and level this up to a more higher level discussion on the problems or do people still want to use the time to discuss this concrete proposal?
> Mirja
> On 06.03.2018 02:46, Mark Nottingham wrote:
>> Thanks for the proposal, EKR. We'll track this as <>.
>> Since we're trying to nail down the invariants in London (or soon afterwards), I'd like to figure out the WG's feelings on this pretty quickly.
>> I know folks need a chance to read and digest, but it would be extremely helpful if we could have some initial discussion on-list now. Please focus on the technical merit of the proposal, clarifying questions, and statements of support/lack thereof.
>> Assuming it's still a topic of interest in two weeks, we'll schedule some time to discuss it in London. EKR, could you please submit a presentation (say, max 20 minutes, plus discussion time afterwards) ASAP?
>> Cheers,
>>> On 6 Mar 2018, at 10:05 am, Eric Rescorla <> wrote:
>>> 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.
>>> 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:
>>> And a partial implementation of it in Minq at:
>>> Mint:
>>> Minq:
>>> 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
>> --
>> Mark Nottingham
> <mirja_kuehlewind.vcf>

Mark Nottingham