On Mon, May 20, 2024 at 7:26 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote:
> Compared to the alternatives, Trust Expressions seems to solve the > problems less effectively and introduce much greater risks. If you really > feel the opposite is true, I would strongly encourage you to: > b) Make a good faith attempt to engage with the concerns raised about the > risks. Think through how a party with different goals to your own could > exploit the negotiation offered by Trust Expressions for their own > purposes. If your goal was instead to enable surveillance and domestic > control of the web for your government, how would widespread support for > Trust Expressions help you? > If an attacker's goal is to surveil the web (i.e. get the plaintext of selected HTTPS connections), they can MitM the connection, log the traffic keys for the connection, or have one of the parties (client or server) with access to the plaintext send me the plaintext. Only the first option, a machine-in-the-middle attack, involves the Web PKI - the rest can be done regardless of the certificate chain served by the server or verified by the client. In a world without Trust Expressions, the surveillor performing a MitM attack needs to get the client to trust the certificate chain presented by the MitM. It could do this by asking the user to add its root to their browser's trust store (e.g. like Kazakhstan does), or by coercing the browser vendor to add the surveillance root to the browser's trust store. In this world, it doesn't matter what certification authority the server being MitMed is using. In a world with Trust Expressions, the above scenario is still possible and it is unchanged by the presence of Trust Expressions: The client still has added the surveillance root to its trust store, the MitM is still generating or using a cert issued by the surveillance root, and the server being MitMed can serve whichever of its certificate chains to its end of the MitM. (Presumably the MitM either doesn't advertise Trust Expressions in the ClientHello it sends to the server, or it advertises the same one sent by the client so as to keep a low profile of being detected by the server.) Trust Expressions appears to open up a new attack vector that involves coercing clients to trust a new root, and also coercing servers to support using a cert issued by that root (when connected to by a client that trusts that root, and using another cert chain on other connections). This scenario requires the attacker to coerce a superset of the parties involved in the previous scenario, and includes an additional step that is unnecessary. Coercing the server to use a different cert chain (only when the client trusts it) does nothing to facilitate the attacker from getting the plaintext of a connection from that server. The attacker still needs to MitM that connection with an attacker controlled leaf certificate because it doesn't know the private key of the certificate used by the server. The technical attack of surveilling a connection looks the same regardless of whether Trust Expressions exists: The surveillor coerces clients into trusting its surveillance root, and creates certs issued from that root to MitM connections. Trust Expressions might make it more palatable for this attacker to coerce servers to use a cert issued by their surveillance root (when trusted by clients, and another cert for other clients), but doing so is unrelated to connection surveillance and is separable. A government using Trust Expressions for domestic control of the Web is a very broad and vague topic. The only two examples of end goals for domestic control of the Web that I can think of right now are for surveillance and censorship. Surveillance was discussed above and Trust Expressions provides no additional benefit for surveillance over the status quo. For censorship (that does not involve viewing the plaintext of connections - that requires surveillance), there's a broader space to explore. Today, countries can censor sites by DNS hijacking, IP address blocking, and SNI inspection, to name a few technologies. Those options remain unaffected by Trust Expressions. A government might try to convince/coerce websites that operate within its jurisdiction to use a certificate chain issued by a government CA when clients within the government jurisdiction connect. Then, somehow, the government technically enforces this requirement, and if a site serves objectionable content, the government revokes the site's cert (or opts not to renew it). I'll assume that this technical enforcement is only for domestic connections, where the government has hypothetical control over both endpoints. Enforcing that all ClientHellos have a trust expression for a root store that includes the government CA is insufficient (and implausibly impractical, e.g. people visiting from other countries). The enforcement can't look at the cert used per-connection and block if the cert isn't issued by the government CA, as that's encrypted in TLS 1.3. They could instead do spot-checks on servers by making their own connections and observing certificate chains, and if the server is using a chain from another CA, they could block connections to that IP address. This sounds like a more complicated, more hostile, and less plausible version of IP address blocking (which is what this ultimately is) to censor sites than the approaches currently used by some governments for censorship (which includes IP address blocking). Perhaps there are additional ways to use Trust Expressions to censor the web that are more practical and more useful than the existing techniques that I didn't consider. There are most certainly other forms of domestic control of the Web that I didn't consider. From my analysis, if I were a government looking to enable surveillance and domestic control of the Web, I don't see Trust Expressions as something that unlocks new options or makes existing techniques easier/more reliable. It is at most something to keep in mind as technology evolves. Maybe I'm not very imaginative, and you've imagined much more interesting ways a government might surveil the web or attempt to control it using Trust Expressions. I'd be interested to hear details on what those are. >From a process perspective, considering how a technology could be abused is important and should be addressed to a reasonable level in the RFC. I don't see a need for this to be fully fleshed out with every possible abuse considered and discussed in an individual Internet-Draft.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
