On 04/27/2016 08:46 AM, Valeri Galtsev wrote:
On Wed, April 27, 2016 10:29 am, m.roth@5-cent.us wrote:
Alice Wonder wrote:
On 04/27/2016 01:21 AM, Brandon Vincent wrote:
On Wed, Apr 27, 2016 at 1:10 AM, Rob Kampen rkampen@kampensonline.com
wrote:
Sounds good, but how many domain MX servers have set up these fingerprint keys - 1%, maybe 2%, so how do you code for that? I guess
I'm thinking
it uses it if available. So even if you do post it on your DNS, how
many clients out there are using DANE on their set up? By the time it becomes more than a tiny % and generally useful, it will be in CentOS 8. It
also requires certificates to be implemented more ubiquitously than at
present - although we do now have affordable solutions, so this one may resolve
more quickly.
Security and Privacy on the Internet are both severely broken.
If you read the white papers from when the Internet was first being
designed, security was rarely even mentioned.
<snip> Just as a point of information, when those RFCs were written, the Internet was *only* for US gov't, and selected research and educational organizations, and NO ONE else. The open 'Net only came in in the nineties - so security wasn't broken and insecure, back then there was physical security and careful selection as to who was allowed on, at all.
That is true, they had in mind resilience of communication net to portions of it brought down (implying some nasty thing like nuclear exchange). Real security though is not in restriction of those who can access something (like government only). Security experts often say: if a secret in known to two people it likely is not a secret anymore ;-(
Yes, but that is why we need to focus on fixing it from the ground up - and that means DNS needs to be secured.
DNSSEC is not perfect, but I don't think there is anything that is truly perfect. Even "perfect forward secrecy" is not perfect (DHE should not be used with DH groups < 2048bit)
But to secure the Internet, one must be able to validate DNS responses and that requires DNSSEC.
To secure TLS, one must be able to validate the certificate and that requires DANE - we know Certificate Authorities can't be trusted.
So "Enterprise" or not, system administrators need to be implementing both of those - and mail servers should be making use of DANE records when they do exist.
Even if it means bumping a software version.
-=-
Illusion of security where it doesn't exist is dangerous, so deprecated protocols and cipher suites should not be supported, even if that means some e-mail messages end up sent in the plain.
But TLS libraries and software that uses them should be updated to support modern cryptography, even on Enterprise distributions, to avoid that.
That's my philosophy.