On 04/27/2016 08:46 AM, Valeri Galtsev wrote:
On Wed, April 27, 2016 10:29 am, m.roth@xxxxxxxxx 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@xxxxxxxxxxxxxxxxx>
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
