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

[David Benjamin <[e-mail]>]

On Mon, Jul 22, 2024 at 8:58 AM Mike Shaver <[e-mail]> wrote:

> On Sat, Jul 20, 2024 at 2:23 PM David Benjamin <[e-mail]>
> wrote:
>
>> On Sat, Jul 20, 2024, 06:13 Mike Shaver <[e-mail]> wrote:
>>
>>>  In what way are these non-web systems not allowed to use other PKI
>>> models today? How would trust anchors provide that permission?
>>>
>>
>> If the same server serves both embedded/IoT traffic and web browser
>> traffic, but we aim for the two to use different PKIs, the server needs to
>> arrange to serve different certificates to each. To do that, we need trust
>> anchor negotiation story.
>>
>
> If there is no extra-TLS means of distinguishing those cases, such as port
> or IP addresses for endpoints, then today such a system can use SNI, which
> is basically a very simple trust selection story. It is less flexible, but
> for selecting between disjoint PKIs in which to orient a given connection,
> it seems that it would suffice.
>
> PayPal and Netflix semi-famously rolled out SNI at moderate pain to
> accommodate a pretty similar situation when browsers and their IOT/etc
> devices no longer had trusted roots in common. I am not against TAs as a
> more flexible way to negotiate the PKI properties that the participants
> want to use for their connection, but I think it's counterproductive to the
> health of the web PKI to spread the idea that TA is *required* for systems
> to migrate to non-web PKI, even if they indeed need to keep using the same
> endpoints for some reason. Having those systems that are inappropriately
> using web PKI today justify further such misuse by saying that they are
> waiting for all their systems to support TA would be pretty unfortunate. I
> think that practically the process of managing and deploying new roots and
> certificates for a private PKI will make "change the hostname or port used"
> a small additional matter.
>
> To be clear, I think that TA will make it easier to resolve such misuses,
> and that this is a virtue of the proposal. I just really don't like the
> idea that it's not possible today.
>

Ah yes, I was speaking in the context of a single.service (i.e. one DNS
name), but you're absolutely right that one can sometimes send different
clients to different services instead.

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

Second, it assumes that the non-web PKI client does not care about the DNS
name used. When DNS names are purely internal routing labels for API
endpoints, etc., the exact DNS name used is not particularly significant.
But when they are user-visible, e.g. in the UI of a web browser,
redirecting to client-specific services isn't viable. In those situations,
we similarly would need a different solution.

We discuss this a bit in
https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md#client-specific-dns-names
as well.

But, absolutely, if some other solution is easier for some deployment at
the moment, by all means go for it.

David