Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

Mikkel Fahnøe Jørgensen <> Thu, 07 January 2021 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E27F53A1201; Thu, 7 Jan 2021 07:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ElDJiiRNJ_JZ; Thu, 7 Jan 2021 07:14:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D90E33A11FF; Thu, 7 Jan 2021 07:14:10 -0800 (PST)
Received: by with SMTP id h205so15352296lfd.5; Thu, 07 Jan 2021 07:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JcMYZ/6IgNuFMTXVxfCPoe9KD9GYE0CIHZiSuUsz1EQ=; b=UTnha7jcCpd8JCwuNCE13IINEgINqjwUvF8wUELjTO75ukATXg9gSwEwCDLbAlGhuD u5tRei6PgJpTYCXfIWRjrtGSm0vHfK2N/GIdFr6PGBY8KcNs2HL1qBvjNQmxA2ROiaLV aiplH30ni0fQ++N7agO+af8WdOp82rV8O3G+cXdTiVWV8SxDSOsePrlCYue5K3xZ9jE4 LEzh9uM9+y/VtCC9yWFsh5EBAmNPTbTOrKrAcpiiDdS78yrElzdQxZmK03BlqBn55mbb oey24b7u0SJfFAPiVX+iq7zNJoC90TvkcT6MgGCEVHNTDgNVjZvGRG/KyPYMPQn2K1ep kVZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JcMYZ/6IgNuFMTXVxfCPoe9KD9GYE0CIHZiSuUsz1EQ=; b=R+FqF8RzCjiJSnvJCYlkN8MGzZYMQxeYr+/OMO8EmBNl4n2QDf2pbuoLUBdP7let8w iIDNtlAklKAN1l3P5l5khy0FCzpb4FD+C8CQo/N2dmjXLY/6E30nuUTYZ47AglMh//Nw UXR08B41HpI//agHVvR8bfxR23bQ6+wGjiC2PWpKyiRXq8E1A28sOG1mbES0UTeAhjm6 tBY/8KihnsZS9U8jBKlwlF6gX0s8M5+Wl2xcniYZE2TeLqMu80L9P1zriG1eOrQWpPC8 PkZbJ1lmtMHaGfedTRGWF/5hcTLnoiOLdt04A0VmyrwbBiQJ6fMmc01vhjML1pK4XP38 T2Mw==
X-Gm-Message-State: AOAM532XSimLKXvv+OYZnBtuM+0VusyK6sHSGHnZ2rBWpCklL5PFHiog ii+atTtouq6rqVznPCQzIwg=
X-Google-Smtp-Source: ABdhPJzIVfMwQcPtq/q1LplanGDHSCeRiTqMYPKJQqQiwrW7/Rg2+XZa1lMDU4mPGNfwxEzjcQ/q1w==
X-Received: by 2002:a2e:a484:: with SMTP id h4mr4610990lji.276.1610032448485; Thu, 07 Jan 2021 07:14:08 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e15sm1188878lfc.106.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 07:14:07 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2165548A-CD3E-44C2-B283-ACD5B005E90D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 07 Jan 2021 16:14:05 +0100
In-Reply-To: <>
Cc: Martin Thomson <>, WG Chairs <>,, Mark Nottingham <>,,, The IESG <>
To: Benjamin Kaduk <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 15:14:13 -0000

> On 7 Jan 2021, at 07.26, Benjamin Kaduk <> wrote:
> It seems like only QUIC internals would have to change, not TLS internals?
> My expectation is roughly that, if we were to compare the work needed to go
> from (has TLS 1.3 implementation) to (has QUIC implementation that uses
> quic_early_data instead of early_data) with the work needed to go from (has
> TLS 1.3 implementation) to (has QUIC implementation as currently
> specified), there would not be much difference.  Obviously if you are
> starting from (has QUIC implementation as currently specified), things are
> different, especially if you want to be able to support both draft QUIC and
> RFC QUIC in the same codebase.  I still think that things are cleaner with
> a separate extension and won't involve trying to smush together two things
> that are mostly, but not entirely, the same, but I'm not going to hold a
> Discuss over it.

The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake and the transport keys, but QUIC handles all of its own session encryption with or without help from a TLS library. On a practical level this can also helps performance optimizations in software and in hardware.

From a TLS perspective it may seem reasonable to use the designed feature set, but from a QUIC perspective, QUIC does not necessarily benefit from a tight coupling as long as it can get the keys that it needs. This separation makes it simpler to evolve new versions of QUIC with different crypto designs.

For example, a given TLS library might not support many-core optimizations and this also isn’t critical for obtaining traffic keys, but a large volume of early data could be processed on 24 separate cores in parallel. Getting that to work with any run of the mill TLS library could be a challenge.