Re: [TLS] Authenticating incompatible protocols

Martin Thomson <mt@lowentropy.net> Wed, 15 July 2020 06:25 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 A76A73A0978 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 23:25:30 -0700 (PDT)
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=LqYbeHKj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cenhDYki
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 t7DhEboGYIVj for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 23:25:29 -0700 (PDT)
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 618043A0972 for <tls@ietf.org>; Tue, 14 Jul 2020 23:25:29 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AAF4D5C0190; Wed, 15 Jul 2020 02:25:28 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 02:25:28 -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=Ew5GkAluwEa/YXjm/m+AHtdRRgjq R9cvyky41080XoQ=; b=LqYbeHKjfwtMh3YrTzOg3RaiiFuhFlkBuANcPjX3sN/N D8IwMCLsIlsXJvIi0wb0O1gw16/UTbbuL6Gi6DArG5LhDLhTVV5iO1F6qXd5gegs zvaj/jl28NwZIfm7eLg7WB/wPWJHmt293No3mk/kkMYT4lxQlIfDEVsNILqsp4UM sqaYbR08+q/afZxPJRSZgdGcm7OiwifCoU2XNwtbQpdKeVv3/+497wYDDA0MQNUV zJxhzyq1CpvjnzQPUHp41nI0UyUBV1F2BlHh5GvAjV8S4SA0mRGVf2uknQXri3jE LH5YEnJEx8TJcgxKuHns01YpDF0JpsBoacwyxNagSA==
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=Ew5GkA luwEa/YXjm/m+AHtdRRgjqR9cvyky41080XoQ=; b=cenhDYkinJUi+z3D23Fnm6 klUmgy/wZ9UjiQzxcFDL6NmTssmGwZCBWi9yCcE4mReKaju99WvzCSXz2Cr1Y2Uu GXidZKIn5ImqDSN3303Ims5mR3FaGNjgwoAXG3p/MfpDP6LLHBpwA1UsYdLHXNLL 8IBTMJYzGVnjDFHYsQrCbScju3j/JFgHnLI+RxdHtcy4jopN1wP7Pvo91CD7yc61 rHWpdutQc4xweZm6lhx9wWBlkj/z/xH41xQ53iAkro36C0EgqbFUdLiudNWWk6yR nugMYJrMvxvCy4uyXtqeKgRrcSFqEEOOwGqonchB9O8b71DrCDKpf8chIGO86tiA ==
X-ME-Sender: <xms:WKEOX8mFW23xYwagS7mLvTzjtbnt7dXxxqsp1fjacfnQDsyDQxZiGA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:WKEOX72obLVp5-VeO8Y36YmZeIb8uX1xw4-cmz9468O0Qu9quhQnDw> <xmx:WKEOX6r-eUrDkCcYuBm46IcqrSUIQGY4qWFAtntSs4PwVg0BQQjGMw> <xmx:WKEOX4mWWcaPLurHuRE1HS75EgX__EO3NLYKGZFe4BQHsPURLjrFxQ> <xmx:WKEOX7CAQapqITB4ZXN5xiUsHOQaCug75EmfHQlNTxLnW8DirsGC4w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 617DCE00C1; Wed, 15 Jul 2020 02:25:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <cad8c7a8-a6ea-4547-b3fb-ca6ef74fc41b@www.fastmail.com>
In-Reply-To: <CAHbrMsApdYkqNPGyi7iJaYHQBNr3P2g4zkC4asPuxkgzmJ-2KQ@mail.gmail.com>
References: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> <CAHbrMsApdYkqNPGyi7iJaYHQBNr3P2g4zkC4asPuxkgzmJ-2KQ@mail.gmail.com>
Date: Wed, 15 Jul 2020 16:25:08 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Ben Schwartz <bemasc@google.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ht9W0dAAUlEHgU84vycNlhEZ5M0>
Subject: Re: [TLS] Authenticating incompatible protocols
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: Wed, 15 Jul 2020 06:25:31 -0000

On Wed, Jul 15, 2020, at 08:53, Ben Schwartz wrote:
> For ease of deployment, I wonder whether the concept of a "scope" needs 
> to be pinned down a bit more precisely.  In 00 here, the scope is 
> entirely implicit; servers are required to know how users might have 
> found them, and what other servers they also might have found at the 
> same time.  

I don't think that it is that bad.  It is more that server operators need to understand that the ways in which they advertise the availability of their service interacts with what is deployed.  That is, you need to configure discovery methods and your TLS stacks with the same information (though your TLS configuration can be more conservative in terms of advertising a subset of what can be discovered, so that deployments can be staged).

Right now, that means that if you use SVCB, you should configure your TLS stack to authenticate that.  This might eventually include QUIC versions as well - once that is sorted out - but that won't require the same sort of coordination.

The problem with more detailed indications is that it requires far more configuration.  The TLS stack doesn't just need to know that FOO is available, it needs to know where.  As that is usually the business of the DNS provisioning more than the TLS configuration, I'm concerned that you would get out of sync too easily.