From: Joseph Salowey <j...@salowey.net> Date: Wednesday, May 22, 2024 at 5:04 PM To: "tls@ietf.org" <tls@ietf.org> Subject: [TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions Thanks to the working group for all the discussion on this document. We will kick off an official adoption call soon. While this work is clearly applicable to TLS, the topic of trust stores is broader. [CW] Path building is broader too. The working group should be aware that if the document is adopted as a working group item, It's possible that work will be identified that would be better addressed in other forums. It is also possible that this situation will not arise and all the work will be completed in TLS. On Wed, May 22, 2024 at 8:45 AM Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org> wrote: While a TLS extension could be used to identify which approaches/algorithms/protocols the client supports, the server also needs to know which of its certificate chains the client trusts. To me, these are two separate issues: Selecting a certificate chain based on the client’s signature suite support and Selecting a certificate chain the client trusts. #1 is already solved: we have signature_algorithms_cert and signature_algorithms extensions. Some TLS implementations have support for deploying multiple cert chains per endpoint and selecting the appropriate cert chain based on peer-supported signature suites. This should work fine for PQC, once we define PQC and hybrid SignatureScheme code points. #2 has an existing solution as well (certificate_authorities extension), but in practice it’s not efficient and in some cases not secure. This is where we need improvement and Trust Expressions appears to be an option, although we will likely want to change the details of the design a bit and make it better. Cheers, Andrei From: Nick Harper <i...@nharper.org> Sent: Tuesday, May 21, 2024 11:29 PM To: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Cc: tls@ietf.org Subject: [EXTERNAL] [TLS]Re: WG Adoption for TLS Trust Expressions You don't often get email from i...@nharper.org. Learn why this is important On Tue, May 21, 2024 at 3:00 PM Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> wrote: This thread is now 40+ messages deep and I guess you might have not seen much of the previous discussion. I actually agree with much of your analysis, but it focused on the wrong question, as I wrote earlier in this thread: The question we're evaluating is NOT "If we were in a very unhappy world where governments controlled root certificates on client devices and used them for mass surveillance, does Trust Expressions make things worse?" Although Watson observed that the answer to this is at least 'somewhat', I agree such a world is already maxed at 10/10 on the bad worlds to live in scale and so it's not by itself a major problem in my view. I don't see Watson saying that in any of his messages [5] [6] [7]. Message [7] does mention an intermediate cross-signed by a government CA, but my understanding of Watson's argument is that Trust Expressions doesn't do anything to enable that since the "chain" of certificates sent by a TLS server is really just a grab bag for the client to use when it does path building. Specifically, in today's world, a CA could send to ACME clients a leaf cert with intermediates and cross-signs so that the root of the path could be either that CA or a government CA, and when that server sends that bag of intermediates to a client to verify, the client will build one of those two paths, depending on what's in the client's trust store. The actual concern is: to what extent do Trust Expressions increase the probability that we end up in this unhappy world of government CAs used for mass surveillance? This is a good question to ask, and I see you attempted to address it in message [4]. You argue that Trust Expressions provides an "on-ramp" for deploying a government CA to reach a certain level of legitimacy or adoption. I don't see the connection between that and mass surveillance, nor do I see you make a claim that Trust Expressions does increase this probability. In [1] you describe this "on-ramp", which has step 1 being to ship support for trust negotiation (which could be more accurately described as a trust store advertisement mechanism), and step 2 as the following: > * A large country or federation pushes for recognition of their > domestic trust regime as a distinct trust store which browsers must > advertise. Browsers agree because the relevant market is too big to > leave. I see two ways this happens: The first is that the recognition of the domestic trust regime is done in a way that does not circumvent root store policy. By this, I mean that the CAs in this domestic trust regime must meet all audit and other policy requirements of the browser's root store, and a brower root store can remove trust in a CA from that set if it violates the root store requirements (in the same way that root stores currently operate to distrust a CA when it is no longer trustworthy). In this case, I see no negative effect on security for users or the websites they are connecting to. From a technical perspective, this looks the same regardless of whether the Web PKI ecosystem supports a trust store advertisement mechanism. I see no change in the probability of ending up in the "unhappy world" in this way. The second way this could happen is that the government compels a browser to add a CA to their root store regardless of whether it complies with root store policy, implicitly stating that this CA will misissue certificates. The browser's choice is to comply or leave the market. Until this new CA is in a trust store advertised by clients, there's no incentive for server operators to get a certificate issued by that CA, as there are no clients for it to present that cert to. Thus, server adoption is no factor in the government's pressure to compel a browser to add their CA, and I see the same probability of this being successful as in the current state of the world without Trust Expressions. There is potentially a hybrid approach, where the government first asks nicely that browsers add CA G to their root stores (where root stores are welcome to remove G if it violates policy). At some later point in time, the government tells browsers that since now G is already in their root stores, they're not allowed to remove it, and at some point later G starts mis-issuing certificates to perform surveillance or do other bad things. This switcheroo looks the same in today's world as it does in a world with a trust store advertisement mechanism. In a world without trust expressions, the government gets G added to all major browser root stores, then starts doing bad things with G when it's rolled out to enough browsers. Doing bad things with G requires no server adoption. In a world without trust store advertisements, the government can still compel/coerce/encourage site operators to use a cert issued by G, by using the mechanism that Watson described and is repeated above that requires no changes to how servers get certificates from ACME, or by issuing a completely different chain and relying on G's ubiquity in browsers. My takeaway to the direct question about Trust Expressions increasing the probability of ending up in this unhappy world is that it doesn't increase that probability. In addition to asking that question about probability, message [4] also states: > The real problem here is that you've > (accidentally?) built a system that makes it much easier to adopt and > deploy any new CA regardless of trust, rather than a system that makes > it easier to deploy & adopt any new *trusted* CA. I disagree that it makes it easier to adopt and deploy a new CA *regardless of trust*. Trust Expressions only makes it easier to deploy a CA that is in a trust store advertised by clients. If a CA is in a client's trust store, that to me sounds like a *trusted CA*. On 21/05/2024 19:05, Nick Harper wrote: I'd be interested to hear details on what those are. Messages [1,2,3,4] of this thread lay out these details at length. You asked to think through how widespread support for Trust Expressions would help a government enable surveillance and domestic control of the web. When thinking through this, I also considered what has previously been discussed in the thread. Based on what I saw in the thread and the summary of potential attacks, I couldn't find how Trust Expressions would help a government achieve those goals - using Trust Expressions as a means to that end resulted in an equivalent or worse version of what can already be done with existing techniques. I took another look at the messages you cited to see if I missed anything in them about how Trust Expressions would help a government enable surveillance and domestic control of the web, and found nothing. Here's a review of what's in those messages and what might be relevant: Message [1] states the following actions a government might take: > * One or more countries start either withholding certificates for > undesirable sites, blocking connections which don't use their trust > store, requiring key escrow to enable interception, etc etc. Withholding certs and blocking connections are both addressed in my previous email. Trust Expressions provides no benefits for censorship compared to the status quo. Requiring key escrow is again something that could be done today without Trust Expressions. Messages [2], [3], and [4] talk about the use of Trust Expressions for a government CA to be deployed on clients and servers. Message [2] discusses the technical measures that a government might use to roll out a government-issued CA, but it says nothing about why the government is rolling out such a CA or what attacks it would carry out with it. Message [3] discusses many topics: CA key rotation and CA distrust, ACME deployment considerations and server configuration (relationships with a single CA vs multiple), and whether the deployment of Trust Expressions with ACME could result in CAs providing servers an additional chain that's cross-signed by the government PKI. Message [4] talks about how Trust Expressions is a mechanism that makes it easier to adopt and deploy any new CA. In my opinion, the issue of Trust Expressions enabling government surveillance has been discussed in great detail and the conclusion is that it is not an effective or useful tool for doing that. Instead, we should focus discussion on the problems that Trust Expressions solves. Besides these concerns which are unaddressed so far, much of the recent discussion has focused on establishing what problem(s) Trust Expressions actually solves and how effective a solution it actually is. Looking forward to your thoughts on either or both aspects. The general problem I see Trust Expressions solving is how a server can choose which certificate chain to present to a client with a high degree of confidence that the client will trust that certificate chain (assuming the server has such a chain available to it). This general problem has multiple concrete instantiations. The primary motivator is the transition to post quantum cryptography in the Web PKI. Another is the existing problem with temporal trust store divergence. This problem currently manifests in servers and CA operators trying to provide a certificate chain that works for both old and modern devices. In the future as CA operators rotate root keys more frequently, the new root should be usable once it has met all the requirements for inclusion in the root store, instead of waiting for a significant portion of its lifetime to become ubiquitous. As the Web PKI transitions to PQC, there will be a long transition time where server operators will need to support having multiple distinct certificate chains and send the appropriate one based on whether the client supports a PQC PKI or only classical cryptography. There will also be experiments with different approaches on how to build a PQC PKI. A server provisioned with multiple certificate chains (a prerequisite for PQC PKI) needs to know which one to use with each client. While a TLS extension could be used to identify which approaches/algorithms/protocols the client supports, the server also needs to know which of its certificate chains the client trusts. There is no reason to assume that there will be a single ubiquitous set of PQC CAs, especially during the transition period when experiments are ongoing for different approaches for a PQC PKI. One potential approach already being discussed is Merkle Tree Certs [8], and that will require an as-yet unidentified alternative mechanism when its requirements (e.g. issuance delay, client freshness) can't be met. I'm sure there will be other ideas experimented with and considered that explore the tradeoffs in signature vs public key sizes as well as number of signatures in a certificate chain and transparency requirements. As CA operators start to spin up PQC CAs, different operators will do this at different times and with different technologies. A server that prefers to use a PQC certificate will need to know whether the client trusts that certificate's CA. At its simplest, consider a single web browser, a single PQC PKI technology, and two PQC CAs that get added to its root store at different times. If the server is a customer of the second PQC CA to get added to the root store, it needs to know whether the client (that supports PQC PKI) has updated to the new version of the root store. When multiple browsers are involved, this check of "is the client fresh?" is more complicated, as different browsers will add the second PQC CA to their root stores at different times, and they might add CAs to their root stores in different orders. Waiting for stability of the root stores is the same thing as waiting for ubiquity of trusted roots. This gets at the second instantiation of the problem: temporal trust store divergence. There's already been a fair amount of discussion on this thread about this [9][10], in the form of how to support older devices. I assume I don't need to explain why this is an important problem to solve. I believe Trust Expressions is an effective solution at solving all of these problems. I've only seen one serious alternative presented on this thread: cross-signs with Abridged Certs [11]. You present (in message [12]) two examples of using cross-signing to solve the temporal trust store divergence problem. One is a CA transitioning to new keying material. While this works for some period of time, we've already seen that it's reached its limit [7], and even with Abridged Certs there's an additional cost to the client and server storing the compression dictionary (or multiple versions of it) and the smaller number of bytes on the wire representing the compressed intermediate that could have been completely omitted had Trust Expressions been used instead. The second example is when a new CA wants to launch. The existing mechanism requires a new entrant to the space to make a business deal with one of its potential competitors to be able to usefully enter the market. This sounds like a bug, not a feature, of the system. In [12], you suggest that Trust Expressions encourages CA operators to more slowly transition to a PQC PKI, and that this is undesirable. In the transition to a PQC PKI, there will be experiments with different approaches, and different CA operators may choose different approaches to implement on different schedules. The incentive for CA operators to move quickly instead of waiting for others to pave the way is to meet the demand of servers that want PQC certs early. To me, it is clear that Trust Expressions solves the above problems more completely than cross-signs with Abridged Certs. Trust Expressions provides additional benefits across the Web PKI ecosystem. Servers that use trust expressions can be more confident that they are using a certificate chain trusted by their diverse set of clients (and monitor which trust expressions they don't support so they can adjust their certificate order configuration to close gaps if they want to support those clients). CA operators benefit by being able to issue certs from their new roots sooner without needing to wait for ubiquity or having server operators complain that they don't work. Root programs benefit by being able to more easily make changes with less risk of breakage (e.g. policy changes like root key lifetimes, and breakage due to the inability for servers to provide a set of certificates that both old and new clients can build valid paths for). Best, Dennis [1] https://mailarchive.ietf.org/arch/msg/tls/LaUJRHnEJds2Yfc-t-wgzkajXec/ [2] https://mailarchive.ietf.org/arch/msg/tls/zwPvDn9PkD5x9Yw1qul0QV4LoD8/ [3] https://mailarchive.ietf.org/arch/msg/tls/9AyqlbxiG7BUYP0UD37253MeK6s/ [4] https://mailarchive.ietf.org/arch/msg/tls/fxM4zkSn0b8zOs59xlH6uy8P7cE/ [5] https://mailarchive.ietf.org/arch/msg/tls/7a_4VsilMGwv4t4oGJJYAVxzCQ0/ [6] https://mailarchive.ietf.org/arch/msg/tls/7PPVRTRjg-be7kfalZDXLm4xwzI/ [7] https://mailarchive.ietf.org/arch/msg/tls/up7R6EuAaEHnAeKlOR_f-AD_PvE/ [8] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/ [9] https://mailarchive.ietf.org/arch/msg/tls/fxM4zkSn0b8zOs59xlH6uy8P7cE/ [10] https://mailarchive.ietf.org/arch/msg/tls/T3nlmtNL_TxkEle7AyQKNSC6A4A/ [11] https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/ [12] https://mailarchive.ietf.org/arch/msg/tls/XslyAL38dELwe-5ueVXLdDx-Y7s/ _______________________________________________ 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 mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
