Re: [dnsext] RSA/SHA2 new NSEC3 text proposal

[Alex Bligh <alex@alex.org.uk>]

--On 16 December 2008 11:12:25 +0100 Jelte Jansen <jelte@NLnetLabs.nl> 
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Ok, i've refined the text a bit, and made two possible versions of 5.2.2
> for the validator part, see below.
>
> There is the scary variant of my previous text, with a little
> explanation on why it's a bad idea, and the version like Mark proposed,
> which is safe and secure (but more of a burden on people who for
> whatever reason would think that you don't need nsec3 validating code).

Some language nits follow whilst I think about the substance


> 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].

Fine if we go with the first alternative, but if we go with the
second, it's a MUST for validators, in which case this sentence would
be better under 5.2.1 (else I think we have a MUST and a SHOULD for
the same thing).

> 5.2.1.  NSEC3 in Authoritative servers
>
>    An authoritative server that does not implement NSEC3 can still serve
>    zones that use RSA/SHA2 with NSEC.

Should that "can" be "MAY"?

> And one of these:
>
> 5.2.2.  NSEC3 in Validators
>
>    If a validator chooses not to support NSEC3, it MUST recognize NSEC3
>    Resource Records and treat any zone that uses those as unsigned,
>    after verifying their signatures.  This does, however, make you
>    insecure for negative answers within the zone, and is not
>    recommended.

I think this should read "This does, however, mean the validator
will respond insecurely for".

I am presuming the "and is not recommended" really refers to the same
recommendation that "Implementations that support RSA/SHA-2
algorithms SHOULD also support NSEC3 denial of existence" above,
as opposed to being a separate standalone recommendation for
validators only; if so, I think the wording could be improved
by "and it is for this reason that lack of support for
NSEC3 is not recommended".

IE I think the whole sentence should read:
 This does, however, mean the validator will respond insecurely for
 negative answers within the zone and it is for this reason that lack
 of support for NSEC3 is not recommended.

> OR
>
> 5.2.2. NSEC3 in Validators
>
>    A DNSSEC Validator that implements RSA/SHA2 MUST be able to
>    handle both NSEC and NSEC3 negative answers. If the validator is
>    not able to handle both, it MUST treat a zone signed with
>    RSA/SHA256 or RSA/SHA512 as insecure.

I think there is a logical error here, if the requirement is that
it MUST handle *both* NSEC and NSEC3, the final sentence should surely
read "If the validator is unable to handle *either*. To my knowledge,
a validator that is unable to handle both is not a DNSSEC validator
at all.

The last sentence might be improved as "it MUST treat a zone signed
with RSA/SHA256 or RSA/SHA512 as signed with an unknown algorithm,
and thus as insecure".

There should be a reference to RFC5155 as per your first alternative.


Alex

--
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/>