Subject: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05

From: Peter Koch <[email-masked]>
Date: Mon, 15 Sep 2008 15:24:26 +0200

On Thu, Aug 14, 2008 at 06:43:26PM -0400, Andrew Sullivan wrote:

> <http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-rsasha256/>.
> 
> The docment is intended for the standards track, and if adopted will
> become a Proposed Standard.
> 
> Please read the document carefully.  Please send any remarks you have
> about the draft to the working group mailing list.  

apologies for the late reply.  Generally I support this draft, but there
are a couple of issues brought forward by previous reviewers that should be
addressed in a -06 before going ahead.  Find below a step-by-step
walk through, mostly NITs remarks.  Substantive comments deal with NSEC3
signalling (section 5.2) and the IANA considerations section.

-Peter

>  Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records
>                                for DNSSEC
>                  draft-ietf-dnsext-dnssec-rsasha256-05

> 1.  Introduction
> 
>    The Domain Name System (DNS) is the global hierarchical distributed
>    database for Internet Addressing.  The DNS has been extended to use

NIT: Naming, not Addressing -- maybo borrow from other introductory text.

>    cryptographic keys and digital signatures for the verification of the
>    integrity of its data.  RFC 4033 [RFC4033], RFC 4034 [RFC4034], and

NIT: authenticity & integrity

>    Familiarity with DNSSEC, RSA [SCHNEIER-1996] and the SHA-2

Support Paul Hoffman's comment re: the SCHNEIER-1996 reference.

> 2.  DNSKEY Resource Records
> 
>    The format of the DNSKEY RR can be found in RFC 4034 [RFC4034] and
>    RFC 3110 [RFC3110].

NIT: The DNSKEY RR format is exclusively described in RFC 4034, RFC 3110
    deals specificly with RSA/SHA1:

     The format of the DNSKEY RR can be found in RFC 4034 [RFC4034],
     RFC [RFC3110] 3110 describes the use of RSA/SHA1 for DNSSEC
     signatures.

> 3.  RRSIG Resource Records

>    Where XXX is either 256 or 512, depending on the algorithm used.
> 
>    signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)

[...]

I support Alfred's remarks and suggestion.

> 4.  Deployment Considerations
> 
> 4.1.  Key Sizes
> 
>    Apart from prohibiting RSA/SHA-512 signatures smaller than 1024
>    bytes, this document will not specify what size of keys to use.  That
>    is an operational issue and depends largely on the environment and
>    intended use.  Some good starting points for more information might
>    be DNSSEC Operational Practises [RFC4641], section 3.5, and NIST SP
>    800-57 [NIST800-57].

While it has been observed that in DNSOP we're revisiting RFC 4641,
it hasn't been immediately declared void and might well still serve as a
"good starting point".  So I don't feel removing it here is imperative,
neither is keeping it.

> 4.2.  Signature Sizes
> 
>    In this family of signing algorithms, the size of signatures is
>    related to the size of the key, and not the hashing algorithm used in
>    the signing process.  Therefore, RRSIG resource records produced with
>    RSA/SHA256 or RSA/SHA512 shall have the same size as those produced
>    with RSA/SHA1, if the keys have the same length.

NIT: s/shall/will/, but let that to the native speakers.

> 5.  Implementation Considerations
> 
> 5.1.  Support for SHA-1 and SHA-2 signatures

NIT: SHA-1 is no longer dealt with in this section

>    DNSSEC aware implementations SHOULD be able to support RRSIG resource
>    records with the RSA/SHA-2 algorithms.

Problems here are similar to what we've seen with Francis' draft.  I'd
suggest a slightly differrent wording as an emphasis:

     Implementation of both RSA/SHA-256 and RSA/SHA-512 is RECOMMENDED
     for DNSSEC aware software.

> 5.2.  Support for NSEC3 denial of existence
> 
>    Implementations that have support for RSA/SHA-2 MUST also have
>    support for NSEC3 denial of existence, as specified in RFC 5155
>    [RFC5155].

I agree with the spirit, but since there is no immediately obvious
connection between NSEC3 and these two new algorithms, implementors
might deserve some explanation, otherwise this could come as a late
surprise.  If we're saving precious DNS security algorithm numbers,
we can say that ;-)

> 6.  IANA Considerations
> 
>    IANA has not yet assigned an algorithm number for RSA/SHA-256 and
>    RSA/SHA-512.

NIT: Use {TBA1} and {TBA2} here for consistency:
     IANA has assigne DNS Security Algorithm Numbers {TBA1} and {TBA2}
     for RSA/SHA-256 and RSA/SHA-512, respectively.

>    The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended
>    with the following entries:
> 
>                                                Zone
>  Value Algorithm          [Mnemonic]        Signing  References   Status
>  ----- -----------        -----------       ------- ----------- --------
>  {TBA1} RSA/SHA-256       RSASHA256               y {this memo} OPTIONAL
>  {TBA2} RSA/SHA-512       RSASHA512               y {this memo} OPTIONAL

