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

From: Jelte Jansen <[email-masked]>
Date: Tue, 16 Dec 2008 11:12:25 +0100

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

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

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.

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.

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.

Jelte

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 16 Dec 2008 11:22:40 +0000

--On 16 December 2008 11:12:25 +0100 Jelte Jansen <[email-masked]> 
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

Some language nits follow whilst I think about the substance

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

>    zones that use RSA/SHA2 with NSEC.

Should that "can" be "MAY"?

>    insecure for negative answers within the zone, and is not

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.

>    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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Dec 2008 00:11:04 +1100

>    RSA/SHA256 or RSA/SHA512 as insecure.

	This version of 5.2.2 reflects what is being signaled. 
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Scott Rose <[email-masked]>
Date: Wed, 17 Dec 2008 08:19:53 -0500

>    implement NSEC3 denial of existence [RFC5155].

I agree with Alex that if we go with option 2 below, that SHOULD would
have to be changed to MUST to keep it consistent.

>    zones that use RSA/SHA2 with NSEC.

I think the can could be changed to a MAY without a problem.  Looking at
RFC 2119 it seems correct.

>    RSA/SHA256 or RSA/SHA512 as insecure.

In the second option, should the validator treat the zone as insecure or
unsigned?  I'm wondering to myself if that really makes a difference.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Dec 2008 10:25:29 -0500

>have to be changed to MUST to keep it consistent.

The problem with that is the scope of the requirement.  Why would an 
authoritative name server implementation have to comply with RFC 5155 
because it wants to use RSA/SHA-2(56)?  (Assuming there is no 
requirement for RFC 5155 in the intended market for the server.)

I could see "Implementations of DNSSEC validators MUST" - provided we 
have defined what a "DNSSEC validator" is.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 17 Dec 2008 15:56:52 +0000

--On 17 December 2008 10:25:29 -0500 Edward Lewis <[email-masked]> 
wrote:

> because it wants to use RSA/SHA-2(56)?  (Assuming there is no requirement
> for RFC 5155 in the intended market for the server.)
>

My proposal, in the event we go with option 2, was to move the 'SHOULD'
recommendation from 5.2 (servers and validators) to 5.2.1 (servers) , as
5.2.2 (validators) already contains a 'MUST' for this. This was to
address the confusion of there being a SHOULD and a MUST for the
same thing for validators.

Or are you arguing that in option 2 there should not even be a "SHOULD"
for servers?

Alex

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Dec 2008 11:03:03 -0500

>Or are you arguing that in option 2 there should not even be a "SHOULD"

Yeah, I suppose.

For a "general purpose implementation" I would use "RECOMMENDED" 
(that a server doing implementing RSA/SHA-2[56] also implement NSEC3).
For a turn-key implementation why does RSA/SHA-2(56) depend on NSEC3?

I don't see a link between the two.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Scott Rose <[email-masked]>
Date: Wed, 17 Dec 2008 13:17:16 -0500

> have defined what a "DNSSEC validator" is.

I always assumed "validator" as used in RFC 4033.  But I see your point
about "implementations"  be too broad.  Perhaps having that statement
only refer to validator implementations?

Scott