[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
On 22/07/2024 16:06, Salz, Rich wrote: 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. I agree that having a library like OpenSSL auto-discover the necessary metadata in the system root store is definitely possible. My concern is about breakage with the other parts of the API exposed to applications which will prevent T.E. from being able to be offered by default - meaning applications will have to opt-in via a new API. The Trust Expression's extension is trying to convey accurate information about which certificates are acceptable (which is controlled by the application) and may change the certificate which is received (which is visible to the application). So I don't see how Trust Expression's could be enabled by default without breaking applications or the semantics of the Trust Expression's extension. Some examples: * Some applications will set their own certificate verification callback (SSL_CTX_set_cert_verify_callback). A Trust Expression's label cannot be sent with these connections because OpenSSL doesn't know what the policy is going to be that the application applies. Sending the T.E. label is informing the serve 'I will accept any certificate suitable for this root store'. * Some applications will use the default certificate verifier in OpenSSL, but then access the certificate chain via SSL_get_peer_cert_chain or similar functions for getting specific metadata. The application might then do further checks which OpenSSL is unaware of. If so, the Trust Expression's label from the system store cannot be used without making the label inaccurate. * Some applications will do use the default checks on the certificate, but access the certificate chain to consume / log / display the information elsewhere. It's likely these functions are going to expect a 'normal' X.509 cert chain but one of the use cases of Trust Expressions is to enable non-X509 certificate payloads or shorter chains. I think the second and third cases are particularly critical. OpenSSL cannot know during the handshake whether the application is going to later call SSL_get_peer_cert_chain / SSL_get_peer_certificate and then make a decision about whether to tear down the connection. For example, the application may do its own pinning and check whether the issuer is acceptable. In this case, if OpenSSL sent the Trust Expression extension with the label by default, it would be actively harmful, since the Trust Expression extension is telling the server "I will accept any cert valid in this root store" but in actuality the application is performing pinning. This would make the extension useless for the proposed use cases around handling pinning gracefully and giving server's confidence to migrate CAs. So my conclusion is that TLS libraries are never going to be able to offer T.E. by default. Instead applications would have to opt in, which seems like a major barrier to adoption outside of browsers. Happy to be corrected if there are some wrinkles here, but Hyrum's law seems pretty harsh for the existing TLS library APIs. Best, Dennis ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]I-D Action: draft-ietf-tls-svcb-ech-03.txt
Internet-Draft draft-ietf-tls-svcb-ech-03.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings Authors: Ben Schwartz Mike Bishop Erik Nygren Name:draft-ietf-tls-svcb-ech-03.txt Pages: 6 Dates: 2024-07-23 Abstract: To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Trust Expressions Update
On 21/07/2024 18:09, Kyle Nekritz wrote: Do you see differences with trust negotiation, or in the specific negotiation mechanisms that are being proposed? Or would you have similar concerns if, say, we didn't already have named group negotiation, and were discussing adding that right now? My concerns are about deploying a mechanism for negotiating which certificate the server sends that can scale to the divergent requirements of many different parties. Right now, servers are pretty much forced into choosing between being available on the WebPKI or being available on some other PKI. There are limited mechanisms which do allow servers to select alternative certificates (e.g. based on the client's IP or which interface it is accessing in corporate environments), but these mechanisms cannot be used at scale without causing massive incidental breakage without some signal from the client as to which server certs it trusts. Trust Expression's 'fixes' that restriction and allows servers to participate in multiple PKIs simultaneously. Importantly, Trust Labels are not limited to some fixed set like signature_algorithms registered with IANA. Trust Expression's design requires that TLS libraries accept any trust_label conveyed by the CA via the provisioned certificate chains. Trust labels are basically opaque user-agent strings which can negotiate arbitrary things about the contents of the certificate message in TLS. This makes it easy for good actors like Chrome to deploy a new experiment or new security policies via a new trust label, but also empower actors trying to establish their own PKIs with less noble intentions (explained further in [1]). Does that clarify the technical difference between introducing something like Trust Expressions and other more limited negotiation mechanisms? Best, Dennis [1] https://github.com/dennisjackson/trust-negotiation-comments/blob/main/concerns-and-risks.md#root-programs-and-mass-surveillance ___ 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 that I didn’t provide a comprehensive answer, only that it was possible, perhaps one API at a time. So maybe that addresses many legacy apps. But you are totally right that the surface area is MUCH bigger than that. ___ 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 don't think its possible to go one API / method at a time. If we want to turn on a feature by default, it has to either be non-backwards compatible or not break any existing API. This is a problem for Trust Expressions because exposing the TLS certificate to the application is a major part of pretty much all existing library APIs and the library doesn't know what the application is going to enforce (or expect) about those certificates. This makes it hard (impossible?) for Trust Expressions to accurately convey the application's policy or to be used to experiment with the certificate format. Best, Dennis On 23/07/2024 09:41, Salz, Rich wrote: I agree that I didn’t provide a comprehensive answer, only that it was possible, perhaps one API at a time. So maybe that addresses many legacy apps. But you are totally right that the surface area is MUCH bigger than that. ___ 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 don't think its possible to go one API / method at a time. If we want to turn on a feature by default, it has to either be non-backwards compatible or not break any existing API. I think I agree with you, or at least as far as saying that we really need to hear from implementors as to the feasibility of doing this in a backward-compatible and generic (not just browser/WebPKI) way. ___ 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 Tue, Jul 23, 2024, 11:04 AM Salz, Rich wrote: > I don't think its possible to go one API / method at a time. If we want to > turn on a feature by default, it has to either be non-backwards compatible > or not break any existing API. > > I think I agree with you, or at least as far as saying that we really need > to hear from implementors as to the feasibility of doing this in a > backward-compatible and generic (not just browser/WebPKI) way. > Applications that don't support aren't worse off because other applications can use a newer PKI with fewer problems. > ___ > 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
Applications that don't support aren't worse off because other applications can use a newer PKI with fewer problems. I think the point is that it is unlikely this “better PKI changes” come for free without detailed understanding on the part of app developers ___ 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 23/07/2024 11:08, Watson Ladd wrote: Applications that don't support aren't worse off because other applications can use a newer PKI with fewer problems. The sub-thread Mike started has been specifically on whether we can bring Trust Expressions to non-browser applications by default. I don't think we can but definitely appreciate hearing from other implementers. If the claim is: "This thing has value even if only browsers do it", that simplifies the discussion a lot and helps us talk through the use-cases. For example: I want non-browser clients to be able to do fully PQ TLS by default. I think that's a reasonable expectation. If applications have to opt-in to use Trust Expressions through new APIs and Trust Expressions is necessary for PQ TLS, I feel we're landing in a pretty bad place on the PQ adoption story... 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 Tue, Jul 23, 2024 at 11:10 AM Watson Ladd wrote: > On Tue, Jul 23, 2024, 11:04 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote: > >> I don't think its possible to go one API / method at a time. If we want >> to turn on a feature by default, it has to either be non-backwards >> compatible or not break any existing API. >> >> I think I agree with you, or at least as far as saying that we really >> need to hear from implementors as to the feasibility of doing this in a >> backward-compatible and generic (not just browser/WebPKI) way. >> > > Applications that don't support aren't worse off because other > applications can use a newer PKI with fewer problems. > Right, incremental deployment is still valuable. Every client that is removed from the fallback case is one less client that constrains the fallback's intersection, and one more client that can evolve unburdened. We've tried to be clear on this from the beginning, and haven't ever claimed to be targeting 100% automatic client deployment. Very few things done by this WG depend on or target that. Of course, making things easier to deploy is always welcome. As with any other work we do in this WG, that's often very dependent on the very specific implementation details and what layer of the stack one works at. ECH, at the level of most TLS libraries, required quite a few caller changes. At the level of HTTPS libraries, however, it can plausibly be done automatically. There's also a wide range of deployment ease, ranging from your TLS library doing it automatically, to needing to opt-in to avoid a couple API interactions specific to one implementation, to callers needing to make a couple simple decisions, to callers needing to make some very complex decisions. Indeed part of why we've presented the second draft is that they represent very different deployment tradeoffs. And even within a broad solution direction, there are a lot of decisions that impact this. For example, client ease of use for draft-beck-tls-trust-anchor-ids will change dramatically depending on whether we use a separate connection (a la ECH) or a retry in the handshake (a la HRR, though we might not want it to be *exactly* HRR, we'll see). We wrote up the former just because it was a simpler representative of the overall idea. This all sounds like an excellent topic to continue discussing through post-adoption. As with other IETF work at this stage, our goal here isn't to present a complete solution, but to present a problem to solve, and some starting points for the WG to build on. David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Discussions on Trust Anchor Negotiation at IETF 120
There has been a lot of discussion over the past few days, both in person and on the mailing list. I want to share some thoughts on those discussions before the meeting tomorrow. My impression is that there is little consensus on which problems we want to solve as a WG. Resolving this is critical for making progress. It is almost impossible to have sensible conversations about new drafts without agreeing on and understanding the problems we want to solve. The vast majority of folks I've spoken with have said they're interested in solving the challenges around deploying fully PQ TLS, but don't feel that we are currently close to a shared understanding of those challenges or the tradeoffs around the drafts on the table today. A smaller number of folks are interested in tackling other problems around root store management. I fear this aspect of the problem space is even less clearly understood and I heard very little agreement on what the key challenges are or how they might be addressed. I hope tomorrow we can focus our discussion on figuring out as a WG the problem(s) that we want to tackle and where we differ in our understanding of those problems. I am sure that 20 minutes will not be enough time to resolve these complex issues, but I hope we can find a way to continue the conversation constructively. Ahead of the meeting tomorrow, I want to highlight some of the questions which I think we need to find and agree on answers for: - What are the problems that we solving? - Who are we solving these problems for? Browsers or everyone? - Are we proposing a hard requirement on this negotiation mechanism for anyone wanting to do fully PQ TLS? - Can the proposed mechanism be enabled by default in TLS Libraries without requiring application changes? - Can the proposed mechanism support use in a private PKI? How about in a private PKI that runs over the public Internet (in the now-classic zero-trust networking model)? - What is the long-term vision for TLS and the WebPKI? Are we moving forward together or fragmenting? - How do the proposed mechanisms affect TLS Client Hello fingerprinting or other tracking vectors? - How would the proposed system work in practice? What happens when actors follow their own interests rather than the requirements of RFCs? - Are less popular clients incentivized to lie in their Trust Expressions about which root stores they have? The history of browser HTTP User Agent spoofing [1] highlights how minority clients are forced to spoof the signals of other browsers to maximize site compatibility (even though it violates protocol requirements). - How would versioning root programs work in practice when security requirements change? If the same root CAs are in version N and version N+1 of a root store and version N+1 adopts a stricter security policy - can these root CAs still issue certificates for version N? - What are the consequences of making it easier to establish new root programs? For governments that have previously tried to build domestic root programs, would solve some of the problems they faced and encourage them to try again? Ultimately, these are two complex drafts which propose substantial changes to TLS and the WebPKI. Besides evaluating the technical details in the draft themselves, we also have to tackle the nitty gritty operational questions about how a new system would work in practice—in particular, considering the incentives of the stakeholders to adopt the system and or to deliberately deviate from the intended protocol for self-benefit. Finally, in any proposal which alters the power dynamics of a system, there will be difficult questions of a political nature, especially when the system in question is depended upon by billions of people. Naturally, good people will often disagree on the nuances of these complex topics. However, we owe it to each other to communicate constructively, arrive at a shared understanding and find a path forwards that as much of the community as possible can support. Best, Dennis [1] https://en.wikipedia.org/wiki/User-Agent_header#User_agent_spoofing ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
