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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
