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> Thu, 07 January 2021 06:26 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 D57803A09B9; Wed, 6 Jan 2021 22:26:49 -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 OdFP6rNiUXni; Wed, 6 Jan 2021 22:26:48 -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 39FB03A09B7; Wed, 6 Jan 2021 22:26:46 -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 1076QcAN032429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 01:26:42 -0500
Date: Wed, 06 Jan 2021 22:26:37 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-quic-tls@ietf.org, WG Chairs <quic-chairs@ietf.org>, quic@ietf.org, Mark Nottingham <mnot@mnot.net>
Message-ID: <20210107062637.GG93151@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <763f782a-a327-4b03-8dc7-68c953bfe5a4@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kL3UK93x5VjryMhEMjSx5hQqQuo>
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 06:26:50 -0000
On Thu, Jan 07, 2021 at 04:11:22PM +1100, Martin Thomson wrote: > I'm not sure that the other discussions are productive any more, so I'll fix my errors... > > On Thu, Jan 7, 2021, at 15:04, Benjamin Kaduk wrote: > > > > This isn't an "Updates: X" moment at all in my view. Extensions to TLS have added new handshake messages (certificate status for instance) without updating what it means to implement the core protocol. It's only an update in my view if the functions defined in the updated document. > > > > (incomplete?) > > Sorry, ... if the functions in the update alter the operation of the core protocol in ways that the core protocol does not anticipate or allow. Okay, thanks. 8446 doesn't anticipate changes to EndOfEarlyData for TCP+TLS, but this is ... not that. > For TLS extensions can (and have) changed all sorts of stuff. It has not always gone smoothly... Anyway, I propose that we proceed with your suggestion of (roughly) "including the 'quic_transport_parameters' extension in EncryptedExtensions suppresses the requirement to send EndOfEarlyData otherwise implied by sending 'early_data' in EncryptedExtensions". > > > I referred to all of the code that involves 0-RTT. > > > > At what layer? I honestly do not understand which parts you see as "the > > same behavior". The application will have some data to send early, sure, > > but at some point your interface has to know if it's running over TCP+TLS > > or over QUIC, and the only differences I see are below that point. Any > > given TLS handshake is intrinsically destined for QUIC or not-QUIC, so > > you're never in a situation where you would send both extensions at the > > same time. > > I was largely referring to the TLS internals that would change if early data was conditioned on a second extension. It's not a big change, but it would definitely be a difficult one to get right. My guess is that 0-RTT accounts for about half of the complexity of TLS 1.3 in our stack. 0-RTT in QUIC is relatively easy once TLS has it (it only took me a few hours to implement, from memory). 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. > > For what little it's worth, the patches to enable building a QUIC stack on > > top of OpenSSL (that have been rejected by upstream at this point in the > > 3.0.0 release cycle and are now maintained by Akamai and used by several > > parties) don't implement support for early data at all, so I don't have any > > direct implementation insight to provide. OTOH, that suggests that people > > might not be using QUIC 0-RTT with the openssl TLS stack at all. > > 0-RTT is a feature that isn't uniformly supported (I don't think that Google implementations have support yet, though I could be wrong). It's in Firefox and awesome though. My data from a couple months ago is that google does QUIC 0-RTT but not TLS 0-RTT, if I'm reading my notes properly. -Ben
- [TLS] QUIC changes "early_data" extension semanti… Benjamin Kaduk
- Re: [TLS] QUIC changes "early_data" extension sem… Eric Rescorla
- Re: [TLS] QUIC changes "early_data" extension sem… Martin Thomson
- Re: [TLS] QUIC changes "early_data" extension sem… Benjamin Kaduk
- Re: [TLS] QUIC changes "early_data" extension sem… Martin Thomson
- Re: [TLS] QUIC changes "early_data" extension sem… Benjamin Kaduk
- Re: [TLS] QUIC changes "early_data" extension sem… Mikkel Fahnøe Jørgensen
- Re: [TLS] QUIC changes "early_data" extension sem… Spencer Dawkins at IETF
- Re: [TLS] QUIC changes "early_data" extension sem… Benjamin Kaduk