> I'm not taking any risk. The ability for a server to allow a third party to > have access to data it is exchanging with a client already exists, and that > ability isn't going away whether this proposal (or something similar) is > standardized or not. As I've already pointed out, for the scenarios people > are concerned about, the "attacks" being described would be much more easily > carried out by some means other than draft-rhrd-tls-tls13-visibility.
Yes, you are taking a risk. Or, rather, you are providing a way for any middlebox to force clients to acquiesce. You might think it’s complicated, but it’s not. There’s a perl script in the OpenSSL distribution that does something very similar (look for the TLS Proxy). Servers have always had the ability to share whatever information they want with other entities. We are not trying to change that. What this draft does is force clients to become parties in that interaction and signal in the clear that they are doing so. This is a really fundamental change to TLS. > So, no I am not worried about the "risk" of creating a complicated way for > servers and middleboxes to collude to do something that they can already do > now in a simpler way. I think you’re not getting it. Sorry, probably my fault for not being a very good explainer.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
