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

Benjamin Kaduk <kaduk@mit.edu> Fri, 08 January 2021 19:28 UTC

Return-Path: <kaduk@mit.edu>
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 643633A1231; Fri, 8 Jan 2021 11:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 9sEfL8wB7Yd9; Fri, 8 Jan 2021 11:28:05 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7F63A0B5F; Fri, 8 Jan 2021 11:28:03 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 108JRt3l018149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Jan 2021 14:28:00 -0500
Date: Fri, 8 Jan 2021 11:27:54 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= <mikkelfj@gmail.com>
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>
Message-ID: <20210108192754.GC35887@kduck.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> <3E23F4A2-214B-48A0-8415-539F9B45397A@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3E23F4A2-214B-48A0-8415-539F9B45397A@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-oNhYMbnJRy2O8D9hf4bhFnzUec>
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: Fri, 08 Jan 2021 19:28:07 -0000

Hi Mikkel,

I suspect I'm misunderstanding something, because it sounds to me like you
are supporting a dedicated "quic_early_data" extension to help decouple QUIC
from TLS.  More inline...

On Thu, Jan 07, 2021 at 04:14:05PM +0100, Mikkel Fahnøe Jørgensen wrote:
> 
> 
> > 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.

Yes.  This is what I mean by QUIC 0-RTT and TLS 0-RTT being different --
TLS provides keys, but the actual data handling is done by QUIC.  Using the
TLS mechanism to negotiate TLS early data as an indication that QUIC early
data should be used seems to needlessly couple TLS and QUIC for little
gain.

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

This just seems to be reconfirming that TLS only provides keys to QUIC but
doesn't do any of the bulk-data-handling work.  So a flag that tells TLS
"give me QUIC 0-RTT keys" would work just fine, and there's no reason to
make it be the same flag that says "do TLS 0-RTT".

-Ben