[TLS] Re: PKI dynamics and trust anchor negotiation

Bob Beck <beck@obtuse.com> Fri, 07 February 2025 16:49 UTC

Return-Path: <beck@obtuse.com>
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 59DA4C151088 for <tls@ietfa.amsl.com>; Fri, 7 Feb 2025 08:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.829
X-Spam-Level:
X-Spam-Status: No, score=0.829 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, HELO_DYNAMIC_IPADDR=1.951, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=obtuse.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXhRW0VHcjPj for <tls@ietfa.amsl.com>; Fri, 7 Feb 2025 08:49:12 -0800 (PST)
Received: from h198-166-139-10.ptr.cidc.telus.com (h198-166-139-10.ptr.cidc.telus.com [198.166.139.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBEBC14F74A for <tls@ietf.org>; Fri, 7 Feb 2025 08:49:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obtuse.com; s=20200401; t=1738946949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9YI8owkYzrBf0nVlflxcR/DHS2AgJEpvZgCzThjW0Yc=; b=Ezez+OI9wFiI6SuBRZL1C/CbTk3eMe7d9978GcrD53rzJD6UsvkFwbgxGtDgU65pj4pWEz epGPMdOjQKXmBWeIDLOHmFwqfXSJFL28oIoyYeumVXqmXUlEti6hUExIG7nNa3DfyfOywF A895A8jhXyDyd8HStsQAxuXZVNXilYU=
Received: from smtpclient.apple (<unknown> [192.168.20.3]) by mail.obtuse.com (OpenSMTPD) with ESMTPSA id 382d23c9 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Fri, 7 Feb 2025 09:49:09 -0700 (MST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
From: Bob Beck <beck@obtuse.com>
In-Reply-To: <CADQzZqteTezp4tfC02voQ2wr1U0WY+2sBrWwEgg-s3AY2ZChnw@mail.gmail.com>
Date: Fri, 07 Feb 2025 09:48:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <31F158E1-3E1E-4DE1-842B-A9002216C5A6@obtuse.com>
References: <CAF8qwaANSCodvYKAxSJf1EFnJaXmFAfD+USCg+kRVY9eRa1zow@mail.gmail.com> <CACsn0ckxGKq2pnNrRXqyb1UtHnJHunByrEmr3o=1Y5XrWx4X0g@mail.gmail.com> <CADQzZqteTezp4tfC02voQ2wr1U0WY+2sBrWwEgg-s3AY2ZChnw@mail.gmail.com>
To: Mike Shaver <mike.shaver@gmail.com>
X-Mailer: Apple Mail (2.3776.700.51.11.1)
Message-ID-Hash: VTXID5N5JUHOGUIUVMOSZ74Z4FGBUVYW
X-Message-ID-Hash: VTXID5N5JUHOGUIUVMOSZ74Z4FGBUVYW
X-MailFrom: beck@obtuse.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Bob Beck <beck@obtuse.com>, "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: PKI dynamics and trust anchor negotiation
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sy75oJ5qL5AHrhsZw1WrX5qT3AI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>


> On Feb 7, 2025, at 7:36 AM, Mike Shaver <mike.shaver@gmail.com> wrote:
> 
> Hi Watson,
> 
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd <watsonbladd@gmail.com> wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. Servers have to explicitly act to
> support the new identifier by getting a configuration that includes
> it. Whether or not this is indirectly away as part of ACME doesn't
> really change the equation. New clients can't count on server support,
> unless they advertise an already existing value. There's been various
> ways to express deltas to try to solve this, but they all involve
> paying a penalty for deviation.
> 
> The dynamic I'm worried about most then isn't fracturing: as you point
> out there are some countervailing forces where people want easy
> support. Rather it's that we artificially drive up the price of
> picking different CAs than the dominant implementation.
> 
> I very much share the concerns you've articulated here: increased barriers to entry both for new CAs and for new clients which have different root-management policies than the existing dominant implementation, and outsized penalties for differing from a "well-known set" as might happen from having tighter requirements on CA operation over time. The opaque token seems like it could lead to the properties that you (and I) wish to avoid, but when expressing my support for the group taking up the draft, I felt that the specific identifier form for trust anchors was still mutable, and therefore that it wasn't a barrier to draft adoption.

Without even considering the issues of what the identifier is (happy to think about it post adoption), if the draft was not mutable, then what’s the point in having a call for adoption with the working group to attempt to get to a place where we can have a collaborative effort?

> 
> If I have misunderstood, and identifiers must inherently be opaque in that way for all forms of trust anchors negotiation, then I appreciate the correction!

Speaking only as one of the authors, Why on earth would I go through this adoption process if I didn’t want the working group to actually assist in making the draft better.

If a draft has to be set in stone before being adopted, I can’t see a lot of value to sending it through the working group. 

> 
> Mike
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org