On Jul 23, 2017, at 15:37, Ted Lemon <mel...@fugue.com> 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.
That is clear and AFAIK unavoidable. And not my (main) concern. What I am trying to avoid is the ability to *surreptitiously* subvert a protocol that’s assumed to be secure. IMHO it is fine if one end-point is faced with a choice of either agreeing to an “eavesdropping” connection or aborting because of no (remaining) common cipher-suites. What I don’t want to see is one end negotiating a connection that “should” be secure based on the exchange parameters, but in fact leaking keys… What I want in such a case is a negotiation that clearly states what has been done. Then the end-point would make a conscious decision to either connect and access data despite being surveilled, or avoid both surveillance and service. > Of course the far end can just not downgrade, but it may have downgrading > enabled either for debugging purposes, never intending that all connections > be downgraded, or because the operator didn’t configure the server correctly. > My main concern is the “invisible” downgrade (that the operator has no say about), not an operator error. > If it’s not in the standard, it can still be enabled by operators who are > violating the end user’s trust, but won’t happen by accident and won’t be > possible to coerce with a MiTM attack. I see your point. I don’t share your concern, but don’t object to it either.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
