Re: [TLS] datacenter TLS decryption as a three-party protocol

[BITS Security <[e-mail]>]

> 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.

+1 and this is fundamentally why we’ve made significant effort to work within the IETF process.  We strongly believe a consensus outcome will be better for all, including those who are currently in disagreement.  What we’d like to avoid is being told the solution is to ignore (or admire) the problem.  Finding a workable solution will reduce the risk of forking TLS and will increase the broad adoption of 1.3.

-Andrew



From: TLS [mailto:[e-mail]] On Behalf Of Colm MacCárthaigh
Sent: Wednesday, July 19, 2017 1:45 PM
To: Ted Lemon <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol



On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <[e-mail]<mailto:[e-mail]>> 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