[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implied NSEC3 support in rsasha256 (was: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05)
In message <493FE3B6.5020807@NLnetLabs.nl>, Jelte Jansen writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Koch wrote:
> >
> >> gone back through the mailing list to examine the record, I strongly
> >> oppose its conclusion. The language regarding NSEC3 support from the
> >> -05 version should be restored and we should not continue the
> >> unnecessary practice of algorithm aliases.
> >
> > I agree that we should refrain from the continued algorithm aliasing, but
> > would like to propose a slightly different solution. The draft should go b
> ack to
> > two instead of four algorith numbers. The text regarding NSEC3 should
> > be clarified around 'support' and 'recognition'. RFC 5155 pretty well
> > documents the need for aliases, but it didn't make the step forward
> > explaining why this won't set precedent for future extensions.
> > Therefore, we should document, maybe in DNSSECbis-Updates, the decision and
> > the reasoning, so it's available for similar situations in the future.
> > Note that we might also want to strongly recommend NSEC3 as part of DNSSECb
> is
> > there, but these are separate issues.
> >
>
> heh :)
>
> in waiting for the chairs, i preemptively wrote this earlier today:
>
>
> 5.2. Support for NSEC3 Denial of Existence
>
> Note that these algorithms have no aliases to signal NSEC3 denial of
> existence. The aliases mechanism used in RFC5155 was to protect
> implementations predating that RFC from encountering records they
> could not know about.
>
> Implementations that support RSA/SHA-2 algorithms SHOULD also
> implement NSEC3 denial of existence [RFC5155].
>
> If an implementation chooses not to support NSEC3, it MUST at the
> very least recognize NSEC3 Resource Records and treat any zone that
> uses those as unsigned, after verifying the signatures on those
> records.
Authoritatives servers is SHOULD. This allow for NSEC only servers.
Validators is a MUST. A validator needs to be able to handle either
NSEC or NSEC3 record or it need to treat the zone as insecure.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkk/47UACgkQ4nZCKsdOncUi1gCgyjNixFJLP9DAlbB5rvK6jA5V
> MXkAoM1S8XPMBIGAWgKFznUMRZZYwMxs
> =CV8x
> -----END PGP SIGNATURE-----
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>