[TLS]I-D Action: draft-davidben-tls-trust-expr-03.txt
Internet-Draft draft-davidben-tls-trust-expr-03.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: TLS Trust Expressions Authors: David Benjamin Devon O'Brien Bob Beck Name:draft-davidben-tls-trust-expr-03.txt Pages: 34 Dates: 2024-05-24 Abstract: This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-davidben-tls-trust-expr-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: WG Adoption for TLS Trust Expressions
On 23/05/2024 17:41, David Benjamin wrote: On Thu, May 23, 2024 at 11:09 AM Dennis Jackson wrote This is something that I believe David Benjamin and the other draft authors, and I all agree on. You and Nick seem to have misunderstood either the argument or the draft. David Benjamin, writing on behalf of Devon and Bob as well: By design, a multi-certificate model removes the ubiquity requirement for a trust anchor to be potentially useful for a server operator. [...] Server operators, once software is in place, not needing to be concerned about new trust expressions or changes to them. The heavy lifting is between the root program and the CA. From the Draft (Section 7): Subscribers SHOULD use an automated issuance process where the CA transparently provisions multiple certification paths, without changes to subscriber configuration. The CA can provision whatever chains it likes without the operator's involvement. These chains do not have to be trusted by any clients. This is a centralized mechanism which allows one party (the CA) to ship multiple chains of its choice to all of its subscribers. This obviously has beneficial use cases, but there are also cases where this can be abused. Hi Dennis, Since you seem to be trying to speak on my behalf, I'm going to go ahead and correct this now. This is not true. I think you have misunderstood how this extension works. [...] Hi David, The certification chains issued to the server by the CA comes tagged with a list of trust stores its included in. The named trust stores are completely opaque to the server. These chains and names may not be trusted by any client nor approved by any server, they are issued solely by the CA as opaque labels. These chains sit on the server and will not be used unless a client connects with the right trust store label but obviously can easily be scanned for by anyone looking to check how pervasively deployed the alternate trust store is. Do you dispute any part of that? Most of what you wrote went off on a completely different tangent. Of course, whether this property (whether servers can usefully pre-deploy not-yet-added trust anchors), which trust expressions does not have, even matters boils to whether a root program would misinterpret availability in servers as a sign of CA trustworthiness, when those two are clearly unrelated to each other. Again, my primary concern here is not around the behavior of individual root stores, this is not relevant to the concern I'm trying to communicate to you. I know folks from all of the major root stores have great faith in their judgement and technical acumen. My concern is that Trust Expressions upsets a fragile power balance which exists outside of the individual root stores. There is an eternal war between governments pushing to take control of root stores and the security community pushing back. This battle happens in parliaments and governments, between lawmakers and officials, not within root stores and their individual judgement largely does not matter to this war. The major advantages we as the security community have today are that: a) These attempts to take control for surveillance are nakedly obvious to the local electorate because crappy domestic roots have no legitimate purpose because they can never achieve any real adoption. b) If a root store were to bow to pressure and let in a root CA used for interception, every other country has an interest in preventing that. An international WebPKI means that we are either all secure, or all insecure, together. Trust Expressions, though intended to solve completely different problems, will accidentally eradicate both of these advantages. Firstly, it provides a nice on ramp for a new domestic trust store, mostly through the negotiation aspect but also through the CA pre-distribution. Secondly, by enabling fragmentation along geographic boundaries whilst maintaining availability of websites. Without Trust Expressions, we cannot balkanize TLS. With Trust Expressions, we can and we know people who want to (not anyone in this thread). If you still do not understand this wider context within which all of our work sits, I do not think further discussion between you and I is going to help matters. I would suggest we focus our discussion on the use cases of Trust Expressions and how exactly it would work in practice - these concerns I shared earlier in the thread are solely technical and operational and you and I might be able to make better progress towards a common understanding. Best, Dennis ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: WG Adoption for TLS Trust Expressions
Hi Ryan, On 23/05/2024 19:01, Ryan Hurst wrote: Regarding the concern about government-mandated adoption of root certificates, I also care deeply about this issue. This is why I am disappointed by the one-sided nature of the conversation. I see no mechanism in this proposal that bypasses operator consent, and while governments do and will continue to force operators to make changes not in their interest, this proposal doesn't change that reality. Continuing to focus on this issue in this way detracts from the more constructive discussions happening in this thread. The problem here is that fragmentation (which you acknowledge as a compelling concern) combined with making it much easier to deploy new CAs (a core goal of the draft) which together alters the power balance between the security community and governments in rather the wrong direction. I am not going to spend any further words on it here, but I'm disappointed you've engaged so dismissively in what has become a long discussion on a deeply complex topic. The most compelling argument against Trust Expressions I see in the thread is the potential for fragmentation. However, the current conversation on this topic overlooks the existing fragmentation challenges faced by site operators. The primary concern I hear from these operators is the anxiety over changes related to cipher suites and certificates, fearing that these changes might inadvertently break services in exchange for security properties that their leadership isn’t asking for. Trust Expressions, in my view, offers a net-positive solution to this problem by allowing site operators to manage the trust anchor portion of this risk, which they cannot do effectively today. Is it not rather the opposite, that this draft will give server operators an additional product space of choices and incompatibilities? With Trust Expressions, we must anticipate that CAs will need to jump through at least four separate hoops to provision a chain for each of the major root stores, as well as provision a chain for any past incompatible versions which are still popular. History does not suggest that CAs are particularly capable of managing these considerably more complex structures, given existing struggles with getting single chains correct. Worse, we cannot expect Trust Expressions to become universal in any reasonable timeframe, meaning we still have the compatibility headache of existing and new clients with no Trust Expressions support. At the same time, we are seeing more embedded devices being deployed without long-term maintenance strategies, automatic updates, or mechanisms to manage root store lists. Can you evidence this? The UK and the EU have passed fairly sweeping laws over the past year to require that manufacturers provide long term maintenance and security updates for the entire lifecycle of new digital products [1,2]. The USA usually catches up eventually. Better still, with the shift to PQ we have the best opportunity to adopt the Chrome Root Program's proposal for 7 year certificates. This would entirely fix this issue by pushing it from website operators to device manufacturers, where it should belong anyway :-), rather than creating a fragmented compatibility nightmare by embracing it and putting labels on it. Best, Dennis [1] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act [2] https://www.gov.uk/government/news/new-laws-to-protect-consumers-from-cyber-criminals-come-into-force-in-the-uki On Thu, May 23, 2024 at 10:40 AM Watson Ladd wrote: On Thu, May 23, 2024 at 12:42 PM David Benjamin wrote: > > Of course, whether this property (whether servers can usefully pre-deploy not-yet-added trust anchors), which trust expressions does not have, even matters boils to whether a root program would misinterpret availability in servers as a sign of CA trustworthiness, when those two are clearly unrelated to each other. Ultimately, the trustworthiness of CAs is a subjective social question: do we believe this CA has *and will continue* only sign true things? We can build measures to retroactively catch issues like Certificate Transparency, but the key question is fundamentally forward-looking. The role of a root program is to make judgement calls on this question. A root program that so misunderstands its role in this system that it conflates these two isn't going to handle its other load-bearing responsibilities either. As the old saw goes "past performance is no guarantee of future results, but it sure helps". Moreover root programs have to balance the benefits of including a CA against the costs. One of those benefits is the number of sites that use it. Sincerely, Watson > > David > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to
[TLS]Re: WG Adoption for TLS Trust Expressions
On Thu, May 23, 2024 at 4:14 AM Dennis Jackson wrote: > Hi Nick, > > I think the issues around risk have a great deal of nuance that you're not > appreciating, but which I've tried to lay out below. I appreciate that > rational reasonable people can absolutely disagree on how they weigh up > these risks, but I think we have to agree that Trust Expressions enables > websites to adopt new CA chains regardless of client trust and even builds > a centralized mechanism for doing so. It is a core feature of the design. > > On the issues around benefit, you've repeated the high level talking > points around PQ, adopting new CAs and supporting older devices, but these > talking points don't pan out on closer inspection. > > The central problem is that whilst Trust Expressions introduces a > negotiation mechanism at the TLS layer, it is only moving the pain up the > stack, without actually solving anything. To actually solve these problems, > Trust Expressions envisages that either website operators are doing a > complex dance with multiple CAs to enable the universal compatibility they > already enjoy today or that new CAs are forming business relationships with > incumbent CAs, identically as they would for a cross sign. In both cases, > we're adding a lot more complexity, fragmentation and pain, for no actual > return. > > A detailed response is inline below. > > Best, > Dennis > Hi Dennis, Since there's been a lot of discussion on this thread, I'm going to reply here to your comments relating to the problem Trust Expressions solves and how it compares to other potential solutions. The discussion of the risks is still an important topic, but to make it easier to focus on that discussion my replies to that will be in another message forking this thread. The main problem that Trust Expressions solves is giving servers a reliable way to pick which one of their multiple certificate chains to use on a connection with a given client. The transition to a PQC PKI is a motivating use case where servers will have multiple certificate chains and need to select one vs the other, though other use cases for a multi-certificate model also exist and have also been discussed. This is issue #2 in Andrei's email [1]. I agree with Andrei, you, and others that existing widely supported mechanisms (signature_algorithms and signature_algorithms_cert TLS extensions) solve issue #1 of selecting a chain compatible with the client's signature suite support, e.g. whether or not the client supports PQC PKI. Phrased differently, this existing mechanism is the negotiation mechanism needed by PQC PKI experiments. The only gap in using signature_algorithms_cert for negotiating the use of a PQC PKI experiment is issue #2 - identifying whether the client trusts a particular certificate chain. You suggest that instead of the client providing an indication of what roots it trusts, the server can (if the client supports the PQC algorithm) send a PQC certificate chain that is cross-signed by a ubiquitous classical CA. In this case, the client and server pay the cost of the PQC cert chain on the wire but only get the security of classical cryptography. Using a cross-sign also doesn't give the server a reliable signal about whether the client will trust the chain; instead it maintains the status quo where server operators hope that the cross-sign is ubiquitous enough for the client to trust it. This also assumes that the PQC PKI uses X.509 to be able to do the cross-sign, which puts an unnecessary design constraint on PQC PKI. Trust Expressions solves the problem of a server identifying which (if any) of its multiple certificate chains will be trusted by the client that is currently connecting to it. Temporal trust store divergence is one example of this problem. Despite your claims otherwise, the authors have explained [2] how Trust Expressions solves this problem: > It isn’t necessary for older device manufacturers to adopt Trust > Expressions. Rather, Trust Expressions would be adopted by modern clients, > allowing them to improve user security without being held back by older > clients that don’t update. Servers may still need to navigate intersections > and fingerprinting for older clients, but this will be unconstrained by > modern ones. It will also become simpler, with fingerprinting less > prevalent, as older clients fall out of the ecosystem. The key point here is that Trust Expressions keeps this problem from getting more complicated. Cross-signing only works if it's possible to construct a set of paths with the right cross-signs trusted by both the old devices and modern clients. I previously cited [3] as evidence of this, with a Let's Encrypt cross-sign having expired with no replacement. If cross-signs were a viable solution, we'd see more of it happening. Cross-signs are allowed by root programs. You seem to think that root programs encouraging cross signing would make them more of a valuable solution, but I can't infer from yo
[TLS]TLS Trust Expressions risks
On Fri, May 24, 2024 at 10:14 AM Dennis Jackson wrote: > Hi David, > > The certification chains issued to the server by the CA comes tagged with > a list of trust stores its included in. The named trust stores are > completely opaque to the server. These chains and names may not be trusted > by any client nor approved by any server, they are issued solely by the CA > as opaque labels. These chains sit on the server and will not be used > unless a client connects with the right trust store label but obviously can > easily be scanned for by anyone looking to check how pervasively deployed > the alternate trust store is. > > Do you dispute any part of that? Most of what you wrote went off on a > completely different tangent. > > Of course, whether this property (whether servers can usefully pre-deploy > not-yet-added trust anchors), which trust expressions does not have, even > matters boils to whether a root program would misinterpret availability in > servers as a sign of CA trustworthiness, when those two are clearly > unrelated to each other. > > Again, my primary concern here is not around the behavior of individual > root stores, this is not relevant to the concern I'm trying to communicate > to you. I know folks from all of the major root stores have great faith in > their judgement and technical acumen. > > My concern is that Trust Expressions upsets a fragile power balance which > exists outside of the individual root stores. There is an eternal war > between governments pushing to take control of root stores and the security > community pushing back. This battle happens in parliaments and governments, > between lawmakers and officials, not within root stores and their > individual judgement largely does not matter to this war. The major > advantages we as the security community have today are that: > > a) These attempts to take control for surveillance are nakedly obvious > to the local electorate because crappy domestic roots have no legitimate > purpose because they can never achieve any real adoption. > > b) If a root store were to bow to pressure and let in a root CA used > for interception, every other country has an interest in preventing that. > An international WebPKI means that we are either all secure, or all > insecure, together. > > Trust Expressions, though intended to solve completely different problems, > will accidentally eradicate both of these advantages. Firstly, it provides > a nice on ramp for a new domestic trust store, mostly through the > negotiation aspect but also through the CA pre-distribution. Secondly, by > enabling fragmentation along geographic boundaries whilst maintaining > availability of websites. Without Trust Expressions, we cannot balkanize > TLS. With Trust Expressions, we can and we know people who want to (not > anyone in this thread). > > If you still do not understand this wider context within which all of our > work sits, I do not think further discussion between you and I is going to > help matters. > > I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and you > and I might be able to make better progress towards a common understanding. > > Best, > Dennis > Hi Dennis, I’m replying in this separate thread to respond to some of your comments and responses around the risks related to Trust Expressions so that we can keep the primary thread focused on the technical matters. First, let’s agree on the facts of what Trust Expressions does. Trust Expressions makes it easier to deploy new CAs. Specifically, it makes it easier for servers to use certificate chains issued by new CAs. Trust Expressions does not enable the use/adoption/deployment of new CAs regardless of trust. It only does so for trusted CAs, whereby trusted I mean the CA is in a client’s root store. David Benjamin explains [1] this in detail in his latest reply. If you permit me to summarize what’s already been said on the thread: At the time of certificate issuance, the CA provides the web server with metadata (in the form of a TrustStoreInclusionList, section 5.1 [2]) indicating which trust stores contain the root for that certificate chain. When responding to a ClientHello that contains the trust_expressions TLS extension, the server will only use Trust Expressions if it has a certificate chain that at issuance time matched one of the client’s TrustStores. Trust Expressions only enables the deployment of certs from a new CA if that CA is trusted by a client when the CA sends the subscriber the TrustStoreInclusionList alongside the certificate chain. The client has to trust the CA before Trust Expressions enables use of a new CA, hence it only enables new CAs that are trusted. If the CA makes up its own trust store label to use for deployment, clients would have to be compelled to advertise that trust store label for this “pre-
[TLS]Re: WG Adoption for TLS Trust Expressions
On Fri, May 24, 2024 at 06:14:00PM +0100, Dennis Jackson wrote: > > Trust Expressions, though intended to solve completely different problems, > will accidentally eradicate both of these advantages. Firstly, it provides a > nice on ramp for a new domestic trust store, mostly through the negotiation > aspect but also through the CA pre-distribution. Secondly, by enabling > fragmentation along geographic boundaries whilst maintaining availability of > websites. Without Trust Expressions, we cannot balkanize TLS. With Trust > Expressions, we can and we know people who want to (not anyone in this > thread). One detail of Trust Expressions is that the extension value is TrustExpressionList, not TrustExpression. That is, client can signal support for multiple root programs. Thus, client X in region Y would signal X+Y, not X_Y to the server. The server that does not want to care about Y can then pick X (which is global) and send certificate accordingly. If getting cert in Y is way more painful than getting cert in X, that is further incentive to do just that... And that one region is one of those cases. And even if it isn't more painful, having more certificates is still more painful, so there is incentive to avoid that. The acknowledgement does not say which root program the server used. > I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and you > and I might be able to make better progress towards a common understanding. As for my guesses about how well Trust Expressions would work in practice for various cases presented: - It would not make CA distrusts less painful. I expect most sites do not have alternate certificates that are not off some oddball issuers for some weird devices. Such certificates are not usable for browser usecases, as those either have never been in the trust store, or have fallen out of it. - It is very effective at intermediate suppression. If the client can keep up even remotely up to date, I expect ~100% supression. This includes compat cross-signs that will pop up if root programs shorten root lifetimes. - It does help Post-Quantum deployment quite a lot. Without, until major four all accept common roots, PQ transition is dead in the water. And if site needs to deal with oddball clients, it is dead until quantum armageddon. Not a good place to be, to put it mildly. The SHA-1 to SHA-2 transion was rather painful and took over 10 years. - It could be used for migrating stuff off WebPKI. There is all sorts of stuff tacked on WebPKI that is constant source of pain (especially in any sort of transitions). Getting it off WebPKI into private PKIs would cut the pain by quite a bit. TE could be used that way. I propose API in client TLS libraries that let's cliet use a custom root program, that then gets signaled to server via TE. I do plan to add such API to the TLS library I wrote (later, when TE can archive interop). -Ilari ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: > > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > wrote: >> >> Hi David, >> >> The certification chains issued to the server by the CA comes tagged with a >> list of trust stores its included in. The named trust stores are completely >> opaque to the server. These chains and names may not be trusted by any >> client nor approved by any server, they are issued solely by the CA as >> opaque labels. These chains sit on the server and will not be used unless a >> client connects with the right trust store label but obviously can easily be >> scanned for by anyone looking to check how pervasively deployed the >> alternate trust store is. >> >> Do you dispute any part of that? Most of what you wrote went off on a >> completely different tangent. >> >> Of course, whether this property (whether servers can usefully pre-deploy >> not-yet-added trust anchors), which trust expressions does not have, even >> matters boils to whether a root program would misinterpret availability in >> servers as a sign of CA trustworthiness, when those two are clearly >> unrelated to each other. >> >> Again, my primary concern here is not around the behavior of individual root >> stores, this is not relevant to the concern I'm trying to communicate to >> you. I know folks from all of the major root stores have great faith in >> their judgement and technical acumen. >> >> My concern is that Trust Expressions upsets a fragile power balance which >> exists outside of the individual root stores. There is an eternal war >> between governments pushing to take control of root stores and the security >> community pushing back. This battle happens in parliaments and governments, >> between lawmakers and officials, not within root stores and their individual >> judgement largely does not matter to this war. The major advantages we as >> the security community have today are that: >> >> a) These attempts to take control for surveillance are nakedly obvious >> to the local electorate because crappy domestic roots have no legitimate >> purpose because they can never achieve any real adoption. >> >> b) If a root store were to bow to pressure and let in a root CA used for >> interception, every other country has an interest in preventing that. An >> international WebPKI means that we are either all secure, or all insecure, >> together. >> >> Trust Expressions, though intended to solve completely different problems, >> will accidentally eradicate both of these advantages. Firstly, it provides a >> nice on ramp for a new domestic trust store, mostly through the negotiation >> aspect but also through the CA pre-distribution. Secondly, by enabling >> fragmentation along geographic boundaries whilst maintaining availability of >> websites. Without Trust Expressions, we cannot balkanize TLS. With Trust >> Expressions, we can and we know people who want to (not anyone in this >> thread). >> >> If you still do not understand this wider context within which all of our >> work sits, I do not think further discussion between you and I is going to >> help matters. >> >> I would suggest we focus our discussion on the use cases of Trust >> Expressions and how exactly it would work in practice - these concerns I >> shared earlier in the thread are solely technical and operational and you >> and I might be able to make better progress towards a common understanding. >> >> Best, >> Dennis > > > Hi Dennis, > > I’m replying in this separate thread to respond to some of your comments and > responses around the risks related to Trust Expressions so that we can keep > the primary thread focused on the technical matters. First, let’s agree on > the facts of what Trust Expressions does. Trust Expressions makes it easier > to deploy new CAs. Specifically, it makes it easier for servers to use > certificate chains issued by new CAs. By trust expressions do we mean the extension, or the envisioned world where cert automation results in the CA provisioning multiple certificates to the server via ACME extensions? I don't see why a CA would send a cert from a competitor along with its own. This confusion is I think contributing to the rising temperatures, coming close to that of autoignition of IETF emails. > > Trust Expressions does not enable the use/adoption/deployment of new CAs > regardless of trust. It only does so for trusted CAs, whereby trusted I mean > the CA is in a client’s root store. David Benjamin explains [1] this in > detail in his latest reply. If you permit me to summarize what’s already been > said on the thread: At the time of certificate issuance, the CA provides the > web server with metadata (in the form of a TrustStoreInclusionList, section > 5.1 [2]) indicating which trust stores contain the root for that certificate > chain. When responding to a ClientHello that contains the trust_expressions > TLS extension, the server will only use T
[TLS]Re: WG Adoption for TLS Trust Expressions
On 5/23/2024 9:41 AM, David Benjamin wrote: At the end of the day, the TLS components of trust expressions are simply a more size-efficient form of the certificate_authorities field. The rest is working through the deployment implications to reduce server operator burden. However, the way we achieve this size efficiency is by *not* saying the CAs names. Instead, the CA sets are indirected through named and versioned "trust stores". However, the price one inherently needs to pay here is that servers need to know how to map from those trust stores back to the certificates. We solve this with the TrustStoreInclusionList metadata from the CA. That TrustStoreInclusionList structure is necessarily a point-in-time snapshot of the state of the world. If a root program has not included a CA yet, the CA cannot claim it in the metadata or connections will fail. If the CA is included in zero root programs, the only viable (i.e. correct and does not cause interop issues) TrustStoreInclusionList is the empty list, in which case the certificate will never be presented. I think this is making the assumptions that the only choice for clients is to adopt one "well known" trust store, probably from a short list. I am concerned that such mechanisms reinforce ongoing centralization of the web. -- Christian Huitema ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
> > What point in this process depends on Trust Expressions - that is to say, > at what point does a browser decide that the government CA is acting > differently enough from the other CAs in its root store that it’s willing > to fragment or bifurcate its trust store, and after that point, how does > the politics play out that mandating this CA’s trust is still somehow > legitimate? I'll assert that many people consider eavesdropping by their own government to be legitimate, and eavesdropping by foreign governments to be illegitimate. The point at which a browser would need to make a decision about bifurcating its trust store or pulling out of a country, is the moment a government-controlled CA starts mis-issuing certificates. Without TE, browsers have no ability to bifurcate their trust store, and servers have no ability to support a bifurcated client base. So without TE, the decision must be to pull out of the country, as this is the only technically expedient solution which is acceptable to most people. With TE, browsers /can/ bifurcate their trust store, and servers /can/ support a bifurcated client base. So a decision to pull out of the country, rather than bifurcate, is simply malicious. It's also worth pointing out that the security benefits of TE (i.e., allowing rapid distrust of roots) come from gracefully handling client fragmentation that's the result of time-since-last-update, not fragmentation that's a result of different codebases. It may be worth thinking about how to rework the proposal to reflect that On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: > > > > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson 40dennis-jackson...@dmarc.ietf.org> wrote: > >> > >> Hi David, > >> > >> The certification chains issued to the server by the CA comes tagged > with a list of trust stores its included in. The named trust stores are > completely opaque to the server. These chains and names may not be trusted > by any client nor approved by any server, they are issued solely by the CA > as opaque labels. These chains sit on the server and will not be used > unless a client connects with the right trust store label but obviously can > easily be scanned for by anyone looking to check how pervasively deployed > the alternate trust store is. > >> > >> Do you dispute any part of that? Most of what you wrote went off on a > completely different tangent. > >> > >> Of course, whether this property (whether servers can usefully > pre-deploy not-yet-added trust anchors), which trust expressions does not > have, even matters boils to whether a root program would misinterpret > availability in servers as a sign of CA trustworthiness, when those two are > clearly unrelated to each other. > >> > >> Again, my primary concern here is not around the behavior of individual > root stores, this is not relevant to the concern I'm trying to communicate > to you. I know folks from all of the major root stores have great faith in > their judgement and technical acumen. > >> > >> My concern is that Trust Expressions upsets a fragile power balance > which exists outside of the individual root stores. There is an eternal war > between governments pushing to take control of root stores and the security > community pushing back. This battle happens in parliaments and governments, > between lawmakers and officials, not within root stores and their > individual judgement largely does not matter to this war. The major > advantages we as the security community have today are that: > >> > >> a) These attempts to take control for surveillance are nakedly > obvious to the local electorate because crappy domestic roots have no > legitimate purpose because they can never achieve any real adoption. > >> > >> b) If a root store were to bow to pressure and let in a root CA > used for interception, every other country has an interest in preventing > that. An international WebPKI means that we are either all secure, or all > insecure, together. > >> > >> Trust Expressions, though intended to solve completely different > problems, will accidentally eradicate both of these advantages. Firstly, it > provides a nice on ramp for a new domestic trust store, mostly through the > negotiation aspect but also through the CA pre-distribution. Secondly, by > enabling fragmentation along geographic boundaries whilst maintaining > availability of websites. Without Trust Expressions, we cannot balkanize > TLS. With Trust Expressions, we can and we know people who want to (not > anyone in this thread). > >> > >> If you still do not understand this wider context within which all of > our work sits, I do not think further discussion between you and I is going > to help matters. > >> > >> I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and
[TLS]Re: TLS Trust Expressions risks
> > In your latest message [5], I understand the context of governments > pushing for inclusion of certain roots with varying degrees of legitimacy. > I don’t see the on-ramp for CA pre-distribution being meaningfully > different with Trust Expressions compared to certificate_authorities. > Sorry, I meant to address this point as well. The difference between TE and the certificate_authorities extension, is that there's less widespread server support for the latter. You might compel a browser to bifurcate and advertise the certificate_authorities extension, but pushing out server-side support would be a substantial challenge. Not speaking for Google, but I believe their intention /is/ to put in the substantial work to make server-side TE support ubiquitous, such that it would be a minor ACME config change On Fri, May 24, 2024 at 4:00 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > What point in this process depends on Trust Expressions - that is to say, >> at what point does a browser decide that the government CA is acting >> differently enough from the other CAs in its root store that it’s willing >> to fragment or bifurcate its trust store, and after that point, how does >> the politics play out that mandating this CA’s trust is still somehow >> legitimate? > > > I'll assert that many people consider eavesdropping by their own > government to be legitimate, and eavesdropping by foreign governments to be > illegitimate. The point at which a browser would need to make a decision > about bifurcating its trust store or pulling out of a country, is the > moment a government-controlled CA starts mis-issuing certificates. Without > TE, browsers have no ability to bifurcate their trust store, and servers > have no ability to support a bifurcated client base. So without TE, the > decision must be to pull out of the country, as this is the only > technically expedient solution which is acceptable to most people. With TE, > browsers /can/ bifurcate their trust store, and servers /can/ support a > bifurcated client base. So a decision to pull out of the country, rather > than bifurcate, is simply malicious. > > It's also worth pointing out that the security benefits of TE (i.e., > allowing rapid distrust of roots) come from gracefully handling client > fragmentation that's the result of time-since-last-update, not > fragmentation that's a result of different codebases. It may be worth > thinking about how to rework the proposal to reflect that > > > On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > >> On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: >> > >> > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >> >> >> Hi David, >> >> >> >> The certification chains issued to the server by the CA comes tagged >> with a list of trust stores its included in. The named trust stores are >> completely opaque to the server. These chains and names may not be trusted >> by any client nor approved by any server, they are issued solely by the CA >> as opaque labels. These chains sit on the server and will not be used >> unless a client connects with the right trust store label but obviously can >> easily be scanned for by anyone looking to check how pervasively deployed >> the alternate trust store is. >> >> >> >> Do you dispute any part of that? Most of what you wrote went off on a >> completely different tangent. >> >> >> >> Of course, whether this property (whether servers can usefully >> pre-deploy not-yet-added trust anchors), which trust expressions does not >> have, even matters boils to whether a root program would misinterpret >> availability in servers as a sign of CA trustworthiness, when those two are >> clearly unrelated to each other. >> >> >> >> Again, my primary concern here is not around the behavior of >> individual root stores, this is not relevant to the concern I'm trying to >> communicate to you. I know folks from all of the major root stores have >> great faith in their judgement and technical acumen. >> >> >> >> My concern is that Trust Expressions upsets a fragile power balance >> which exists outside of the individual root stores. There is an eternal war >> between governments pushing to take control of root stores and the security >> community pushing back. This battle happens in parliaments and governments, >> between lawmakers and officials, not within root stores and their >> individual judgement largely does not matter to this war. The major >> advantages we as the security community have today are that: >> >> >> >> a) These attempts to take control for surveillance are nakedly >> obvious to the local electorate because crappy domestic roots have no >> legitimate purpose because they can never achieve any real adoption. >> >> >> >> b) If a root store were to bow to pressure and let in a root CA >> used for interception, every other country has an interest in preventing >> that. An international WebPKI means that we are eith
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 2:27 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > In your latest message [5], I understand the context of governments >> pushing for inclusion of certain roots with varying degrees of legitimacy. >> I don’t see the on-ramp for CA pre-distribution being meaningfully >> different with Trust Expressions compared to certificate_authorities. >> > > Sorry, I meant to address this point as well. The difference between TE > and the certificate_authorities extension, is that there's less widespread > server support for the latter. You might compel a browser to bifurcate and > advertise the certificate_authorities extension, but pushing out > server-side support would be a substantial challenge. Not speaking for > Google, but I believe their intention /is/ to put in the substantial work > to make server-side TE support ubiquitous, such that it would be a minor > ACME config change > The degree of server support is an important consideration. Even with ubiquitous server-side TE support and servers configured with both a ubiquitous chain and a government-issued chain, it seems to me this government push for use of their CA requires a change to server TLS stacks to prefer the government CA chain since both will match the client's advertised trust stores. Mandating this server behavior change seems to me like a heavier lift than just a minor config change. I don't have a good sense of how it compares to the difficulty of configuring a server stack to use the certificate_authorities extension. It appears that at least OpenSSL has support for the certificate_authorities extension ( https://github.com/openssl/openssl/issues/13453), though the application using OpenSSL needs to implement the certificate selection. With TE, I imagine that certificate selection will happen inside the TLS stack or a TE library closely tied to the TLS stack. I wonder if there are ways to make it harder for a server to choose the "bad" cert and easier to choose the "good" cert, but this seems like a social/political problem rather than a technical one. On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > To be clear, in Denis's scenario Ebonia requires all servers to obtain > a cert from Honest Ahmed's > (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure > CA. Server operators who complain that this will break clients are > told that it will have a trust expression that currently isn't used, > but government inspectors will use it to see if the cert is installed. > Then in step 2 they use the number of certs issued to bolster the > argument for inclusion. I don't see how Trust Expressions isn't making > this scenario easier. > Sure, the Ebonian government could mandate that all servers get a cert from Honest Achmed, and provide a specific Ebonia trust store label for the servers to match against. However, the only time the server would use that cert chain is when the government inspectors send the Ebonian trust store label to check if the cert is installed. In step 2 when Ebonia uses the number of certs from Honest Achmed as part of their argument, it matters what that count is. Is it the number of certs issued, number of certs servers are "willing to use" (that's not very well defined), number of certs that servers are actually using? Of course Ebonia will choose whatever suits them best, but it also depends where that number came from and how it was obtained. For example, Ebonia can get a large number of certs issued by Honest Achmed without Trust Expressions by having Honest Achmed generate a cert for every cert it sees in CT logs (with the Honest Achmed leaf using the same public key as in the logged leaf certs so that they're technically usable by the server). I imagine if Ebonia tried to use that count of certificates issued as part of their argument for adoption, there would be outcry about how that volume of cert issuance is manufactured and meaningless. In the scenario where certs are issued and delivered to servers, but they only use them in response to the government inspectors (because those are the only clients that match, this volume of cert issuance to me seems similarly manufactured and meaningless. Maybe Trust Expressions makes that scenario ever so slightly easier, but it seems like this step requires manufacturing false demand/use that would be fairly clear to see is occurring and discount it when arguing against that claim. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: WG Adoption for TLS Trust Expressions
On Fri, May 24, 2024 at 2:05 PM Christian Huitema wrote: > > > On 5/23/2024 9:41 AM, David Benjamin wrote: > > At the end of the day, the TLS components of trust expressions are > > simply a more size-efficient form of the certificate_authorities field. > > The rest is working through the deployment implications to reduce server > > operator burden. However, the way we achieve this size efficiency is by > > *not* saying the CAs names. Instead, the CA sets are indirected through > > named and versioned "trust stores". However, the price one inherently > > needs to pay here is that servers need to know how to map from those > > trust stores back to the certificates. We solve this with the > > TrustStoreInclusionList metadata from the CA. > > > > That TrustStoreInclusionList structure is necessarily a point-in-time > > snapshot of the state of the world. If a root program has not included a > > CA yet, the CA cannot claim it in the metadata or connections will fail. > > If the CA is included in zero root programs, the only viable (i.e. > > correct and does not cause interop issues) TrustStoreInclusionList is > > the empty list, in which case the certificate will never be presented. > > I think this is making the assumptions that the only choice for clients > is to adopt one "well known" trust store, probably from a short list. I > am concerned that such mechanisms reinforce ongoing centralization of > the web. > > I think this is a worthwhile concern, and while noting that I am an author of this draft, I will attempt to wear a slightly different hat temporarily. In another life I help maintain an OS trust store for non-mainstream clients to access the web. My "choices" today are basically to follow Firefox or Chrome and include most of what they support. (we have basically followed Firefox for many years). We can decide to not include certain CA's that we don't feel have merit, but only if they have very little use. We do not have an effective way to add anything separate or distinct for our clients, as such servers can not also be used with the public web in general. So I think as far as the situation is today, trust store choice is already very centralized if you want your client to "usually work" on the public web. We have basically two choices. both of which are very very similar in their content. I am not certain that trust expressions would change that situation for a non-mainstream client like this, but I don't think that it makes my choices worse. I still have the same choice - follow one of the well known trust stores. I can do this either by continuing as always and not having the client send a trust expression, or, by fetching the trust anchors from a "well known" big trust store and modifying the client to support the necessary things and to send the appropriate trust expression. Were a "new" trustworthy root program to show up with CA partnerships that were useful and made use of trust expressions, a non-mainstream client could potentially start to make use of that as another choice, *If* they trusted the operators of such a program to do a good job of evaluating the trustworthiness of the CA's they were including. -Bob > ___ > 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: TLS Trust Expressions risks
> > Even with ubiquitous server-side TE support and servers configured with > both a ubiquitous chain and a government-issued chain, it seems to me this > government push for use of their CA requires a change to server TLS stacks > to prefer the government CA chain since both will match the client's > advertised trust stores. Mandating this server behavior change seems to me > like a heavier lift than just a minor config change. > The part of the spec you quoted says: if multiple certs match, choose any. When TE is rendered in actual code, why do you assume that there will be no configurable or easily-gameable way to make sure the government CA always wins? On Fri, May 24, 2024 at 5:15 PM Nick Harper wrote: > > > On Fri, May 24, 2024 at 2:27 PM Brendan McMillion < > brendanmcmill...@gmail.com> wrote: > >> In your latest message [5], I understand the context of governments >>> pushing for inclusion of certain roots with varying degrees of legitimacy. >>> I don’t see the on-ramp for CA pre-distribution being meaningfully >>> different with Trust Expressions compared to certificate_authorities. >>> >> >> Sorry, I meant to address this point as well. The difference between TE >> and the certificate_authorities extension, is that there's less widespread >> server support for the latter. You might compel a browser to bifurcate and >> advertise the certificate_authorities extension, but pushing out >> server-side support would be a substantial challenge. Not speaking for >> Google, but I believe their intention /is/ to put in the substantial work >> to make server-side TE support ubiquitous, such that it would be a minor >> ACME config change >> > > The degree of server support is an important consideration. Even with > ubiquitous server-side TE support and servers configured with both a > ubiquitous chain and a government-issued chain, it seems to me this > government push for use of their CA requires a change to server TLS stacks > to prefer the government CA chain since both will match the client's > advertised trust stores. Mandating this server behavior change seems to me > like a heavier lift than just a minor config change. I don't have a good > sense of how it compares to the difficulty of configuring a server stack to > use the certificate_authorities extension. It appears that at least OpenSSL > has support for the certificate_authorities extension ( > https://github.com/openssl/openssl/issues/13453), though the application > using OpenSSL needs to implement the certificate selection. With TE, I > imagine that certificate selection will happen inside the TLS stack or a TE > library closely tied to the TLS stack. > > I wonder if there are ways to make it harder for a server to choose the > "bad" cert and easier to choose the "good" cert, but this seems like a > social/political problem rather than a technical one. > > On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > >> To be clear, in Denis's scenario Ebonia requires all servers to obtain >> a cert from Honest Ahmed's >> (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure >> CA. Server operators who complain that this will break clients are >> told that it will have a trust expression that currently isn't used, >> but government inspectors will use it to see if the cert is installed. >> Then in step 2 they use the number of certs issued to bolster the >> argument for inclusion. I don't see how Trust Expressions isn't making >> this scenario easier. >> > > Sure, the Ebonian government could mandate that all servers get a cert > from Honest Achmed, and provide a specific Ebonia trust store label for the > servers to match against. However, the only time the server would use that > cert chain is when the government inspectors send the Ebonian trust store > label to check if the cert is installed. In step 2 when Ebonia uses the > number of certs from Honest Achmed as part of their argument, it matters > what that count is. Is it the number of certs issued, number of certs > servers are "willing to use" (that's not very well defined), number of > certs that servers are actually using? Of course Ebonia will choose > whatever suits them best, but it also depends where that number came from > and how it was obtained. For example, Ebonia can get a large number of > certs issued by Honest Achmed without Trust Expressions by having Honest > Achmed generate a cert for every cert it sees in CT logs (with the Honest > Achmed leaf using the same public key as in the logged leaf certs so that > they're technically usable by the server). I imagine if Ebonia tried to use > that count of certificates issued as part of their argument for adoption, > there would be outcry about how that volume of cert issuance is > manufactured and meaningless. In the scenario where certs are issued and > delivered to servers, but they only use them in response to the government > inspectors (because those are the only clients that match, this volume of > cert issua
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 4:15 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > The part of the spec you quoted says: if multiple certs match, choose any. > When TE is rendered in actual code, why do you assume that there will be no > configurable or easily-gameable way to make sure the government CA > always wins? > I'm not assuming there will be no configurable or easily-gameable way to do this - I don't know what exactly that will look like in implementations. I'm asserting that TE alone as currently specified is insufficient for this attack, because TE says "choose any" and the attack needs to choose a specific one. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 5:18 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > Even with ubiquitous server-side TE support and servers configured with >> both a ubiquitous chain and a government-issued chain, it seems to me this >> government push for use of their CA requires a change to server TLS stacks >> to prefer the government CA chain since both will match the client's >> advertised trust stores. Mandating this server behavior change seems to me >> like a heavier lift than just a minor config change. >> > > The part of the spec you quoted says: if multiple certs match, choose any. > When TE is rendered in actual code, why do you assume that there will be no > configurable or easily-gameable way to make sure the government CA > always wins? > Since the server is free to apply whatever logic (random, smallest number of bytes on the wire, secret government coercion) it likes to pick from multiple matches, If what the government intends is to *always* have the paths matching a particular trust expression chosen on a multiple match, the server software needs to be either gamed, or complicit in making that happen, or it will not happen reliably. (either that or the client needs to be mandated to be modified to simply try with only the desired "bad" trust first, and then if it doesn't work silently reconnect with the "good" trust to work with the rest of the world - which can happen without trust expressions perfectly fine, and is a trick clients have used before for things like, SHA1 deprecation. I don't believe this is in any way different than a server supporting https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 (which says the list should be used as "guidance" and leaves it up to the implementer - maybe the list is in a priority order like key shares, maybe it is not?) While I am not convinced that this is a real risk for surveillance issues that is not already present, as already outlined in our previous replies, If the community at large truly believes that this is a real risk worthy of design work to mitigate, then this should probably also be addressed in 8446 at the same time. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
