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

Martin Thomson <mt@lowentropy.net> Thu, 07 January 2021 05:11 UTC

Return-Path: <mt@lowentropy.net>
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 7F2833A02BC; Wed, 6 Jan 2021 21:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=bXSc0nOK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iWvuZ90z
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 Ir94sfeXGMBS; Wed, 6 Jan 2021 21:11:45 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEEA3A02BB; Wed, 6 Jan 2021 21:11:45 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1BA605C00D4; Thu, 7 Jan 2021 00:11:44 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 07 Jan 2021 00:11:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=x2Jvv00jiAOKqpDWsyPM+sAZ+Mr2 xI2iyfiLGwHFhdU=; b=bXSc0nOK5ad+uX+91tZ060kbJlOO0OJJKbdPuBVEtE5W ccIyOHpI2drbrkYqh1k4d+3ReLdel3lfHfTT2OYLhDUwfaXVjQHh4r7kZ8x/Oc0b TrSEnjFR1EvmR9MZA72WzoLoSiTw6/lhzKIj5lYY6OedTo6DaxiDfp01tqVVxwbu XMa+bZGhclKjA9FlQvcOGKcQQeghBf+6UqyVyIfaywOmJHxLHK2BWeozh1eVyhrN JE8M+07VAIuuvdoTrQpLhN6vkmROHPzWhODeJ/S+CHo2XI2xtAmECVDIc/QtDHFQ 9cdboLlKx8P9fo5vJq2F5OEa+e6OwCbSqZcKkA2MjA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=x2Jvv0 0jiAOKqpDWsyPM+sAZ+Mr2xI2iyfiLGwHFhdU=; b=iWvuZ90zIzLKCdbkLhicoI oENcLMqWHRepAm4+LO7cCUmsf89VGOs9DXAFw/WMt7wgyAV1dgcE7q/gARTpsgXf 5hkD1pvnw/0pcJ5ihksP9qj7UdlCvRZhz6/SLzmG7q+adMkWNh674ofKX4BPOuVy FMcB3pc9yHR3FfkCBYkmw5wh6/rT+g0cZlbkCxwBIyQ0waeY2JhdTfxhw5thMz9C rhKMHw7Hsg1tNEEMXK7X6ub7R5/r1EgWs9WqZDHYGUuiq1FDDF7mr+NmXkLRO+hi OYuH5E6j4oukloYV3aVjI1xA6LFDnXk81xPXX6t23kxKKXS4T95Wt4UnZvx6D5tQ ==
X-ME-Sender: <xms:D5j2X3z54fxhOvm2iBvbrkIQyo3kv77U15GUq1yR5OKRTTxf9SGu8g> <xme:D5j2X_S9ooDqVXNCNdzZ4LQZK9s3AvgmIsHycotroBqBteP_l4G139nd6q9bXX26I CSMAQfiUMQswKP8Uws>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegtddgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeehfeetudduudehtdekhfdvhfetleffudejgeejffehffevkedu iefgueevkeefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:D5j2XxVxRKgfLCStkZMLGUtT1nI_G2wKV-iMnffROQG-S1BwERKo6w> <xmx:D5j2Xxhw_NwmcXvqo2OxGeK15ePFkvtfGe8-nS3Xc2XK5YHvRpFv-Q> <xmx:D5j2X5AOlUbT_UDHlFqMbiT6_B83ooYoFASNWjHMgl3KfGtr6PyRRg> <xmx:EJj2X08klf1MnJzF1dR3SAg0V_K9A_AW1ucMO8AVEJE_SpmAh_aN8A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3E1C72014F; Thu, 7 Jan 2021 00:11:43 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <763f782a-a327-4b03-8dc7-68c953bfe5a4@www.fastmail.com>
In-Reply-To: <20210107040430.GF93151@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>
Date: Thu, 07 Jan 2021 16:11:22 +1100
From: Martin Thomson <mt@lowentropy.net>
To: 'Benjamin Kaduk' <kaduk@mit.edu>
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>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-l_bnEGCH-TKojn9x6rGiO5MtVY>
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 05:11:47 -0000

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.

For TLS extensions can (and have) changed all sorts of stuff.

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

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