[Discuss] free SSL certs from the EFF
Derek Atkins
warlord at MIT.EDU
Wed Dec 3 10:52:49 EST 2014
Richard,
Richard Pieri <richard.pieri at gmail.com> writes:
> Derek,
>
> According to the DNSSEC specs, if there is no RRSIG record in the
> lookup answer then a properly behaved resolver will treat it as
> unsigned. Backwards compatibility with so-called insecure DNS is an
> explicit requirement of DNSSEC. So, what happens when a malicious
> actor inserts filters at an intermediary resolver or router that strip
> RRSIG records from DNS answers?
Which RFC states this? I'm quite familiar with 4033 et al, (and even
moreso with their predecessors, 2535 et al). Granted, I did stop
following the specs somewhere around the NSEC3 discussions, but it was
certainly the case that a DNSSEC-aware resolver would always know
whether to expect signed data. I.e., if there is no DS record for the
zone then a DNSSEC-aware resolver knows it's not a signed zone. If
there IS a DS record for the zone and then a query does not return an
RRSIG or NSEC then there's a problem (verification failure).
Obviously a non-DNSSEC-aware resolver doesn't care.
> DNSSEC was never intended to protect you against that. It was designed
> to protect high-level caches -- root zones, ISP's, big data players,
> private networks, and the like -- from cache poisoning. That's it. Any
> benefits that might trickle down to you are incidental.
Actually, it was designed to protect against that. I sat in the
IETF meetings where that was explicitly discussed. If an intermediary
strips the DNSSEC records out then a resolver expecting DNSSEC will
force a validation error.
> Never mind that DNSSEC has no means of rolling over the root KSKs. If
> a root is compromised then the whole domain hierarchy is compromised
> and there currently is no way to fix that other than disabling DNSSEC
> for the hierarchy or accepting loss of service for everything under
> that root.
Well, it sort of does, but it's not easy. But this is why they use
ZSKs. The Root Zone KSK is mightily protected.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the Discuss
mailing list