Same problem as mentioned above. The IANA registry at
<http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>
does not have an entry to reflect the "Status" column. Also, traditionally,
the tracking of protocol requirement levels has been an RFC Editor rather
than an IANA task (where "traditionally" the distinction wasn't that strict).
Since this is a reoccuring process issue, I'd suggest we skip the last
column ("extending" an appendix in a remote document doesn't apper the right
approach to me, either) and deal with that issue at a different level.
The Mnemonic definition for the registry is still needed, so that snippet
could describe the registry addition instead.

> 7.2.  Signature Type Downgrade Attacks
> 
>    Since each RRset MUST be signed with each algorithm present in the

NIT: s/RRset/RRSet/g ;-)

>    DNSKEY RRset at the zone apex (see [RFC4035] Section 2.2), a
>    malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the
[...]

> 9.  References
> 
> 9.1.  Normative References

[...]

>    [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
>               Standards (PKCS) #1: RSA Cryptography Specifications
>               Version 2.1", RFC 3447, February 2003.

Is there a standing downref exemption for this RFC?

-Peter

--
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: Jelte Jansen <[email-masked]>
Date: Wed, 17 Sep 2008 15:46:44 +0200

> signalling (section 5.2) and the IANA considerations section.

Thanks for your suggestions, some comments below. I do agree and will
have a -06 ready soon. I agree with most nits.

> "good starting point".  So I don't feel removing it here is imperative,

Hmm, what about keeping it (i'd still like to reference to and RFC and
not only to the more general NIST doc), but mentioning that it may be
under revision soon? OTOH, if there is an update to 4641, it should be
obvious from the RFC database.

>      for DNSSEC aware software.

Hmm, I personally think SHOULD is just that bit stronger, maybe even
without 'be able' there. But that discussion might boil down to a ligt
version of optional vs. mandatory...

> surprise.  If we're saving precious DNS security algorithm numbers,

I think it also prevents a bit of confusion and ugliness that you get
when having every single algorithm two times in the list. But you are
right, it could use more shouting. This road leads to different
confusion possibilities :)

> approach to me, either) and deal with that issue at a different level.

Hmm, I never noticed that. How annoying. Is the earlier mention of
SHOULD or RECOMMENDED enough?

> Is there a standing downref exemption for this RFC?

Nice catch. I don't think there is too much harm in moving the reference
to informative, since the relevant parts are copied here (with the
suggested fixes in -06).

Jelte

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 18 Sep 2008 21:20:33 -0400

<no-hat>

>surprise.  If we're saving precious DNS security algorithm numbers,

 From the document I read a zone that signs with RSA/SHA2 can use either
NSEC or NSEC3, thus and validator can not be sure until it gets back an answer
from the zone, which kind of negative "expression" the zone uses.

Are the members of the working group comfortable with this ?

         Olafur (no opinion just an observation)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Sep 2008 13:33:24 +1000

In message <[email-masked]>, Olafur Gudmundsson wri
> Are the members of the working group comfortable with this ?

	I am.  I was aware of that when I said to make it indicated
	NSEC3 support.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 19 Sep 2008 16:08:24 +0200

> Are the members of the working group comfortable with this ?

Well, pure signaling of nsec/nsec3 usage is not necessary for
validators, and the algorithm aliases that were made for older
algorithms was only so that the original validators will not trip over
missing NSEC records, not for new ones to know what to expect.

But, in the current text of this draft, if your validator does not
support NSEC3, it cannot support RSA/SHA2 signatures either. I will add
some text to make this more clear for possible implementers.

If that is a big problem, i suggest people speak up now. I have raised
this issue twice before i made the change, and heard virtually nothing
but support for it.

Speaking of speaking up, I still need at least one reviewer/supporter of
the draft by thursday. The issues raised so far will be addressed, but
unless the above point needs to be changed, i don't think they would
warrant a new last call cycle.

Jelte

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Sep 2008 09:03:34 -0700

I have read this document and it seems fine, modulo earlier comments 
on this thread.

An additional note: the first sentence in section 4.1 is wrong 
(probably out of date). The document now has lower and upper 
restrctions for both RSA/SHA-256 and RSA/SHA-512.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Weiler <[email-masked]>
Date: Tue, 30 Sep 2008 12:51:15 -0400 (EDT)

I have read this document.  Aside from the nits previously raised and 
the below, it should go forward.

>> From the document I read a zone that signs with RSA/SHA2 can use 
>> either NSEC or NSEC3, thus and validator can not be sure until it 
>> gets back an answer from the zone, which kind of negative 
>> "expression" the zone uses.
>>

No.  This creates an unneccessary link between two unrelated DNSSEC 
parameters.  The danger is that if someone finds an attack that takes 
advantage of NSEC3, zones may have to choose between being vulnerable 
to that attack while using good hash algorithms and protecting 
themselves from the NSEC3 attack while using poor hash algorithms. 
Not a fun choice.

Is there any compelling reason to link them?

-- Sam