> 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:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Wednesday, July 19, 2017 1:45 PM
To: Ted Lemon <mel...@fugue.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol



On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon 
<mel...@fugue.com<mailto: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

Reply via email to