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

["David A. Cooper" <[e-mail]>]

Everything I have stated is my personal opinion.

Note that I never suggested that I like or am espousing a certain 
approach, I was simply stating a fact. In many cases today, a TLS 
connect that appears to a client to be terminating a one place (Company 
X) is actually terminating somewhere else (Hosting Provider Y) without 
any clear indication to the client that the connection is terminating at 
Hosting Provider Y. Nobody has suggested that this is unacceptable or 
that TLS is broken if it can't prevent that.

TLS is not an end-to-end protocol, it is a point-to-point protocol, and 
as noted in hosting company example, which you claim to find so 
troubling, it isn't always clear to either party what's at the other end 
of the connection. It might be the entity the client thinks its 
connecting to (Company X), it might be a hosting provider acting on 
behalf of Company X, or it might be something else. The best the client 
can hope for with things like TLS, PKIX, TRANS, etc., is that the server 
end of the connection is either Company X or some entity authorized by 
Company X to act as Company X for the purpose of being the connection 
endpoint (and, yes, Company X may have been coerced into authorizing 
some other entity to covertly act as the server endpoint). I am not 
saying that I like this or am "espousing" it, I am simply pointing out a 
fact.

Similarly, the best that TLS can offer in terms of privacy is that the 
contents of the communication between the two endpoints is not seen by 
anyone else *unless* at least one of the two endpoints (client or 
server) chooses to provide the contents of the communication to some 
other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

It is also a fact that once a client provides data to a server, there 
are no technical mechanisms that would allow the client to limit what 
the server does with that data. As has been show over and over again, 
including by you, it is very frequently the case that the server that 
initially receives the data passes it on to others. The others may be 
back-end database servers or anti-virus scanners, but the client has no 
control over what happens to the data once the server receives it.

I have not tried to argue that draft-rhrd-tls-tls13-visibility is the 
best solution for addressing the need for visibility within the data 
center. Perhaps it is, perhaps it isn't. But, I'm tired of the abusive 
and false suggestions that draft-rhrd-tls-tls13-visibility is a 
"wiretapping" draft or that it is defining a "please-screw-me 
extension." These suggestions have been repeated over and over again, 
even though they have already been countered effectively - "repeating 
points already countered is just disruptive noise."

On 10/24/2017 10:13 PM, Stephen Farrell wrote:
> 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.
>