Sorry, the more I think about how to do this in a way that doesn't make things worse, the less faith I have that it is possible. But if you know of a way to do it, I certainly don't oppose you doing it. I'm not an expert: the fact that I don't see how to do it doesn't mean it can't be done.
On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > 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
