RE: Proposal: Run QUIC over DTLS

Hannes Tschofenig <> Tue, 06 March 2018 07:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 704D9120724 for <>; Mon, 5 Mar 2018 23:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hTDbx1NhsDP8 for <>; Mon, 5 Mar 2018 23:47:55 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe08::61e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E588C124239 for <>; Mon, 5 Mar 2018 23:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p3zDogW9NZQ5/JKQEjMbgoUx7W7NdbzCo3jilEFoW04=; b=NBAkkovNU3op6QMppMfHFSlZf+tcdfStKfDmP/bhkH+IdtIpaeIOcVoo2JaxyknCIyjravt20u4bQKj6Sfh6aEd/yw16d2/JJ7w0qupNLcj/2KGSdCMbOFYtoPHis8wU2WjrT5uxd1wwMN/5Ui2t+yWE3aff30oNju6LLBJpbyw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 07:47:52 +0000
Received: from ([fe80::783f:d09c:fea6:f83d]) by ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 07:47:52 +0000
From: Hannes Tschofenig <>
To: Eric Rescorla <>, IETF QUIC WG <>
Subject: RE: Proposal: Run QUIC over DTLS
Thread-Topic: Proposal: Run QUIC over DTLS
Thread-Index: AQHTtNappe76W31ejEW/HbZR7/NoDaPC1Aag
Date: Tue, 6 Mar 2018 07:47:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1888; 7:ClRyqfLcQqACyEyB59dMjaQIPhqu+GGdH2Rs8r8h8UCWuBmEv0ubk4DLQzHO2BvPC9LLX/mAE5WVmaPIJHr931tqTUV+pIpnQ+pa+4EY7s+BJJ9/D/Hq0JLgrw+s8yQF41VrVcTeY+bDEzgICqFfk1K5mEHYnCsSnZHa4ThIJtEfMb0TT0soXr80fixENf1R8Mn+A0j4eeQ5PEukPoJKs1N4gPKr7/4fACeOyaYi33Rw+XgzNBFliefSHqadTk3T
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 63910b6d-f69d-4b9f-e8fe-08d5833690ac
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1888;
x-ms-traffictypediagnostic: VI1PR0801MB1888:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(166708455590820)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1888; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1888;
x-forefront-prvs: 06036BD506
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(346002)(366004)(39860400002)(396003)(51874003)(40434004)(199004)(189003)(3846002)(2950100002)(9686003)(55016002)(54896002)(6306002)(236005)(6116002)(66066001)(2900100001)(229853002)(8676002)(99286004)(7696005)(8936002)(606006)(76176011)(790700001)(105586002)(6436002)(86362001)(68736007)(81156014)(316002)(110136005)(97736004)(3280700002)(966005)(14454004)(106356001)(186003)(59450400001)(5890100001)(102836004)(81166006)(6506007)(5660300001)(25786009)(2906002)(5250100002)(53546011)(6246003)(26005)(53936002)(72206003)(74316002)(3660700001)(33656002)(7736002)(478600001)(561944003)(589034003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1888;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Y6yHwijLjwg5hNTFoKGYaHImeJkAclsY2/pMt0Xugu9n5CbsFrtf+hG+BorwZgrn0Rd7Wyp9rbTvxI5h3QYLDcUVUBKDkQaW80+LjuA2NmI1kY1wgcq6Nab/jynFmDbkZQNHB0lcHHrBm8L9+FwZIrQhz1sO/fdCmZrNVGifuoo38424d713xWgvKUddZaQ+fjD9OUWE0/ON7ZeCK1yt991Wz0OG99p4LdakQKSmE8fBfhRhfOxDjiex6qHEzG4KpK3JIvjfAZ6QlhjtFq/vIdOHI98iN1wyvX8XbgbSh1/lyql8aPCXFqKM17nUVQ+MgXdKdHqI2PG6BuPZFiDr5g==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112334B8D33EFA40A863F7EFAD90VI1PR0801MB2112_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 63910b6d-f69d-4b9f-e8fe-08d5833690ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 07:47:52.0423 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1888
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 07:48:00 -0000

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.