On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> Certainly, but that doesn't need to happen on this working group, nor > protocols which implement similar solutions need to be called TLS. > I'll belabor this point: rather than thinking about what these providers are owed, which is nothing, it is better to think about what is best for TLS overall. Selfishly, I have a strong preference to see TLS1.3 succeed and that within a matter of years, we no longer have to support TLS1.2 or earlier versions. If some networks and operators feel that they can't feasibly use TLS1.3, they're very likely to stay on the older versions. We could consider brinkmanship; and see who blinks first if we try to disable the older versions anyway, but that's a gambit that often makes hostages out of innocent users, and can end up serving to taint TLS1.3 with reliability issues and hold back its adoption. It's clear that there is a strong distaste here for the kind of MITM being talked about, and many wish not to give it any kind of stamp of approval within the standard; that that itself would also taint TLS1.3 with security concerns. Proxies are proposed as a work-around instead, as it avoids any changes to protocol. But this seems like cutting our noses off to spite our faces. Proxies tend to be always-on and render plaintext much more accessible than a tcpdump tap. Proxies are also inline, read-write, and subject to exploit in a worse way than a tcpdump tap (which can be network isolated). In real security terms, I absolutely buy that proxies would be worse for overall security and all of the properties that TLS is supposed to provide, in some environments. That would seem like a bizarre conclusion. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
