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
