------ Original Message ------
From: "Paul Hoffman" <paul.hoff...@vpnc.org>
To: "Adrien de Croy" <adr...@qbik.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 7/05/2016 7:24:46 a.m.
Subject: Re: [DNSOP] New Version Notification for
draft-song-dns-wireformat-http-03.txt
On 6 May 2016, at 12:14, Adrien de Croy wrote:
The original text makes a claim about security and privacy around TLS.
This is not true in the real world, and is becoming less true with
every MitM deployed.
It is as true now as it has ever been.
no, that's incorrect. when there were no MitMs, (discounting crytpo
algorithm downgrade attacks against SSLv2) you could consider https to
be secure (integrity and privacy).
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, and that's the only way the proxy can cache and
scan for malware.
So over time anyone's expectations of integrity and privacy if they know
what's going on is actually reducing. Setting an expectation about
security and privacy in an RFC is therefore IMO not justified. I'd just
propose removing the statement since this is about DNS over HTTP.
If you want to hear this argument from many major proxy vendors go look
in the httpwg archives.
Saying that TLS is not secure because there are environments where
users can be tricked into lower security is silly in that that same
statement is true of every security protocol.
I'm not talking about downgrade attacks, I'm talking about proxies
spoofing certs.
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 the user knows the proper cert chain, they can look up the chain for
the site they are on and determine it ends in their company's spoof cert
signing cert, and then know they were intercepted. Extremely few users
know or bother to do this.
Proposals were made to allow browsers to know when they were being
intercepted (special attributes in certs or otherwise "trusted
proxies"), but these were rejected by the TLS people and browser people.
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. So
we're currently following the ignore the problem strategy.
Anyway, I encourage people to look through the httpwg archives. There
you'll see these arguments also put by the authors of Squid, Varnish,
NGinx, Checkpoint, and myself among others.
Adrien
If you want to propose a document to the IETF that says "TLS (and all
other security protocols) should not be considered secure because users
can be tricked", do so in SAAG.* It's not appropriate for a
foo-over-TLS protocol document.
--Paul
* I doubt that such a document will be well received, but I have been
wrong about these types of predictions often.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
