[dnssec-deployment] aug2004 CAM of interest?
davidb at verisignlabs.com
Tue Aug 17 17:15:00 EDT 2004
On Tuesday 17 August 2004 4:09 pm, Edward Lewis wrote
> At that time, the specs allowed the zone admin to choose to sign
> everything else in the zone with just Y. How does the validator
> detect that the absence of an X signature is 1) by admin choice or 2)
> a stripping attack?
> I don't know if the proposed solution made DNSSECbis. How realistic
> is this? Imagine X as a current mandatory to implement algorithm and
> Y as a replacement for a broken X. If this isn't fixed, then we
> could wind up with confused validaters.
I believe the DNSSECbis documents solve this problem:
From draft-ietf-dnsext-dnssec-protocol-07, section 2.2:
There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any).
And in section 5.2:
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
I remember testing this behavior in some snapshot of BIND 9.3 at one of the
Amsterdam workshops (although, my tests weren't what you would call
*thorough*), and noting that it worked.
> Multiple algorithms and mixing mandatory-to-implement with
> experimental algorithms is a box owned by Pandora.
Handling this looked pretty straightforward to me, but perhaps I am missing
David Blacka <davidb at verisignlabs.com>
Sr. Engineer VeriSign Applied Research
More information about the Dnssec-deployment