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

[Devon O'Brien <[e-mail]>]

> 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).
>

This is indeed the exact motivation behind us proposing solutions to
address the broader use case of trust anchor negotiation in TLS.


The primary purpose of trust anchor negotiation is the same as the broader
TLS parameter negotiation problem: allowing client and server to agree on a
mutually-satisfiable decision when configurations differ, but overlap.
Additionally, in a world in which trust anchor negotiation exists, there is
the possibility of improving upon existing TLS PKI pain points exacerbated
by its absence.


There are existing solutions that address a subset of these pain points.
Combining these together risks increasing complexity beyond a single more
complex solution and introduces possible undefined behavior, unexpected
failure modes, etc.


There are also solutions that are theoretically capable of solving the
broader problem, but with barriers to viable deployment (such as
certificate_authorities).


I am deeply sensitive to the pitfall of adding extensibility for
extensibility's sake and feel that the complexity of TE and TAI are a
result of different tradeoffs, of which the WG may prefer one over the
other. As David Benjamin noted, TE pushed complexity away from TLS clients
and servers and towards root programs and CAs, which are both fewer, and
have a well-formed existing relationship. TAI, on the other hand, is able
to be more simply specified at the cost of adding additional dependencies,
such as maintaining fresh and accurate DNS records.


On the whole, we hope the WG will review both proposals and let us know
which set of tradeoffs we collectively prefer so that we can standardize
and deploy a viable negotiation mechanism.


-Devon