------ Original Message ------
From: "Stephane Bortzmeyer" <[email protected]>
To: "Adrien de Croy" <[email protected]>
Cc: "[email protected]" <[email protected]>; "Paul Hoffman"
<[email protected]>
Sent: 7/05/2016 10:10:35 p.m.
Subject: Re: [DNSOP] New Version Notification for
draft-song-dns-wireformat-http-03.txt
On Fri, May 06, 2016 at 07:45:23PM +0000,
Adrien de Croy <[email protected]> wrote
a message of 84 lines which said:
when there were no MitMs, (discounting crytpo algorithm downgrade
attacks against SSLv2) you could consider https to be secure
(integrity and privacy).
Apparently, you have an analysis of TLS which is quite at odd with
everyone else in the security world. TLS *is* secure against MitM
(otherwise, there would be little reason to use it). I agree with Paul
Hoffman: your objection against the current text is groundless.
So I'm not sure what you're saying here - that there are no MitMs? Or
that they aren't a problem for integrity?
Or that theoretically if anyone actually implemented the full suite of
options in TLS then it would not be able to be MitMed?
And it's not a problem of the protocol that nobody does the checks?
Now you can expect in a corporate network to be surfing through a
https-inspecting proxy where neither integrity nor privacy is
guaranteed in any strict sense,
Because the end host is controlled by the same organisation as the
interceptor
no, this virtually never happens. We don't control google.com, but we
intercept it.
. Saying that TLS is vulnerable to MitM because of this
case is like saying TLS is vulnerable because, for instance, a program
did not bother check the certificate
exactly. No mainstream browsers do. Am I imagining this?
Just to be clear, client certificates will prevent this kind of thing,
but they are also pretty much unworkable due to the prohibitive
logistical deployment problems.. Which is why even banks don't use them
for online banking.
To claim this as the thing which makes TLS secure against MitM is
therefore disingenuous. Or are you claiming something else?
<https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
Browsers still happily show their little green lock icon. Sure they
have to accept the signing cert first, and that tends not to happen
unless you're in a corporate network, or some countries I believe
have now mandated acceptance of a cert or are looking at that.
If someone (your company or other) can add a cert to your cert store,
it can do what it wants. This has been known from the beginning of
public-key cryptography. In a typical corporate environment, the IT
department install all the software, anyway, and can even install a
browser which does not check certs, as well.
sure.
So we are left in the situation where users don't really know if
they have security or not, and the green lock icon is untrustworthy.
If you don't control your machine (if someone is administrator and you
are not), all bets are off. Again, this is well-known for a very long
time and you add no new information.
If "adding new information" is a requirement, then definitely should
strike the sentence from the RFC, because we don't need to be told again
that TLS gives us integrity and privacy. That's no new information
either, regardless of whether it's true or not.
Adrien
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
