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

[Mike Shaver <[e-mail]>]

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.

On Sun, Jul 21, 2024 at 7:05 PM Dennis Jackson <ietf=
[e-mail]> wrote:

> We've seen a number of recent incidents where CAs have delayed revocation
> of mis-issued certificates for 'critical' services that are not accessible
> on the public web [1]. The vast majority of these services could already
> migrate to a private PKI today but they simply don't have adequate
> incentives to make the small investment necessary. How would Trust
> Expressions or Trust Anchors change that?
>
TA, once deployed, could well possibly make it easier to migrate or manage
such systems, but I don't think it's reasonable to expect that any protocol
change will provide sufficient "incentive" for the operator of such a
system to bear the costs of operating a PKI when they could instead push
those costs to the stewards of the web PKI instead. It's not a reasonable
standard against which to evaluate a protocol element, IMO.

Mike


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:
>
>>
>>
>> On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara <[e-mail]>
>> wrote:
>>
>>> 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.
>>
>>
>> I agree with your second sentence very much, but I don’t understand your
>> first one. In what way are these non-web systems not allowed to use other
>> PKI models today? How would trust anchors provide that permission?
>>
>> Mike
>>
>
> 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.
>
> David
>
>
>
> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>