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

Spencer Dawkins at IETF <> Fri, 08 January 2021 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE15C3A11D8; Fri, 8 Jan 2021 10:53:01 -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 FG7Z7B4KsSIk; Fri, 8 Jan 2021 10:53:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 623DC3A11D5; Fri, 8 Jan 2021 10:53:00 -0800 (PST)
Received: by with SMTP id r63so10282566ybf.5; Fri, 08 Jan 2021 10:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dHbsGPA0CFaLynnCPqeYQ4hK5e5eL33PpTGVwEQrrd0=; b=QegE8qFqcT82AJsRRYc4OKvZThgLoMUYNZFBZudNZi0qqpb2moNr0B/OcLqMaEkxYQ zWl8B5Y8ltQfW6Q+2kZXm3LQZ+OPxPQWqbhKBnVkmGHVws8iO1GuRewVE6P9Q0YArAyO xx/7gWS7tOTLWlXbaJoQr2eLOxgp6mbMBg0//1gx8OduTfBq/U3tAaooyS9y88tDz2TZ 5ORJjuxv7S/Kk5NGWbXLrF2eTd8BXCvun9b929SznuYuTcQRTVd9rvJF9yrcPl8QlCCM pvEvGlHenEW9fInKjF3GHUf7r5h9TdosdfElyVuqF1OqmS/26epPn4asMFyLK7r7nKtn w4Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dHbsGPA0CFaLynnCPqeYQ4hK5e5eL33PpTGVwEQrrd0=; b=Y+gPon9d0CD2bS+nslAUB+baO7L9nopehOG4mEM403cGs1hjZr1PQ3wC1YEJiD4JM/ TrLCfIRvtFQi1hdeawvLu0IwUwnZHbS3v4kgpymjH5I0KU9CyabH12sVxq9jEYvclBlO lUBJU7SkaEzQJcqqo2A6zfIG0ph55aNeoS5tw6C1VsM7tXkryVNTneuNqEqoJTkBlKGZ xzpGeI2KAmcrwu2Sokxlmh50i1ZWYfr4sw+bVMA2k6/VZU4Jwcj7mpEU6hPI4Boo5+rl wBCmT7xD2wIhqnzrFYSrjDA6IYjA2lY9ZSM/izMQtw9eF1SxSUNjaiKFablZGzGJL+Ow CcTQ==
X-Gm-Message-State: AOAM533Ij5yorIj+/t9lIrRSmNdKh5ufiyF6/sX/7wkDc9W1/6wA76y+ 8Hke5GLINgLiN87Y0oDWdnORsWo3fDOIYp07AJA=
X-Google-Smtp-Source: ABdhPJzA198UAaCjTAhggleVXXmx6e0VAlqZOlEuNZy3uEOEkoe/Y9WT/suJZ96p8JpcW1vyJSMH+C0ES/wy3o6w34M=
X-Received: by 2002:a25:7795:: with SMTP id s143mr7779166ybc.53.1610131979246; Fri, 08 Jan 2021 10:52:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 08 Jan 2021 12:52:33 -0600
Message-ID: <>
Subject: Re: QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))
To: Mikkel Fahnøe Jørgensen <>
Cc: Benjamin Kaduk <>,, WG Chairs <>, Mark Nottingham <>,, IETF QUIC WG <>, Martin Thomson <>, The IESG <>
Content-Type: multipart/alternative; boundary="000000000000aa223705b86810fb"
Archived-At: <>
X-Mailman-Version: 2.1.29
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: Fri, 08 Jan 2021 18:53:02 -0000

For what it's worth,

On Thu, Jan 7, 2021 at 9:15 AM Mikkel Fahnøe Jørgensen <>

> 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.

I asked about how closely QUIC would be tied to TLS 1.3 during charter
discussions, and the answer I got then was that most of what would keep
QUIC tied to TLS 1.3 was that the security people who replied weren't
expecting any replacement for TLS 1.3 anytime soon. So this was a case of
QUIC using the only handshake that made sense, not the only handshake that
could work.

So I'm agreeing with Mikkel here.