BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] free SSL certs from the EFF
- Subject: [Discuss] free SSL certs from the EFF
- From: warlord at MIT.EDU (Derek Atkins)
- Date: Wed, 03 Dec 2014 10:52:49 -0500
- In-reply-to: <547E0FB3.3070005@gmail.com> (Richard Pieri's message of "Tue, 02 Dec 2014 14:14:59 -0500")
- References: <546C4823.6060900@gmail.com> <BN3PR0401MB1204BAB10AE6249C54E4E81BDC760@BN3PR0401MB1204.namprd04.prod.outlook.com> <54737E7C.5040506@mattgillen.net> <BN3PR0401MB1204CDD16766109B0CD095ECDC730@BN3PR0401MB1204.namprd04.prod.outlook.com> <sjm8uirdxem.fsf@securerf.ihtfp.org> <BN3PR0401MB1204B299B351DFF7F2E85FBDDC7D0@BN3PR0401MB1204.namprd04.prod.outlook.com> <sjmlhmqcb1j.fsf@securerf.ihtfp.org> <BN3PR0401MB120492A5BDE4D3CEE0AECDD3DC7A0@BN3PR0401MB1204.namprd04.prod.outlook.com> <sjm8uiqc7sw.fsf@securerf.ihtfp.org> <547E0FB3.3070005@gmail.com>
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
- Follow-Ups:
- [Discuss] free SSL certs from the EFF
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] free SSL certs from the EFF
- References:
- [Discuss] free SSL certs from the EFF
- From: warlord at MIT.EDU (Derek Atkins)
- [Discuss] free SSL certs from the EFF
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] free SSL certs from the EFF
- From: warlord at MIT.EDU (Derek Atkins)
- [Discuss] free SSL certs from the EFF
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] free SSL certs from the EFF
- From: warlord at MIT.EDU (Derek Atkins)
- [Discuss] free SSL certs from the EFF
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] free SSL certs from the EFF
- Prev by Date: [Discuss] free SSL certs from the EFF
- Next by Date: [Discuss] free SSL certs from the EFF
- Previous by thread: [Discuss] free SSL certs from the EFF
- Next by thread: [Discuss] free SSL certs from the EFF
- Index(es):
