[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Ilari Liusvaara <[e-mail]>]

On Fri, Jul 19, 2024 at 09:39:32PM -0700, Watson Ladd wrote:
> On Fri, Jul 19, 2024, 8:58 PM Salz, Rich
> <rsalz=[e-mail]> wrote:
> >
> > I’m a little skeptical of approaches that solve an entire problem
> > space with one architecture. I’m more skeptical of enough people
> > having the ability to read and understand the semantics of
> > several pages of JSON object descriptions. 

The TLS endpoints will not see that JSON. Good thing, as JSON is too
complex for TLS (even CBOR would be too complex).


> > Can we simplify things and solve just one problem?
> 
> Do that several times and you end up with the mess we have now, where
> the interplay of certificate serving and algorithm selection requires
> quite a dance to figure out, and is version dependent. Each additional
> factor to negotiate has to play in, and already assembling all the
> bits gets complicated.

Yes, if one drops usecases that are valuable to simplify stuff, later
adding mechanism for those usecases ends up more complex than if one
had just gone with the originally more complex solution.

And it might be worse than just supporting both: The features could
interact in bad ways. For example of bad interaction, certificate
compression versus certificate extensions.

But on the other side there is excessive complexity from trying to solve
too much (e.g, certificate policies). Or worse, complexity that does not
serve any actual purpose (e.g., differing representations of IDNs in
email certificates).


> On top of that if we want the CA ecosystem to evolve, we have to deal
> with different clients trusting different things. And there are not a
> whole lot of ways to solve that. Using that mechanism to say "here is
> the bundle of stuff I expect" is much cleaner.

Allowing various embedded and IoT stuff to migrate off of WebPKI would
be of immense value. Such stuff using WebPKI has been source of gigantic
amount of pain.




-Ilari