On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon <mel...@fugue.com> wrote:
> 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. > I think it was Nick who had the idea of adding a message to the TLS transcript that encrypts the PMS or session key under a public key. This had some advantages: * Static-DH can be banned and clients can check for changing DH parameters. * The technique would be signaled and opt-in to clients; they can terminate the connection if they don't want it. Clients could insist on being configured to support it, not support it in incognito mode, etc. * The PMS/key could be encrypted under a different key than the key pair used to authenticate the server; this means that the servers needn't have a key that can decrypt these transcripts. It can be kept offline. It also means that the investigation team needn't have access to the servers certificate private key. Much better all-round. * Still can work with tcpdump/wireshark etc, but not very useful to three letter agencies, etc. > > 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 >> > > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
