On Mon, Jul 22, 2024 at 8:58 AM Mike Shaver <mike.sha...@gmail.com> wrote:
> On Sat, Jul 20, 2024 at 2:23 PM David Benjamin <david...@chromium.org> > wrote: > >> On Sat, Jul 20, 2024, 06:13 Mike Shaver <mike.sha...@gmail.com> 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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
