On Thu, May 23, 2024 at 4:14 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> 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 your messages what root program policies are preventing the additional use of cross-signed certs, nor can root programs compel CAs to make business decisions Trust Expressions doesn't require any business deals that aren't needed today. Today, when a new CA operator commences operations, they generally make some sort of business deal with an incumbent CA to get a cross-signed cert. In a Trust Expressions world, a new CA could still do that. Trust Expressions opens up additional opportunities for a subscriber to have business relationships with multiple CAs, but it doesn't require this. You argue that Trust Expressions only moves the pain up the stack without solving anything. Trust Expressions provides an off-ramp for servers to reduce the pain of fingerprinting and other techniques to support a diverse set of clients, and adds no additional pain for the servers that are not facing this pain. Trust Expressions allows for a quicker transition to PQC PKI. In [4], you suggested the opposite, asking "why not let someone else go first and pave the way?". I answered this in my reply [5], and now you're changing the question to the long tail of CAs. The factors that will move the long tail are server demand and eventually root program or browser requirements that drop support for classical CAs. The long tail is a problem for holding back the rest of the ecosystem when there's no trust negotiation mechanism, but when such a mechanism is present, it helps new things (e.g. PQC) get adopted faster, without needing to wait for the long tail to catch up to a point where there is intersection between the new technology and the long tail. When I say that Trust Expressions allows servers to be more confident that they are using a certificate chain trusted by their clients, I mean that at the time that the server selects which certificate chain to use, it has a very high degree of confidence that the client will trust it. You're right that in the present day the server might be able to infer whether the chain is accepted or not based on connection success, but that is too late! The server doesn't know if the connection failed because the cert is bad, a network issue, the client canceling a request, or any other number of reasons. Trust Expressions provides visibility into the failure reason, allowing site operators to see if there are particular trust stores used by clients that are failing to connect. I believe I have responded to your comments regarding the problem that Trust Expressions solves. To recap, the problem here is a server knowing which of its multiple certificate chains to use. Do you think this problem is worth solving and is better solved by technologies other than Trust Expressions, or do you think this problem is not worth solving or doesn't exist? Cheers, Nick [1] https://mailarchive.ietf.org/arch/msg/tls/nbJOdcbB_0UsqJllj4rLwDdaze8/ [2] https://mailarchive.ietf.org/arch/msg/tls/T3nlmtNL_TxkEle7AyQKNSC6A4A/ [3] https://mailarchive.ietf.org/arch/msg/tls/up7R6EuAaEHnAeKlOR_f-AD_PvE/ [4] https://mailarchive.ietf.org/arch/msg/tls/XslyAL38dELwe-5ueVXLdDx-Y7s/ [5] https://mailarchive.ietf.org/arch/msg/tls/GTTEnFl7f3xgtcviVwME6lr-RJc/
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
