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 03:51 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 76A553A14D4; Wed, 6 Jan 2021 19:51:30 -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=DPSaXePO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f7u0lp8H
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 KNf6ZNtS4lgA; Wed, 6 Jan 2021 19:51:29 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E7C3A14D3; Wed, 6 Jan 2021 19:51:28 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 37EEA5C010A; Wed, 6 Jan 2021 22:51:28 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 06 Jan 2021 22:51:28 -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=Bt0qUNlMP5owW/TJGmHn5yBFQPEd yww4p+pLaTcUjqw=; b=DPSaXePOE2Yt4wYhdIod5aozc/1oe9V+0VQODz6/Fqn1 kYqUqmNxWokHHvUv/9kR+OiNht+Cvqw6y94ns8NrQ5vAfpfnnstqBuJ5ZBvVNyZr sJWGruzbWWlBoW13kTkSH5WCgKUJwoJzRoTPur7U7Y9ZNLO0jh/NNhfb9kyiNNWg OrUgShJeSt6rKscKNGxpD78/rOuW3AZ04Dg9eMW/7RIukZYsfAusPdY7mHZqXlEP BMNLddwJgBlOksHqNQ9q7QgSrQ+fzC25ZO9wRyC+CgKmP9fpoQfh7MmtudIZvp6r YKxocqYQ6ruCRA385iPeqYl3EZVCjB8DWAyncURP1Q==
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=Bt0qUN lMP5owW/TJGmHn5yBFQPEdyww4p+pLaTcUjqw=; b=f7u0lp8H53i7mclIx8wPu2 YHcSa/AwTOx3B5xNmdsDGYVU+j8MDIcm5P451mADRsLgkTHQOlYtPZ4m4oMNXXYO sHELwZtNfhqpHpxDp4Oc3470IZ2mFLMRBMNa1jjQEfqH1QcLVbieq0+mfXINby1k xiwiqiNMQPVGHDvg5PabDqnoo4PwhzeMF1pbgiNUZe3DGEP8PVTjHi+/+Whb1CD1 95FxwqR7noRjGY3sMHVr5hT7bu7lRGKCDy5Vcaf1C6qUrbvIXJ/bEus4PQLJmrYJ 3wMK6ckBeYbBHIFvrZFOGp1RrUDwfe156jd4+IThkeu4Y3BqqJ+teR+5pgK/zhSQ ==
X-ME-Sender: <xms:P4X2X9jV-Zj_s-IrG-mkfrvO1uoXZxNaEXwkHFyoOdG16t6dS3iMqg> <xme:P4X2XyA5llNNUJdfs8i4qDtk6BgQC7-LgQ7IPrzQeA4vzCO41W011JHju_CZPvb-I k8sQl9LgNYn6_kiIYw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegtddgudeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeehfeetudduudehtdekhfdvhfetleffudejgeejffehffevkedu iefgueevkeefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:P4X2X9FqKe8psudtQDRgKLS2CLq_OhMQsM0zIfUPVFN0RJzBNSqaoQ> <xmx:P4X2XyStKQbA_zPoN74yDSDmN70Q2FMfb0Kz24bqw15rVEZ3ExOLOA> <xmx:P4X2X6zUwCKOEQW7s10qHIS9MKFPd6FpXHzCBfWXbXZxLfWzY1KA-Q> <xmx:QIX2X0uxcVtHV-hMEIL2jKXua5yZpvVvn2DwF2qtHXIjOltl39vTcw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6EE2A2014F; Wed, 6 Jan 2021 22:51:27 -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: <9b950156-7b73-4bd2-8cd7-b0f4caa9d7af@www.fastmail.com>
In-Reply-To: <20210106035341.GW93151@kduck.mit.edu>
References: <160982240167.15696.6063503687030193256@ietfa.amsl.com> <fe55a7ad-5b57-416d-bc07-2562491c04d6@www.fastmail.com> <20210106035341.GW93151@kduck.mit.edu>
Date: Thu, 07 Jan 2021 14:50:43 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>, tls@ietf.org
Cc: "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/5kvo_KcpTh5zrGd2jfLiaDn7GvA>
Subject: Re: [TLS] =?utf-8?q?QUIC_changes_=22early=5Fdata=22_extension_semant?= =?utf-8?q?ics_=28Re=3A_Benjamin_Kaduk=27s_Discuss_on_draft-ietf-quic-tls-?= =?utf-8?q?33=3A_=28with_DISCUSS_and_COMMENT=29=29?=
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 03:51:31 -0000

Trimming this down.

On Wed, Jan 6, 2021, at 14:53, Benjamin Kaduk wrote:
> I didn't expect to find much appetite for changes, but I wouldn't be doing
> my job if I didn't ask the question.  It's a little unusual for something
> outside the core protocol to change the behavior of an extension defined in
> the core protocol, but perhaps not unheard of.  There is also the question
> of whether it would merit an "Updates:" relationship ... since you have to
> implement the rest of the new thing to get the new semantics, it may not be
> needed.

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.
 
> Which behavior is that, exactly?  The QUIC 0-RTT keys are different than
> the TLS ones, and the data itself is carried in a different place...

I referred to all of the code that involves 0-RTT.

> I think the key question for the TLS WG might be how similar something has
> to be before it's a good idea to reuse an extension codepoint vs. getting a
> new one.

If you like.
 
> 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

(incomplete?)