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-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
