[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Sat, Jul 20, 2024 at 2:23 PM David Benjamin wrote: > On Sat, Jul 20, 2024, 06:13 Mike Shaver 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 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 wrote: > On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote: > >> >> >> On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara >> 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 -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Mon, Jul 22, 2024 at 8:58 AM Mike Shaver wrote: > On Sat, Jul 20, 2024 at 2:23 PM David Benjamin > wrote: > >> On Sat, Jul 20, 2024, 06:13 Mike Shaver 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
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Mon, Jul 22, 2024 at 12:52 PM David Benjamin 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 ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Mon, Jul 22, 2024 at 9:53 AM David Benjamin wrote: > > 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. > I looked up the term "dns names" in Google Chrome, through the location bar, which is not only used for DNS names. The URL I got back was this: < https://www.google.com/search?q=dns+names&oq=dns+names&gs_lcrp=EgZjaHJvbWUyCQgAEEUYORiABDIHCAEQABiABDIHCAIQABiABDIHCAMQABiABDIHCAQQABiABDIHCAUQABiABDIHCAYQABiABDIHCAcQABiABDIHCAgQABiABDIJCAkQABgKGIAE0gEIMjE1NGowajeoAgCwAgA&sourceid=chrome&ie=UTF-8 > This argument doesn't seem compelling to me, aside from the other parts of the discussion. thanks, Rob ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On 22/07/2024 09:57, Mike Shaver wrote: 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. I would like to hear from the authors (or others in the TLS implementation community) if they think Trust Expressions / Trust Anchors can be pushed into non-browser endpoints by default and the work they think would be required to achieve it? I think I see how, with substantial investment, an application like a browser could adopt these designs. I'm not sure I can see a TLS library ever being able to offer it by default. Best, Dennis ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Mon, Jul 22, 2024 at 1:36 PM Dennis Jackson wrote: > I would like to hear from the authors (or others in the TLS implementation > community) if they think Trust Expressions / Trust Anchors can be pushed > into non-browser endpoints by default and the work they think would be > required to achieve it? > > I think I see how, with substantial investment, an application like a > browser could adopt these designs. I'm not sure I can see a TLS library > ever being able to offer it by default. > Today, TLS libraries used in “general purposes” systems, like the default HTTP libraries or such for languages, have a pretty simple model of trust: list of certs, each with notBefore/notAfter/eku at best. Already that lags behind some of the nuance that web browsers use, whether Mozilla’s simple notBefore-of-issued-cert measure, or Chrome’s more complex SCT time validation. As an example, the popular Python package “certifi” provides a set of “curated” roots, which is actually the Firefox root set. When Firefox stopped trusting certificates issued by “e-commerce management” after a certain date, that package removed the root entirely, meaning that unlike with Firefox (and Chrome), all previously issued certificates were also rejected. We’re in the early days of these “bounded trust” capabilities, and I have some hope that we will settle into a small number of additional rules that are sufficient to make root distrust (or scope reduction) easier on the ecosystem. At that point, libraries like OpenSSL will need to decide if they want to be able to reflect the web PKI (as interpreted by at least one browser, anyway), in which case they will need to add these sorts of checks, and root store providers will need to configure them. Maybe we end up with a standard language for expressing them, but root stores already differ in format today without much pain, so I don’t think that’s necessary. I think that most program authors who use these “standard” TLS implementations are generally expecting to validate as a browser would, unless they take additional steps, so I see this lack as a bug in those libraries, or at least a capability that needs to be easily available in each stack ecosystem. Trust Anchor negotiation will require configuration of both sides, but so does cipher negotiation and so forth, and I think that it will be fine for a library to come with “sane, web-like” defaults, and then provide a mechanism for configuring alternative policies when desired. Whether it should be or not, especially given recent events, it’s generally easier to get a configuration change deployed than a software update. But also, even if the legacy endpoints never get a trust anchors configuration update or support, those that *do* support it can be treated appropriately without disrupting the frozen clients. This would let modern clients like browsers continue to tend to the web PKI, without the opposing force of such possible disruptions. From my experience with root programs, this would be a very welcome capability! Mike ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On 22/07/2024 11:00, Mike Shaver wrote: 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. [...] Trust Anchor negotiation will require configuration of both sides, but so does cipher negotiation and so forth, and I think that it will be fine for a library to come with “sane, web-like” defaults, and then provide a mechanism for configuring alternative policies when desired. I think reading the drafts would be really valuable. Unfortunately the necessary changes are not as simple as anything like cipher selection. For example, Trust Anchors requires the TLS Library to have access to additional DNS records, which either the application needs to provide or the TLS Library needs to fetch itself - neither seem viable by default. Both drafts also require other breaking API changes on client and server. This would let modern clients like browsers continue to tend to the web PKI, without the opposing force of such possible disruptions. From my experience with root programs, this would be a very welcome capability! I would love to hear more about these possible disruptions you feel are a factor> Speaking as someone who is involved in a root program currently, I don't understand how Trust Anchor Agility would enable anything for us - discussed at more length here [2]. Best, Dennis [2] https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On Mon, Jul 22, 2024 at 11:27:37AM -0700, Dennis Jackson wrote: > On 22/07/2024 11:00, Mike Shaver wrote: > > For example, Trust Anchors requires the TLS Library to have access to > additional DNS records, which either the application needs to provide or the > TLS Library needs to fetch itself - neither seem viable by default. Both > drafts also require other breaking API changes on client and server. Yeah, access to DNS records is very problematic. And retrying handshake is something even more problematic. I don't see TE requiring breaking API changes on client: API that lets one add a set of (pseudo) trust anchors plus TE advertisement for those should work? Server-side both require much more extensive API changes. However, I think that it is feasible to add support without breaking API changes (by extending certificate loading to support alternate issuer chains [1]). [1] Or if TLS library has reified issuers (however, I do not know any stable TLS library that does), extending those to support alternate chains. If TLS library does file parsing, one might even not need any API changes. -Ilari ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On 22/07/2024 12:28, Ilari Liusvaara wrote: I don't see TE requiring breaking API changes on client: API that lets one add a set of (pseudo) trust anchors plus TE advertisement for those should work? I agree adding a new API for T.E. which applications could opt in to would be fine. But could T.E. ever be enabled by default without breaking the existing API and requiring application changes? For example, applications which access the server certificate via a callback or after handshake completion are going to be surprised by anything non-X.509 and also likely differ in policy from the system trust store (making any use of the system root store's trust expression label by default quite troubling). Similar issues apply for where applications configure the TLS certificate validation policy in advance, ship their own root store (even if its say a copy of an existing one) or hook up a custom certificate validation library. Server-side both require much more extensive API changes. However, I think that it is feasible to add support without breaking API changes (by extending certificate loading to support alternate issuer chains). A similar picture seems to apply here. Adding a new API is fine but then needs server-side applications to opt in to using it. Otherwise overloading existing file / directory mechanisms might be possible if there's not too many fussy applications out there which are going to barf. I'm pretty pessimistic about these API issues (Hyrum's Law etc) but I haven't had much exposure to OpenSSL's APIs from the perspective of other clients / servers - so curious if you do see a way to enable it by default without changing existing applications. Best, Dennis ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
I agree adding a new API for T.E. which applications could opt in to would be fine. But could T.E. ever be enabled by default without breaking the existing API and requiring application changes? Yes it could. For example, you’d have to add meta-data identifying the ‘directory of certs’ that are typically used so that it could become a named trust store. Assume that’s a fixed filename, like “trust-store-id.txt” or something. Then when you specify that directory (e.g., via [1]) it could look for the fixed filename and send that identifying information. Of course there are many ways in OpenSSL to specify how you want to trust things, but at least you’d have a migration path. [1] https://www.openssl.org/docs/man3.0/man3/SSL_CTX_load_verify_locations.html ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
