Hi Nick,
I think the issues around risk have a great deal of nuance that you're
not appreciating, but which I've tried to lay out below. I appreciate
that rational reasonable people can absolutely disagree on how they
weigh up these risks, but I think we have to agree that Trust
Expressions enables websites to adopt new CA chains regardless of client
trust and even builds a centralized mechanism for doing so. It is a core
feature of the design.
On the issues around benefit, you've repeated the high level talking
points around PQ, adopting new CAs and supporting older devices, but
these talking points don't pan out on closer inspection.
The central problem is that whilst Trust Expressions introduces a
negotiation mechanism at the TLS layer, it is only moving the pain up
the stack, without actually solving anything. To actually solve these
problems, Trust Expressions envisages that either website operators are
doing a complex dance with multiple CAs to enable the universal
compatibility they already enjoy today or that new CAs are forming
business relationships with incumbent CAs, identically as they would for
a cross sign. In both cases, we're adding a lot more complexity,
fragmentation and pain, for no actual return.
A detailed response is inline below.
Best,
Dennis
On 22/05/2024 07:28, Nick Harper wrote:
The second way this could happen is that the government compels a
browser to add a CA to their root store regardless of whether it
complies with root store policy, implicitly stating that this CA will
misissue certificates. The browser's choice is to comply or leave the
market. Until this new CA is in a trust store advertised by clients,
there's no incentive for server operators to get a certificate issued
by that CA, as there are no clients for it to present that cert to.
This is incorrect. Governments have a wide range of incentives available
to them to encourage adoption by websites, including simply making it a
legal requirement. Currently, none of those incentives are strong enough
to overcome the fact that the website would become simply inoperable
without Trust Expressions.
Thus, server adoption is no factor in the government's pressure to
compel a browser to add their CA, and I see the same probability of
this being successful as in the current state of the world without
Trust Expressions.
The conclusion that server adoption has no role in government pressure
doesn't follow from any of the argument that you made and is in any
case, wrong.
Government capability to compel browsers is fundamentally one of
legitimacy. In democracies, this usually plays out in debates between
elected lawmakers who will either support or oppose new legislation
impacting browsers. Website adoption is absolutely a factor in this
debate. "A large fraction of our domestic websites have adopted our new
domestic certificates, but American browsers refuse to trust them
leaving us dependent on foreign infrastructure" is a much more powerful
argument than "we made a new CA that no one uses, pretty please can we
force browsers to trust it".
A substantial issue that you didn't pick up on is how Trust Expressions
changes government incentives to perform this kind of mass surveillance.
Whilst having your domestic root CA ship in clients does enable
surveillance, it's not especially useful when no websites use that root
CA, so targets can tell when their connection is being intercepted.
Governments therefore either have two choices: MiTM everything (a
substantial hurdle to have passed into law) or compel adoption by
websites of the domestic CA (so that MiTM certs blend in with real
ones). This latter path is substantially easier from the perspective of
lawmaking and is only possible with Trust Expressions (otherwise the
adopting sites would become inaccessible. As noted earlier in the
thread, this approach with Trust Expressions also scales nicely,
allowing many countries to do this in parallel with the website using
the domestic CA of each one.
> The real problem here is that you've
> (accidentally?) built a system that makes it much easier to adopt and
> deploy any new CA regardless of trust, rather than a system that makes
> it easier to deploy & adopt any new *trusted* CA.
I disagree that it makes it easier to adopt and deploy a new CA
*regardless of trust*. Trust Expressions only makes it easier to
deploy a CA that is in a trust store advertised by clients. If a CA is
in a client's trust store, that to me sounds like a *trusted CA*.
Without Trust Expressions, web servers are locked into one certificate
chain which needs to be widely trusted. With Trust Expressions, web
servers can add arbitrary certificate chains regardless of client trust,
and CAs are empowered to ship additional chains without the operator's
consent. This makes it much easier to deploy a new CA regardless of
trust. Neither the operator, not the client, needs to trust the new CA
cert chain for it to be provisioned.
I appreciate reasonable people can disagree on the complex interaction
between tech, policy and root stores, but this is just a factual
observation: Trust Expressions makes it easier to deploy new CAs and
does so regardless of who trusts them.
Instead, we should focus discussion on the problems that Trust
Expressions solves.
As the Web PKI transitions to PQC, there will be a long transition
time where server operators will need to support having multiple
distinct certificate chains and send the appropriate one based on
whether the client supports a PQC PKI or only classical cryptography.
There will also be experiments with different approaches on how to
build a PQC PKI. A server provisioned with multiple certificate chains
(a prerequisite for PQC PKI) needs to know which one to use with each
client. While a TLS extension could be used to identify which
approaches/algorithms/protocols the client supports, the server also
needs to know which of its certificate chains the client trusts.
As Andrei observed, such an TLS extension is already exists and is
widely supported.
There is no reason to assume that there will be a single ubiquitous
set of PQC CAs, especially during the transition period when
experiments are ongoing for different approaches for a PQC PKI. One
potential approach already being discussed is Merkle Tree Certs [8],
and that will require an as-yet unidentified alternative mechanism
when its requirements (e.g. issuance delay, client freshness) can't be
met. I'm sure there will be other ideas experimented with and
considered that explore the tradeoffs in signature vs public key sizes
as well as number of signatures in a certificate chain and
transparency requirements.
These experiments will need their own negotiation mechanisms anyway.
Trust Expressions does not help that.
Separately, I do think MTC is a compelling proposal and that the
issuance delay / client freshness issue could be addressed with some
tweaks to the design.
As CA operators start to spin up PQC CAs, different operators will do
this at different times and with different technologies. A server that
prefers to use a PQC certificate will need to know whether the client
trusts that certificate's CA. At its simplest, consider a single web
browser, a single PQC PKI technology, and two PQC CAs that get added
to its root store at different times. If the server is a customer of
the second PQC CA to get added to the root store, it needs to know
whether the client (that supports PQC PKI) has updated to the new
version of the root store. When multiple browsers are involved, this
check of "is the client fresh?" is more complicated, as different
browsers will add the second PQC CA to their root stores at different
times, and they might add CAs to their root stores in different
orders. Waiting for stability of the root stores is the same thing as
waiting for ubiquity of trusted roots.
Yet a simple cross-sign between the new PQ root key and the old non-PQ
key suffices. PQ clients with the new PQ root will have PQ security. PQ
clients without the new PQ root will consume the non-PQ signature (but
Trust Expressions doesn't help them anyway). Non-PQ clients will signal
via their signature_algorithms extension and receive the non-PQ chain.
This gets at the second instantiation of the problem: temporal trust
store divergence. There's already been a fair amount of discussion on
this thread about this [9][10], in the form of how to support older
devices. I assume I don't need to explain why this is an important
problem to solve.
Yet as acknowledged by the authors, Trust Expressions does not solve
this problem. The devices causing this problem are not likely to adopt
Trust Expressions, meaning that we'll still be doing TLS fingerprinting
indefinitely. Cross Signing does actually solve this problem.
I believe Trust Expressions is an effective solution at solving all of
these problems. I've only seen one serious alternative presented on
this thread: cross-signs with Abridged Certs [11]. You present (in
message [12]) two examples of using cross-signing to solve the
temporal trust store divergence problem. One is a CA transitioning to
new keying material. While this works for some period of time, we've
already seen that it's reached its limit [7],
Can you explain why you think cross-signing has reached its limit? As I
noted earlier, Root Stores could easily encourage cross signing if they
wanted to.
and even with Abridged Certs there's an additional cost to the client
and server storing the compression dictionary (or multiple versions of
it) and the smaller number of bytes on the wire representing the
compressed intermediate that could have been completely omitted had
Trust Expressions been used instead.
A compressed intermediate certificate in Abridged Certs occupies two
bytes on the wire. Somewhat smaller than the Trust Expressions extension
:-).
The server-side storage space required is negligible, 34 bytes per
intermediate certificate (32 byte hash, 2 byte identifier). The
client-side storage space required is 2 bytes per intermediate
certificate (since we already ship the full set of intermediates to
clients). The dictionary format has also been ordered to support
multiple versions without needing to store the redundant data. So in
short, much less than the multiple extra certificate chains that Trust
Expressions demands.
The second example is when a new CA wants to launch. The existing
mechanism requires a new entrant to the space to make a business deal
with one of its potential competitors to be able to usefully enter the
market. This sounds like a bug, not a feature, of the system.
Firstly, Trust Expressions also requires these business deals. Website
Operators need both a chain from the new CA and an existing trusted CA.
This requires either the subscriber to have a business relationship with
the existing CA, or the new CA to have a business relationship with them.
Secondly, unlike Trust Expressions, cross signing actually solves this.
Further, root store operators can encourage cross signing if they so wish.
In [12], you suggest that Trust Expressions encourages CA operators to
more slowly transition to a PQC PKI, and that this is undesirable. In
the transition to a PQC PKI, there will be experiments with different
approaches, and different CA operators may choose different approaches
to implement on different schedules. The incentive for CA operators to
move quickly instead of waiting for others to pave the way is to meet
the demand of servers that want PQC certs early.
We're not worried about the CAs at the front of the pack, who will look
to innovate no matter what. We're worried about the CAs that make up the
long tail.
Servers that use trust expressions can be more confident that they
are using a certificate chain trusted by their diverse set of clients
(and monitor which trust expressions they don't support so they can
adjust their certificate order configuration to close gaps if they
want to support those clients).
What do you mean by 'more confident'? They already know whether the
chain is accepted or not based on whether the connection goes through.
You seem to be imagining that having to maintain relationships with
multiple CAs to be present in multiple trust stores is a feature for
website operators, rather than a huge burden. Best case is that they
will do much as they do today and simply pick one CA which is
ubiquitous, so Trust Expressions doesn't help.
CA operators benefit by being able to issue certs from their new roots
sooner without needing to wait for ubiquity or having server operators
complain that they don't work.
Only by carrying out a business agreement with a more widely trusted CA,
just as they would for a cross sign.
Root programs benefit by being able to more easily make changes with
less risk of breakage (e.g. policy changes like root key lifetimes,
and breakage due to the inability for servers to provide a set of
certificates that both old and new clients can build valid paths for).
Cross Signing actually solves both of these problems as we've already
discussed. Trust Expressions does not, it relies either on CAs doing the
legwork to keep these things working (as they already do today) or
website operators to do a complex dance with multiple CAs and
fingerprinting (as they already do today).
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote:
Although Watson observed that the answer to this is at least
'somewhat', I agree such a world is already maxed at 10/10 on the
bad worlds to live in scale and so it's not by itself a major
problem in my view.
I don't see Watson saying that in any of his messages [5] [6] [7].
On 01/05/2024 00:07, Watson Ladd wrote:
I think the sharper concern is that you could block traffic without the cert
included.
Watson can of course speak for himself in this matter.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
