On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie > wrote:
> > > > It is odd ... and I'm being deliberately provocative to get at the > > doublethink. It is impossible to consider this mode wiretapping and not > > claim the browsers support it today. Plainly, they do. > > In what sense does a browser "support" a server leaking a private > key via some proprietary interface? That makes zero sense to me > and seems sheer hyperbole, as you said yourself. And not useful. > I think it's most useful to focus on the real world, and what works and doesn't work in the real world, and the implications for user security, again in the real world. I don't think it's useful to engage in disconnected arguments and debate that lack that focus. In the real world, the kind of wiretapping you are talking about works today, people are using it, so plainly it is supported. Let's stay grounded in that reality. > happening, and is not already possible. > > When using crypto in a network protocol, it is impossible to know > or not know that a peer is implementing crypto well or badly. > It absolutely is possible to know that a peer is implementing crypto badly; for example if they use RC4, or have static DH parameters, those can be detected. I can't fathom why those concerned with the problems of static-DH are not advocating for dynamic-DH as a requirement. At a minimum that seems like the most concrete real-world action that will prevent it. If nothing is done, then static-DH remains possible. > > It will also continue to be > > possible to MITM traffic, if you have the RSA key, and some dh-static > > opponents even advocate for this. I have seen no intellectually > consistent > > explanation for why that is ok, > > I never said it was "ok." I said it wasn't part of the TLS RFCs. > > The point here is to not specify mechanisms that enable wiretapping > to the extent that is feasible Two observations: 1. as static-DH makes plain, TLS1.3 continues to enable this kind of wiretapping. Are you proposing a modification? Do you then agree with my suggestion that static-DH be actively forbidden and that clients can reject duplicate DH params? 2. My concern is to specify things that will improve real-world security. This should always be our goal. (you seem to assume that all uses > of crypto "support" wiretapping, since it's always possible for an > implementation to leak keys - that's gibberish IMO, but I'm using > the term in your sense in this paragraph). That's not gibberish and it's a really really important point. It *is* always possible to leak keys, or plaintext. We can't ignore that. That's part of the security model. Our task is then to make it as unlikely as possible and to accommodate the needs of users in ways that discourage it. > why that won't be abused by coercive > > authorities, > > It could be. It'd still be abuse IMO. > I think it's a lot less likely that signaled, opt-in, infrastructure would be used by coercive authorities. It works ok in the corporate cases, where they control both ends, but for the coercers, they couldn't just show up and say "Use a static DH and give us the key" to anyone. Instead they'd have to say "enable this option that browsers don't enable by default". This doesn't seem realistic. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
