[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
- [TLS] PKI dynamics and trust anchor negotiation David Benjamin
- [TLS] Re: PKI dynamics and trust anchor negotiati… Salz, Rich
- [TLS] Re: PKI dynamics and trust anchor negotiati… David Benjamin
- [TLS] Re: PKI dynamics and trust anchor negotiati… Watson Ladd
- [TLS] Re: PKI dynamics and trust anchor negotiati… Mike Shaver
- [TLS] Re: PKI dynamics and trust anchor negotiati… Dennis Jackson
- [TLS] Re: PKI dynamics and trust anchor negotiati… Bob Beck
- [TLS] Re: PKI dynamics and trust anchor negotiati… David Benjamin
- [TLS] Re: PKI dynamics and trust anchor negotiati… David Benjamin
- [TLS] Re: PKI dynamics and trust anchor negotiati… Watson Ladd
- [TLS] Re: PKI dynamics and trust anchor negotiati… Bas Westerbaan
- [TLS] Re: PKI dynamics and trust anchor negotiati… David Adrian
- [TLS] Re: PKI dynamics and trust anchor negotiati… Watson Ladd
- [TLS] Re: PKI dynamics and trust anchor negotiati… David Benjamin