[TLS]Re: TLS trust expressions and certificate_authorities

Dennis Jackson <ietf@dennis-jackson.uk> Tue, 11 June 2024 10:25 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 D8314C1519AA for <tls@ietfa.amsl.com>; Tue, 11 Jun 2024 03:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Bq4lngTws0ox for <tls@ietfa.amsl.com>; Tue, 11 Jun 2024 03:25:32 -0700 (PDT)
Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480BBC15152F for <tls@ietf.org>; Tue, 11 Jun 2024 03:25:30 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (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-103.mailbox.org (Postfix) with ESMTPS id 4Vz4Yy04vBz9sdM for <tls@ietf.org>; Tue, 11 Jun 2024 12:25:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1718101526; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MVVfzmoP0wvhM09Y90ey5aqjNgm7zVWcnOKo/YICw5U=; b=shOJwGbi/aPNz5JeVcpMT1RakpvBJ1tDvkofhdVHsmT9CfQRMho9BXLkWv4lULs6Hwy1As JnIkh1LueGy4Hu9YTorqPAECKHdErbsNjI++1eZU6RPI+39y/7MufZz+SyfX42UhsiM3ml WdbenYkLXy3SB4O1bfJE8N3Udm7Enq8INYhLyhPBaKsA7F5Hh6PCd+7ZrBlwEA+C1fL10u YxnVgWnf3+FZp+GzEJ8zu9AkrOkvItHuRBWHApfIn5JO2Kkxs8zYnly4R2X0Xwr5VHqXX5 Hxjm93uyqYVJzL7llZhQJXkvJwkwkFvkifwOt4PxTZpwkAfDXSuhicXYZAkxYg==
Content-Type: multipart/alternative; boundary="------------vlKYrgwNdNTWuhvjHHZUzSoV"
Message-ID: <6cfcb94b-4796-4f8c-bc51-bc94b41012f1@dennis-jackson.uk>
Date: Tue, 11 Jun 2024 11:25:24 +0100
MIME-Version: 1.0
From: Dennis Jackson <ietf@dennis-jackson.uk>
To: tls@ietf.org
References: <CAD2nvsS+75evXbaPqO55++a7qm1sUZ8JSpCvJNXwne-w9K3MTw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAD2nvsS+75evXbaPqO55++a7qm1sUZ8JSpCvJNXwne-w9K3MTw@mail.gmail.com>
Message-ID-Hash: 3GGPD3Y3MVT2HMOKJ2N6WKMYQRQVQNFU
X-Message-ID-Hash: 3GGPD3Y3MVT2HMOKJ2N6WKMYQRQVQNFU
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.9rc4
Precedence: list
Subject: [TLS]Re: TLS trust expressions and certificate_authorities
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/28O-XW3fM1TlbqIMNelYlxDePbY>
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>

Hi Devon,

I'm a bit disappointed in how you've characterized the earlier 
discussion, but I appreciate the attempt to move the conversation on to 
new technical ground. I previously started a thread on the problems with 
the proposed uses of Trust Expressions for PQC-transition [1] in a 
similar effort to move the conversation on. It would be good to see a 
response from the TE authors to that thread.

> Focusing on the actual draft text, the TLS trust expressions extension 
> does not represent any kind of major paradigm shift, primarily due to 
> its strong similarity to the existing certificate_authorities TLS 
> extension.
>
> [...]
>
> There is no fundamental capability offered by trust expressions that 
> isn’t already available by certificate_authorities.

I think the above captures the main thrust of your argument in this 
thread, but it seems like quite a flawed analysis. If T.E. does not 
offer any new capabilities over certificate_authorities, then there is 
no point in standardizing it at all. Conversely, arguments that T.E. is 
a much more effective mechanism for deploying trust negotiation than 
certificate_authorities undermines the claim that T.E. doesn't introduce 
new risks that merit discussion.

In terms of the differences between the existing certificate_authorities 
extension and Trust Expressions, I want to enumerate a few:

Firstly, certificate_authorities is impractical at any kind of scale 
because it requires listing the distinguished name of every CA in the 
ClientHello (as you noted). This makes the size blowup is a huge 
impediment to actually using it for anything other than in a private PKI 
setting e.g. for indicating which client_certs a server would like to see.

Secondly, certificate_authorities is very poorly supported today. TLS 
libraries typically ignore it e.g. OpenSSL requires custom callbacks to 
integrate it [2] - I couldn't find anything actually calling this 
function. Neither BoringSSL nor NSS support it in ClientHellos as far as 
can tell.

Thirdly, certificate_authorities doesn't have any of the machinery 
necessary to orchestrate deploying it. Trust Expressions envisions ACME 
/ TLS Servers implementations and CAs cooperating to distribute these 
trust labels to subscribers without requiring them to do any 
configuration themselves.

Trust Expressions proposes to solve all of these drawbacks with 
certificate_authorities. The first is achieved by replacing the long 
list of distinguished names with a single identifier. The second is to 
ship support across servers and clients and make sure it is well 
exercised and indeed required. The third is to ensure that CAs can 
deliver multiple certificate chains to clients and that clients can 
transparently select between them based on a trust label.

Consequently, T.E. does meaningfully change the calculus over 
certificate_authorities and so there are number of active threads 
discussing the risks of enabling trust negotiation and evaluating how it 
can be abused.

Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/b_S23Rk0yvleoT3D0BGUTYFut80/

[2] https://github.com/openssl/openssl/issues/13453

On 11/06/2024 02:24, Devon O'Brien wrote:
>
> Hello,
>
>
> I realize there has been extensive discussion about trust expressions 
> and a variety of hypothetical scenarios that some believe will play 
> out should this draft get adopted and implemented. I would like to 
> start this out with a clear statement: we hear these criticisms and 
> are paying very close attention to them in order to help ensure this 
> working group does not ship an irresponsible standard that causes any 
> of the possible doomsday scenarios sketched out. The crux of this 
> disagreement isn’t whether the outlined hypotheticals are bad; we are 
> in strong agreement on this point. Rather, the disagreement is about 
> the causality being posited between a rather incremental extension 
> mechanism and these outcomes. Here, we authors strongly disagree with 
> the points that have been repeatedly mentioned by some working group 
> members and I hope that a more careful analysis of what trust 
> expressions actually provide over the status quo will help the working 
> group work past these disagreements.
>
>
> I believe that, in our excitement at the opportunities that a more 
> agile web PKI can provide, we did ourselves and the broader community 
> a disservice by leaning too far into some of the far-reaching 
> possibilities we envision from a world with trust expressions. While 
> we remain excited about a more agile and less-ossified PKI, it’s now 
> clear that such emphasis caused the conversation to shift dramatically 
> away from what the draft actually says and towards a variety of 
> opinion-based arguments about what laws may be written by various 
> world governments in the coming years and decades.
>
>
> Focusing on the actual draft text, the TLS trust expressions extension 
> does not represent any kind of major paradigm shift, primarily due to 
> its strong similarity to the existing certificate_authorities TLS 
> extension. The difference between these extensions exists not in what 
> information is being communicated, but rather, how concisely it’s 
> being communicated. RFC 8446 defines the certificate_authorities 
> extension as follows: “The "certificate_authorities" extension is used 
> to indicate the certificate authorities (CAs) which an endpoint 
> supports and which SHOULD be used by the receiving endpoint to guide 
> certificate selection.”
>
>
> In practice, this means:
>
>  *
>
>     The supported certificate authorities are communicated by sending
>     a list of DER-encoded distinguished names in the ClientHello and
>     CertificateRequest messages
>
>  *
>
>     Subscribers match this set of distinguished names against their
>     provisioned certificates and select one to serve
>
>  *
>
>     If no matching certificate exists, subscribers rely on some
>     fallback heuristic for selection
>
>
> To more accurately describe what TLS trust expressions does and 
> doesn’t do, I would like to discuss it in terms of its similarities 
> and differences to certificate_authorities. Defined within trust 
> expressions is:
>
> 1.
>
>     A labeling and compression mechanism for the
>     certificate_authorities TLS extension, also sent in the
>     ClientHello and CertificateRequest messages, so that relying
>     parties can more efficiently communicate this information to
>     subscribers. With certificate_authorities, this is a list of trust
>     anchor distinguished names.
>
> 2.
>
>     A means of distributing this label information to subscribers so
>     that they can extract trust anchor information from the
>     aforementioned labels. With certificate_authorities, the labels
>     are contained within the certificates themselves.
>
> 3.
>
>     An algorithm for subscribers to match labels against a set of
>     pre-provisioned TLS certificate paths. With
>     certificate_authorities, this is a direct string match of listed
>     distinguished names which must be searched for among provisioned
>     certificates.
>
> 4.
>
>     A mechanism to account for changes in trust between when
>     subscribers obtain this information (certificate issuance) and
>     when they evaluate a label (a TLS connection). This isn’t defined
>     in certification_authorities because it’s not needed for the
>     direct name matching used therein.
>
>
> There is no fundamental capability offered by trust expressions that 
> isn’t already available by certificate_authorities. When compared to 
> certificate_authorities, the primary obstacle being addressed by trust 
> expressions is the size of the message sent in (1). X.501 
> distinguished names are notoriously verbose, and modern trust stores 
> contain hundreds of trust anchors, rendering it infeasible for relying 
> parties to dedicate tens of thousands of bytes in a TLS handshake to 
> listing trust anchors. Notably, parties that may wish for clients to 
> signal a specific mandated CA can do so efficiently with 
> certificate_authorities today, as this requires sending only a single 
> distinguished name.
>
>
> Compressing a set of trust anchor names can be done in a variety of 
> ways, but trust expressions does so by applying a label and version 
> scheme to trust stores (3), which are an existing and recognized 
> collection of trust anchors that are also already relying party specific.
>
>
> The majority of complexity in trust expressions comes from (4). This 
> complexity is a result of design choices made by the authors, but is 
> also something that can change based on working group feedback and 
> participation. We are far more committed to creating a usable 
> mechanism for communicating supported trust anchors than we are any 
> specific design choice.
>
>
> Critically, neither trust expressions nor certificate_authorities 
> change what trust anchors are trusted by any relying party, whether 
> they support these mechanisms or not. Discussion about whether some 
> root program may be pressured to accept national trust anchors that do 
> not meet existing standards is a critically important security policy 
> topic, but is fundamentally orthogonal to this mechanism. Drawing 
> causality between trust expressions and this outcome (especially 
> ignoring the existing surface already provided by 
> certificate_authorities) may be well-intentioned, but is misplaced.
>
>
> And lastly, to address some accurate critical feedback we’ve received, 
> trust expressions do not “enable” a multi-certificate model. Today, 
> web servers have a variety of options available to them to serve 
> multiple TLS certificates, including fingerprinting TLS connections 
> and the aforementioned certificate_authorities extension. Trust 
> expressions do, however, offer some improvements by making trust 
> signals both explicit and relatively concise. Language on this topic 
> will be softened throughout our explainer and draft text.
>
>
> -Devon
>
>
>
> _______________________________________________
> TLS mailing list --tls@ietf.org
> To unsubscribe send an email totls-leave@ietf.org