On Tue, Apr 30, 2024 at 4:30 PM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote:
> 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> > <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'. > > Wouldn't we also get this last point as a sort of side effect of abridged certs? -Ekr > - 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
