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 <mikkelfj@gmail.com> Thu, 07 January 2021 15:14 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27F53A1201; Thu, 7 Jan 2021 07:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElDJiiRNJ_JZ; Thu, 7 Jan 2021 07:14:11 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90E33A11FF; Thu, 7 Jan 2021 07:14:10 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id h205so15352296lfd.5; Thu, 07 Jan 2021 07:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.8.100] (109.58.155.143.mobile.3.dk. [109.58.155.143]) by smtp.gmail.com with ESMTPSA id e15sm1188878lfc.106.2021.01.07.07.14.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 07:14:07 -0800 (PST)
From: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Message-Id: <3E23F4A2-214B-48A0-8415-539F9B45397A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2165548A-CD3E-44C2-B283-ACD5B005E90D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 7 Jan 2021 16:14:05 +0100
In-Reply-To: <20210107062637.GG93151@kduck.mit.edu>
Cc: Martin Thomson <mt@lowentropy.net>, WG Chairs <quic-chairs@ietf.org>, draft-ietf-quic-tls@ietf.org, Mark Nottingham <mnot@mnot.net>, tls@ietf.org, quic@ietf.org, The IESG <iesg@ietf.org>
To: Benjamin Kaduk <kaduk@mit.edu>
References: <160982240167.15696.6063503687030193256@ietfa.amsl.com> <fe55a7ad-5b57-416d-bc07-2562491c04d6@www.fastmail.com> <20210106035341.GW93151@kduck.mit.edu> <9b950156-7b73-4bd2-8cd7-b0f4caa9d7af@www.fastmail.com> <20210107040430.GF93151@kduck.mit.edu> <763f782a-a327-4b03-8dc7-68c953bfe5a4@www.fastmail.com> <20210107062637.GG93151@kduck.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/u_HX8Lff_c0DbWlmZjaE_C9eXT0>
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-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 15:14:13 -0000


> On 7 Jan 2021, at 07.26, Benjamin Kaduk <kaduk@mit.edu> 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.

Mikkel