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

[Mike Shaver <[e-mail]>]

On Mon, Jul 22, 2024 at 12:52 PM David Benjamin <[e-mail]>
wrote:

> I say sometimes because this is not always viable. It's a more indirect
> way of addressing the root issue, so there are some limitations. First,
> this requires foresight on the part of the service operator and client
> vendor. If everyone knew ahead of time that the client might diverge (e.g.
> by way of standing still while the ecosystem moves), then one might set
> this up. But this is a perennial problem *because* people empirically do
> not know ahead of time. Or perhaps the vendor even intended to continue
> servicing their IoT devices, went out of business, but enough folks bought
> them and continue to happily use them that some other service provider does
> not wish to abandon them.
>
> We can try to help this by encouraging such foresight as best practice,
> but it takes just one important client of one important server to gum up
> the works. Trust anchor negotiation, if successful, provides a solution
> that doesn't require as much deployment-level foresight. (If the IoT device
> can negotiate trust anchors, it's easy. If it can't, the clients that *do* negotiate
> trust anchors can still evolve freely and do not add to the PKI
> intersection problem.)
>

Yep, I absolutely look forward to a web where we have this sort of
capability, either on endpoints themselves or even managed by a more-modern
intermediary. I’m not informed enough to comment on the protocol elements
of the specific Trust Anchor proposal, but I agree that more PKI agility
will be healthy.

Fundamentally, the TLS implementation community will be pushing this
agility into endpoints by default, which means that it would take active
divergence by a system implementor to create the sort of TBTF systems that
impede trust changes today.

Mike