[TLS] Re: PKI dynamics and trust anchor negotiation

[Watson Ladd <[e-mail]>]

Dear David,

I have to start by apologizing. It's not until now on reading your
email that I've come to the realization of what the issues were with
at least the early negotiation proposals in a way that makes them
clearly articulateable, and I think earlier on it would have been more
fruitful for me to have realized them. I've also not necessarily fully
digested the latest proposal.

If we were to have used certificate_authorities to negotiate, every
client would be sending a list of all the authorities it recognized,
servers would intersect them with what they had, and sending back the
result or an error if there were none, perhaps with some indicative
information of what they had on hand. In this world a new client would
be just as able to send such a list as any other, and servers could
recognize shifts in support and change the set of CAs they use
accordingly. There would be no additional mechanism inflected penalty:
if server A and client B can connect, they are able to determine this
fact, regardless of whatever deviations from commonality each one has
in their contribution.

A negotiation where what is advertised is an inherently opaque
pointer, and where each side must maintain an idea of what that could
mean, does not have this property. Servers have to explicitly act to
support the new identifier by getting a configuration that includes
it. Whether or not this is indirectly away as part of ACME doesn't
really change the equation. New clients can't count on server support,
unless they advertise an already existing value. There's been various
ways to express deltas to try to solve this, but they all involve
paying a penalty for deviation.

We've been through this before with the web platform looking more at
feature detection than painful UserAgent sniffing as browsers keep
telling all sorts of lies on top of lies.

There's also the fact that we've gone back and forth about how to
negotiate parameters, regrouping the possible dimensions a few times
and in different directions. We also have to deal with OS stores; this
bit us with TLS 1.2 where the set of supported algorithms had to split
out leafs from the rest of the chain since different implementations
could be used. I'm not sure that starting off with a tight coupling of
a bunch of dimensions is the right idea, but don't feel as strongly
about that.

The dynamic I'm worried about most then isn't fracturing: as you point
out there are some countervailing forces where people want easy
support. Rather it's that we artificially drive up the price of
picking different CAs than the dominant implementation.

Sincerely,
Watson