RE: Proposal: Run QUIC over DTLS

Mikkel Fahnøe Jørgensen <> Tue, 06 March 2018 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3515124D37 for <>; Tue, 6 Mar 2018 00:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZJJxC0T1b6QH for <>; Tue, 6 Mar 2018 00:49:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4ECC1120724 for <>; Tue, 6 Mar 2018 00:49:31 -0800 (PST)
Received: by with SMTP id e7so21220307ioj.1 for <>; Tue, 06 Mar 2018 00:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=fGuBLosc33akxaeI5umKGD1XWpNq4yKKLMhtQ3E6nCE=; b=FaoE2paxAnmN8RPRtRCVKU9CcIOQU8G7QwdlV60TboQpWSLpdD9NDHQ//TcMcp18rl 536nQGP7UKwhxecsfAEvcoMJE0unmL9qDeSbO66IwtHnSuvT+dfLS9X6CFx4p7LC7Sba lhllLE475/IpfHVNPnzMWjlvnmqTJdZ78W/cYiiaWhPWX1BTKRm1pbMIcu3GtvJv5573 dxWybvv8zQ9oOIm+kavbzEFF4nIjKpu2kDlYyo3oYCaZz9xgguZwbaQRBKKyU6GeSQsh SLnRDDJ51Fhtw0M/XC5v+jO3tVgpPi8ku5aGCp7+62YA1Hqii+3TNXf2UhY3ewbIzuXK 7RVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=fGuBLosc33akxaeI5umKGD1XWpNq4yKKLMhtQ3E6nCE=; b=tmKqgfv/GidQLXpXM7znfaA7US7v0ZvojHND2cJu98Ik3EacaD4+WBoe0VBXSe+15f Jiz1NS4HxwqVCkhwCQTqfKxlIWEeOUDB6+Vzs4ilhCu2erOrvZFrDnKtMfKE33RsgPKK dhLJq97jvZGIwenqACRGhgVRidzHYQVxEYkuUizn7r8OnoJRJfhh8oSlcuEs7mEg7qS3 y7V75WBmCZKNZcXO9BhUSA0jP0SHAWW0gVNdM6cqUSTlp6SmzEBa1nyrGZzjiAGGY+WW 5w8ASz5S4rlUNBLnu1AaIvNVqe/KTIxmwCvsbRffFT81VMhcr0uhwIV+ELncfLjPydZ1 LR/w==
X-Gm-Message-State: APf1xPBr6AmZDyumGDpySXQsQbp1rUGpFgWB6H7JL47UddMwY57zyhZL cAPK20Y/e9mv1WcDhYsabiA0/faepdJa5EmW/MXC0w==
X-Google-Smtp-Source: AG47ELtoE1/WstwtmGCWuep9LIPdsvEDS3zQgJm/oG+/LGrSH0iF5oGBAWNpye1oUlODGvz9BdOpiqmloxlHyXcDsRY=
X-Received: by with SMTP id z20mr20758920ioi.274.1520326170553; Tue, 06 Mar 2018 00:49:30 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 6 Mar 2018 00:49:29 -0800
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 6 Mar 2018 00:49:29 -0800
Message-ID: <>
Subject: RE: Proposal: Run QUIC over DTLS
To: Hannes Tschofenig <>, Eric Rescorla <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="001a113eda8a56b54a0566ba85ea"
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: Tue, 06 Mar 2018 08:49:34 -0000

This is an interesting proposal.

- It clearly points out that the current crypto handshake does not map as
cleanly as it could be - also noting the recent discussion on list about
truncating stream 0 early.

- It makes it much simpler to layer QUIC over other transports. For
example, a low-end device on a very secure line, such as an ABS breaking
system, could send QUIC without crypto framing to a central core, but still
use all of the QUIC semantics.

- It could simplify/accelerate use of QUIC in web browsers.

- It is a hammer allowing applications to deploy DTLS without only using
QUIC. Sometimes QUIC may be need a lot of spec work to map a concept - for
example IoT MQTT over QUIC is not clear cut, but it is easy to use DTLS.
Having to use both DTLS and QUIC in app may be a bit much if they are not
fundamentally the same.

That said, I agree with Ian and others - there are a bit too many moving
parts and dependencies. It is very nice to have a single self-contained
construct. Already the need to depend on TLS adds a lot of complexity (even
if it can be hidden by third party libraries).

I would suggest how to reconsider a much cleaner crypto mapping inside QUIC
based on these findings as Ian, Kazuhu, and Sudbodh also touches upon.

Even if this fails due to timeline - it may be worthwhile goal for v2.

If QUIC invariants were tied to DTLS it might not be possible to move out
of that tie-in - even for custom or special purpose versions of QUIC - i.e.
too much friction.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 6 March 2018 at 08.48.09, Hannes Tschofenig (

To be honest, I have been wondering why the QUIC group started with TLS 1.3
instead of DTLS 1.3 all along.

For me this makes sense.



*From:* QUIC [] *On Behalf Of *Eric Rescorla
*Sent:* 06 March 2018 00:06
*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....


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,


  * 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:



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,


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.