Re: [TLS] Application-Layer Protocol Settings

Martin Thomson <mt@lowentropy.net> Thu, 09 July 2020 00:16 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 F0E823A0A14 for <tls@ietfa.amsl.com>; Wed, 8 Jul 2020 17:16:45 -0700 (PDT)
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Q39Km79d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gEeAKRji
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 bAXRlnMCbh9k for <tls@ietfa.amsl.com>; Wed, 8 Jul 2020 17:16:44 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7985A3A0A0E for <tls@ietf.org>; Wed, 8 Jul 2020 17:16:44 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7A3295C0100; Wed, 8 Jul 2020 20:16:43 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 08 Jul 2020 20:16:43 -0400
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=fm2; bh=6sAvQFelyyPu3jRZ+Vnk9CZxdZ8q F6iY44RSIahhgQY=; b=Q39Km79deEbMBKrbnepywp2d73unE5mfcOf8BUppr+0/ heR9gCRa3SEVcTVTQ08+/ffiaRHpb65gf9qkHANsevNfPp1+Y7yu6ITNXVuPwx8+ pr9T95vZFfxn9ureWom296lfZAB7QNEwV4bjpG9UfBTHtqEln+8NC98OkBDp0OMI MOjfhySUX7AcVD72ENpcQklr8kXCQD87OXVcE3sO5j1BjNS3OxaU3LT2yprJ4ZPx 1VbnEjSMaRT/v/ko50vFQTooxFPft1Er7Ae/2jh5gWHUMZ6hzp2Gdo1QQlYRuOBc aWNck+X278jpch9muw4eWf0ye2IAGaBdzP4wd62bTw==
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=fm3; bh=6sAvQF elyyPu3jRZ+Vnk9CZxdZ8qF6iY44RSIahhgQY=; b=gEeAKRji9B8lh2WmWYkZbj Im80jGae6QMzHpcqL6SBwAaxqm0T8Qa70XccN2AzSezkYBWz6wwDTP0ue184OZ/2 arRcNriq3LGyRvTaQepFqhmekqM4dxIcGBPRpRA8t370vnNOc+sw2axurMC8xDKx ke/k6tGx9oWMOZ1wZ5EywpmPYvHYEBc0UgxfSi3itJ2HAG8rdcqY/H9gSskqJeG5 a64b7KpMAeVuCKPd86GTSNKKJOo7KeyxSkLxSHFCXCfEOMFFEIIdv9gJzalMKu7o oKARCSSWBm8jlQoIwOyzCq/fVfpY/qJsj5GxTAlG4Bb8nvTMGy8fVlTFK486mrVA ==
X-ME-Sender: <xms:62EGX3Fe2BW21f5CeDsR67-XKDk4cq1DXAHe5UzQpTcfuBXLp1zmDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudekgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:62EGX0XYGwhFzhBfUt-8Ec2JVeKRv35ubr90I7LGYtJkm6EuIEPhNg> <xmx:62EGX5JrJaVpa-KQjgUkQJBnb4ThnHxGJIoUYCp8IJYP5FK_aenfxQ> <xmx:62EGX1FlD_sEio0xrlNdSy4D4-zEq2cveqCfULqVsDkDadByOD5Ppg> <xmx:62EGX8DupuPgn0ohaOhK9PfJ9qX7rNIpwSYK-1X_xMRoVqyDzkGTdw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0278EE00B3; Wed, 8 Jul 2020 20:16:43 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-601-g4bf46fa-fm-20200708.001-g4bf46fa8
Mime-Version: 1.0
Message-Id: <d9201e80-19b9-4854-9655-10935414143c@www.fastmail.com>
In-Reply-To: <CAAZdMacsDdcZCcS1yLSQwO3rbhnh8AVkgZHrt+A+KDKKaYWO7g@mail.gmail.com>
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> <CAAZdMacsDdcZCcS1yLSQwO3rbhnh8AVkgZHrt+A+KDKKaYWO7g@mail.gmail.com>
Date: Thu, 09 Jul 2020 10:16:24 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Victor Vasiliev <vasilvv@google.com>
Cc: "tls@ietf.org" <tls@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OjnmSvJ47jo5FhTV-7RpKNDEnOA>
Subject: Re: [TLS] Application-Layer Protocol Settings
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, 09 Jul 2020 00:16:47 -0000

On Thu, Jul 9, 2020, at 00:13, Victor Vasiliev wrote:
> For what it's worth, I don't think we should define a new ALPN token 
> for that; using ALPN tokens for flags will eventually lead to 
> combinatorial explosion (e.g. "if we define h2_half_rtt, we have to 
> define h2c_half_rtt", etc), and can also lead to some really unpleasant 
> situations with Alt-Svc.

I'm not so firm on that.  h2 was defined before 0-RTT, so there is no provision for carrying settings over into 0-RTT anyway, which is what would be required for thewebsocketprotocol CONNECT to work.  You propose defining extensions to TLS to address this shortcoming in addition to the synchronization issue, but what that really is is a new version of h2 - one where SETTINGS does not appear in application data (mostly, I assume that updates are OK).

This was discussed during the design of HTTP/2.  But 0-RTT was too new to decide anything at that point and the view was that anything could be negotiated in one of two ways: SETTINGS (which takes time) or a new protocol version.  It might seem a little early to be even contemplating a new version, but that wasn't the thinking at the time.

h2c is dead, so we don't need to worry about that.