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
