On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mel...@fugue.com> wrote:
> The problem is that the actual solution to this problem is to accept that > you aren't going to be able to decrypt the streams, and then figure out > what to do instead. Which is work the proponents of not doing that are > not interested in doing, understandably, and which is also not the work of > this working group. > > I'm skeptical that there is a way for this working group to solve the > proposed problem, but if there is, it involves figuring out a way to do > this that doesn't make it easy to MiTM *my* connections, or, say, those > of activists in dangerous places. > I find this a very bizarre outcome that works against our collective goals. If there is no mechanism at all, then it is quite likely that organizations will use static-DH or stay on TLS1.2. Those are bad options, in my opinion, because there's no signaling or opt-in to the client. We can do much better than that. Client opt-ins are far from academic. For example, browser's incognito modes may refuse to support such sessions, if they knew what was going on. It's also bad if organizations end up deploying static-DH and that means we can't do things like checking for changing DH parameters. It seems like we would be rejecting a good opportunity to make what the network operators want work in a better and more secure way, while making it harder for passive observers and coercive authorities, to use the same mechanism for other purposes. What do we gain? beyond a hollow moral victory. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
