Hiya,
I still need to re-read the trust expressions docs, though my sympathy remains with Dennis' arguments so far. That said, and independent from the rest of the discussion, FWIW I don't think the particular argument below is sound. On 20/07/2024 00:05, Ryan Hurst wrote:
It is also worth noting that RFC 7258 on preventing pervasive monitoring has been cited several times as part of the arguments against Trust Expressions. However, it clearly states: Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF.
In context, that's part of: Finally, the IETF, as a standards development organisation, does not control the implementation or deployment of our specifications (though IETF participants do develop many implementations), nor does the IETF standardise all layers of the protocol stack. Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF. The broader Internet community will need to step forward to tackle PM, if it is to be fully addressed. I do not think that was intended as saying the IETF ought not think about protocol changes that might be (ab)used for legal or political reasons. Rather it was saying that we need to ack that we (the IETF) don't have control, but need to work with others to counter PM.
Speculation about how a server negotiation mechanism or server deployment of an otherwise untrusted government CA might later affect a root store's decision to include that CA, and whether or not that will make it easier to then pass laws preventing the distrust of that CA, seems fully into the legal and political aspects of mitigating pervasive monitoring and has nothing to do with the technical details of the client trust store and not Trust Expressions.
I fully disagree. As we're defining new things, we really should consider how those can be abused, generally, including by those with purely legal or political goals. If 7258 says anything, it says we've agreed that we will think about such potential issues. Cheers, S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
