[TLS] Re: PKI dynamics and trust anchor negotiation

Dennis Jackson <ietf@dennis-jackson.uk> Fri, 07 February 2025 15:31 UTC

Return-Path: <ietf@dennis-jackson.uk>
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 26933C20C8E5 for <tls@ietfa.amsl.com>; Fri, 7 Feb 2025 07:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk
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 KYzkzpUtvJoN for <tls@ietfa.amsl.com>; Fri, 7 Feb 2025 07:31:14 -0800 (PST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (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 DD171C35F2D3 for <tls@ietf.org>; Fri, 7 Feb 2025 07:30:30 -0800 (PST)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4YqHwc5lvHz9spD for <tls@ietf.org>; Fri, 7 Feb 2025 16:30:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1738942224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1pahN0uKgY/i5+dQLXnboSgbnX9baEkndTgJKsv9f7k=; b=hoWJ9DR4aCZO2OIRlT8cfJK6xBiPS+++3gE8P4gw+bSqsMj4wh3fdVlKtmnCjpCMBki5dD 9yJZhBw9omqFxTBpxyEMtZWDX0tPY0Z5hwU9zug+1zZCg9ifSeryC2ChPLp3t/t6ZWYbAB EhSZPgS+jCCw35+MKG5y3kOusOsSHndeLX9R4e/3F3NwIl2AyPhFGOhSl5FbogwdWthQSs vJEV17bQs6Rzg4/KU4EbEHuUj8FQKpRtBTuF/UNTTkB5Jt95ZU9Q8UNGlHIR8cGNd99xWb Oinkp+N7Wqizr+vKzF/ht+XCc/zJM5xZ3WY5+Qj+1wPOPH8c420V51a93ys52g==
Message-ID: <eeab54e1-2b83-4609-9b76-32bf8adbad9c@dennis-jackson.uk>
Date: Fri, 07 Feb 2025 15:30:23 +0000
MIME-Version: 1.0
References: <CAF8qwaANSCodvYKAxSJf1EFnJaXmFAfD+USCg+kRVY9eRa1zow@mail.gmail.com>
Content-Language: en-US
From: Dennis Jackson <ietf@dennis-jackson.uk>
To: TLS List <tls@ietf.org>
In-Reply-To: <CAF8qwaANSCodvYKAxSJf1EFnJaXmFAfD+USCg+kRVY9eRa1zow@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: QLGEWQTLDE664BVQB6K5LGRUCHOEKUOI
X-Message-ID-Hash: QLGEWQTLDE664BVQB6K5LGRUCHOEKUOI
X-MailFrom: ietf@dennis-jackson.uk
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
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/xKUPW87NiCMyxjD2unCuh9REEos>
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>

I don't think there's any new argument to address, so I will just offer 
a pointers into where these issues are discussed in 'Trust is 
non-negotiable'.

Section 3.3 [1] looks at how trust negotiation (as an abstract 
mechanism) changes incentives to divergence for existing root programs, 
as well as the consequences of enabling the deployment of new root 
programs with divergent policies. Unfortunately, fragmentation is often 
an insidious, gradual process that arises from many actors making 
independent decisions that prioritize their own needs, in the absence of 
any ecosystem forces strong enough to bring them together. It doesn't 
have to be a goal that is pursued deliberately, although it can also be 
(e.g. market differentiation or enshittification).

Separately, structural barriers to deployment of a new technology, which 
impact certain constituencies much more than others, are a common cause 
of ecosystem fragmentation. The specific design of TAI has serious 
issues in this regard which are laid out in section 4.6 [2].

The argument that this fragmentation is possible with existing 
mechanisms like certificate_authorities is evaluated at the end of the 
section 3.3 [3]. These extensions do not have any meaningful 
existence in the wild for the purposes of server certificate negotiation 
and it's running code that counts here. Further, for the same reasons 
that the TAI authors identified these extensions as an unsatisfactory 
solution for their needs, it is unsuitable for anyone else trying to 
deploy trust negotiation at scale.

Finally, as is discussed throughout Section 3, I disagree there is any 
security tradeoff at the heart of this issue. We've shipped many many 
improvements over the past 10+ years through the steady ratcheting of 
root program policies. Instead, I believe barriers to further 
improvements are predominantly found server-side, in the level of 
investment that server operators (and to a lesser extent CAs) are 
willing to make in terms of libraries, automation and tooling. Trust 
negotiation does nothing to address these issues, which are largely 
societal rather than technical.

Best,
Dennis

[1] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-3.3

[2] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-4.6

[3] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#name-alternative-paths-to-abuse