Ben, In the scenario you outlined below, it seems the third party has significant control over the communications of the clients (e.g. national border firewall). In addition, based on your description, it seems they are intent on ensuring that not communications occur unless they can view the communications. In addition, they must be able to coerce the server owner into providing the key (because the proposed method requires opt-in by both the client and the server). This is a significant amount of control that the third party wields.
In this scenario, wouldn't the state firewall simply require all clients to trust their CA so that they can reverse proxy all communications--since they will likely not only be interested in one server's communications but many? It seems important to keep in mind that each server that a third party wants to listen in on must agree to enable it (opt-in). It would seem that a state run firewall is unlikely to get that agreement from a broad number of servers of interest. And, as you point out, each client will know they're being forced to agree that the third party can listen in on communications (if they choose to continue to communicate with the server). In countries where it is possible to challenge such coercion in a court of law, the client will know they are being forced and can challenge that (or more likely the industry can provide pressure). This method seems to protect against someone like the NSA secretly coercing a server owner into opting in without the knowledge of the cl ient (and the broader community). I guess the basic question I'm asking is that if a third party is so powerful that they can do what you describe, aren't they going to force an even more effective method (trusting their CA so that they can terminate the connection as a middle man) on clients so that they don't have to coerce every server? Thanks, Paul -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Benjamin Kaduk Sent: Wednesday, October 18, 2017 13:42 To: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On 10/02/2017 03:31 PM, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS > extension defined in this I-D takes into account what we heard from the > discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 > in Prague. Specifically, it provides an opt-in capability for both the TLS > client and server and makes it clear on the wire that visibility will be > enabled for the session. The new mechanism does not depend on static > handshake or session keys. > This draft does not seem to have anything to address the concern that, once a visible ClientHello extension is needed to enable wiretapping, certain parties (e.g., national border firewalls) would reject/drop *all* ClientHellos not containing that extension, thereby extorting all clients into "opting in" to the wiretapping and effectively rendering the "opt-in" requirement useless for those clients. As a more general comment, I think that this concern is so squarely at odds with the concern that the client must be able to opt-in to the wiretapping [and, optionally, be guaranteed by the key schedule to know when wiretapping is happening] that I do not see any potential for a workable solution. -Ben P.S. I agree with Rich; can we try to defer these conversations until after 1.3 is actually published? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
