On 01/05/2024 00:07, Watson Ladd wrote:
On Tue, Apr 30, 2024 at 3:26 PM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote:
<snip>
Let's assuming for a moment we could a) get most of the world to use ACME (a
worthy but challenging goal) and b) get them to configure multiple CAs and
receive multiple certificates. We don't need trust expressions to be able to do
quick rotations - because we don't ever want to use the old CA. It's just a
case of swapping to the new one. There's no need for negotiation.
We've already seen a serious problem with cross-signing happen, where
Cloudflare is planning to stop using Lets Encrypt. That's because the
cross-signed cert that let Lets Encrypt work with old Android devices
expired, with no replacement. Having websites present one chain
creates a lot of thorny tradeoffs. Either you present a cross-signed
certificate, or a few, and take the bandwidth hit, or you don't and
suffer a compatibility hit. This was manageable when signatures were
small. When they get chonky it will be much less fun.
There's a huge and unexplored design space here that does not require
trust negotiation. I don't claim any of these ideas are optimal:
* Techniques like abridged certs + cross signs let you mitigate any
bandwidth impact for recent-ish clients. Given the older clients are
going to be missing a lot of performance improvements anyway, this
doesn't seem unacceptable.
* Root Programs could introduce specific root certs they operate for
the sole purpose of cross-signing new CAs to speed up their adoption.
* Clients could have a TLS flag 'My Root Store is very old' which is
set when X years without a root store update have passed.
Alternatively, they advertise an explicit age for their root store
or the TLS Flag 'My Root Store was updated in the past year'.
* I think there may also be some interesting ways to improve Merkle
Tree Certs to support these use cases without needing trust
negotiation but that'll have to wait for another thread.
As far as I'm aware there is no need for cooperation in creating a
cross-signed intermediate: it's a certificate with a public key and
just a different signer. So Country X could force its sites to include
that cross-signed intermediate in the grab bag handed to browsers, and
everything would work as now. Browsers have to tolerate all sorts of
slop there anyway. I think the sharper concern is that you could block
traffic without the cert included.
Sincerely,
Watson Ladd
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
