Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Stephen Farrell <[e-mail]>]

David,

I'll go back over your mails tomorrow but was struck by this...

On 24/10/17 23:39, David A. Cooper wrote:
> I haven't even gotten into the question of what does it mean for a connection to 
> be MiTM'd. If Company X decides to have its web site operated by Hosting 
> Provider Y is the connection between the client and Company X being MiTM'd? The 
> client might think it has a secure end-to-end connection with Company X, but in 
> reality its data is being intercepted and read by Hosting Provider Y, without 
> the client's permission (and most likely without the client's knowledge). How 
> does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be 
> standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.