On 11/25/2014 06:28 AM, Edward Ned Harvey (blu) wrote:
From: [email protected] [mailto:discuss-
[email protected]] On Behalf Of Matthew Gillen
This is not without new attack vectors: you can only trust DNS responses
as far as DNS-SEC goes, which unfortunately ends one-hop before
end-systems (unless you run your own DNS server and force everything on
your home network to use that; which I do but don't know how common
that
is).
Based on my understanding of DNSSEC, it doesn't add security except
in esoteric edge cases. Because your client doesn't have any point
of trust -
That's what I meant when I said it "ends one hop before end-systems".
if your client queries DNS, there's no way for your client
to know *this* response is authentic for your domain.
I won't put the quoted part below in my own words:
https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
By checking the digital signature, a DNS resolver is able to check if
the information is identical (i.e. unmodified and complete) to the
information published by the zone owner and served on an
authoritative DNS server. While protecting IP addresses is the
immediate concern for many users, DNSSEC can protect any data
published in the DNS, including text records (TXT), mail exchange
records (MX), and can be used to bootstrap other security systems
that publish references to cryptographic certificates stored in the
DNS such as Certificate Records (CERT records, RFC 4398), SSH
fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC
4025), and TLS Trust Anchors (TLSA, RFC 6698).
If it can be used for SSH fingerprints and IPSec public keys, it can be
used for CA certs...
Matt
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
