On 7/23/2017 12:37 PM, Ted Lemon wrote: > On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL > <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote: >> I think there's no way the connection can be established if the third >> party in control of the network does not allow that. > > This is why it’s hard to reason well about this stuff—we tend to get > the threat models wrong. The attack that negotiating enables is not > that a third party can block all connections. They can always block > /all/ connections. > > What the attack enables is blocking only those connections that don’t > negotiate a downgrade. So if you negotiate a downgrade, you get to > look at your content, but if you don’t negotiate the downgrade, you > don’t. This allows a MiTM to coerce end users into negotiating downgrades.
Speaking of threat model, one of the main threats is the "Lavabit" case: a server is asked to somehow implement a backdoor so existing clients. In that case, it is very useful for clients to detect that something has changed. They can move away and use another server. We are also concerned with the "open library" case, in which the backdoor ends up being implemented by default in popular libraries. If that happens, the backdoor can be instantiated via a simple configuration parameter, and coercion becomes that much easier. Publishing an RFC describing the back door would of course increase the risk that the corresponding code ends in the common libraries, and that is reason enough to not publish such a text. -- Christian Huitema
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
