Re: Proposal: Run QUIC over DTLS

Phillip Hallam-Baker <> Wed, 07 March 2018 04:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98484126FB3 for <>; Tue, 6 Mar 2018 20:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5ay1_M8mrFV for <>; Tue, 6 Mar 2018 20:35:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95FA6126DED for <>; Tue, 6 Mar 2018 20:35:11 -0800 (PST)
Received: by with SMTP id 108so911532otv.3 for <>; Tue, 06 Mar 2018 20:35:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2i0mUYn0ALfCO4ucsDZ7FnEzIM7nfvSVpP0saMNp2EM=; b=GvvQAtF+xV5rg+GJp2TS+idSka6+bpFCP46SnJr+sqY3IOxZ5cMdgey+JgpAQLMd4m k7PGgDng1X5VZeGAPLUHU1QfQdqavJceBYPFoHJwVDDEEmIKfDgJgjgHkZYrtWVzO0b5 mvucNa4Iq5x77RZNS5DJ7RpKTDqycE8uikXr7WkuQlg/lXo5Xf+9WoGNP9EtXImRqRwQ lJBiOSiU8kU/W/AT7NER/3Wn/ulU5v0dSN91Qx7pcBz7qnYDMQJyG6150W1GwEPHdGnL eAs52ZAOAuzq9JZsNDi1t2XTMReRPyi+eB+tF/pohjNgoOeN86M0Y0tElQ/Nnxxf17+6 cPjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2i0mUYn0ALfCO4ucsDZ7FnEzIM7nfvSVpP0saMNp2EM=; b=qWIjJ7Qp6EprxNXSkgz6udlulTT+NfhIIR98PaIQdY4N/nNfdiKMAox4mLver+0g2W fiaK+3iFFTHsr5ivyRNFhU9zhBCr1CkpCpJRhsdBHwRxtsv6mK02p22McnuxjTemCtzc Kx68yXwNe+xle8Y4VMYKE/s3PjqPoduWqDwcyYGGiCP1OyQms2AeOA90NcV0NHyOf/Qh cy54NtKfdJ06nI4ZBP3L44k1O/ZBZVECFMNJFG+ru0JYb1D/MZtl6v3tFaorOvoGppv9 MoBSMqfygDT9izVd2KxTlQEHY3NImR/ID/EzpLKzwYn5BDGLvCQcpPCnD2CMN7ndv6Ht 4q3A==
X-Gm-Message-State: APf1xPCfLoHVzfwIMJt9K1zWvm6mLKLhz+Teolxpu5rJXXgECwvSSJUa yezJlZL9hzEvH+E4QX+c/ruUUNjZbsNqcliWs74=
X-Google-Smtp-Source: AG47ELuZ9z34REBdDw9Wtqha992HCQ8JOSl/vwFUho/LkrSnqHzdVn67mJ0pRG1KO8Hk9XkE5Rqc5o5SYgMUTqcCsOU=
X-Received: by with SMTP id r24mr15128971otg.338.1520397310627; Tue, 06 Mar 2018 20:35:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 6 Mar 2018 20:35:09 -0800 (PST)
In-Reply-To: <>
References: <>
From: Phillip Hallam-Baker <>
Date: Tue, 6 Mar 2018 23:35:09 -0500
X-Google-Sender-Auth: 8lPGFTxcroyIBed4BWEt4wADE8w
Message-ID: <>
Subject: Re: Proposal: Run QUIC over DTLS
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="f4030437961c9e15d30566cb15da"
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, 07 Mar 2018 04:35:14 -0000

It seems to me that it would be a good plan to use DTLS framing after the
initial handshake is complete.

Right now it seems that QUIC has got rather complicated and factoring out
the crypto part from the transport part seems like it would aid clarity.

Simplifying the design is always worth it in my view.

On Mon, Mar 5, 2018 at 6:05 PM, 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