Subject: draft-ietf-dnsext-dnssec-rsasha256-05

From: Alfred Hönes <[email-masked]>
Date: Thu, 4 Sep 2008 16:11:50 +0200 (MESZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello,
I eventually found the time to take a closer look at the latest
revision of the RSA / SHA-2 DNSKEY/RRSIG draft,
      draft-ietf-dnsext-dnssec-rsasha256-05,
whereby a substantial inconsistency in Section 3 became apparent,
and I have a few further recommendations to improve the text.

(1)  Section 3 -- mis-specification, and textual enhancements

The draft says:

   [...]

   hash = SHA-XXX(data)

   Where XXX is either 256 or 512, depending on the algorithm used.

   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)

   Where SHA-XXX is the message digest algorithm as specified in FIPS
   PUB 180-2 [FIPS.180-2.2002], "|" is concatenation, "00", "01", "FF"
   and "00" are fixed octets of corresponding hexadecimal value, "e" is
   the private exponent of the signing RSA key, and "n" is the public
   modulus of the signing key.  The FF octet MUST be repeated the
|  maximum number of times so that the total length of the signature
   ^^^^^^^^^^^^^^^^^^^^^^^
   equals the length of the modulus of the signer's public key ("n").
   "data" is the data of the resource record set that is signed, as
   specified in RFC 4034 [RFC4034].

   [...]

The specification of 'FF*' IMHO makes no sense.

Since the 'mod n' operation reduces the bit size of the result,
the sequence of (integer) repeat factors <k> such that the second
formula above with 'FF*' instantiated as <k> times the octet 0xFF
fulfills the condition that "the total length of the signature
equals the length of the modulus" is unbounded, and hence the
requested maximum does not exist.
Also, the stated condition on the *result* (signature) can only
be verified *after* performing the modular exponentiation and hence
is considered inappropriate.

I guess that:

a)  the condition should be applied to the term in parentheses
    (*before* modular exponentiation), and
b)  we should request the *minimum* number of 'FF's fulfilling
    the condition.

Further, in order to enhance the readability of the text, I strongly
recommend to group all explanations of the terms appearing in the
first formula into the "where" clause immediately following this
formula, and only explain the terms specific to the second formula
in the second "where" clause.  Additionally, I suggest to replace
"Where" by "Here" in both sentences for grammatical reasons.
Finally, I suggest to indent the formulae to better separate them
from the prose.

Altogether, I recommend to replace the above snippit by:

   [...]

|     hash = SHA-XXX(data)

|  Here XXX is either 256 or 512, depending on the message digest
|  algorithm used, as specified in FIPS PUB 180-2 [FIPS.180-2.2002],
|  and "data" is the data of the resource record set that is signed, as
|  specified in RFC 4034 [RFC4034].

|     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)

|  Here "|" is concatenation, "00", "01", "FF" and "00" are fixed octets
   of corresponding hexadecimal value, "e" is the private exponent of
   the signing RSA key, and "n" is the public modulus of the signing
|  key.  The FF octet MUST be repeated the minimum number of times so
|  that the total length of the concatenated term in parentheses equals
|  the length of the modulus of the signer's public key ("n").

   [...]

(2)  Section 9

As a service to the reader, I suggest to sort the items in 9.1 and
9.2 by ref. tag collation order, in particular to sort references
to RFCs by RFC number.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

--
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: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Sep 2008 13:05:30 -0400

Since this document is in WGLC, it would be nice to have a declaration
whether you support advancing the document to the IESG, perhaps with
some or all of your changes incorporated as a necessary condition for
that support.

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Francis Dupont <[email-masked]>
Date: Fri, 05 Sep 2008 15:51:15 +0200

In your previous mail you wrote:

=> this is the standard PKCS 1 v1.5 padding so why not get the
right text from it?

=> with the "equals" we no more need minimum (or maximum).
(I've looked at the PKCS standard and the number of 0xFF is the padding
is given by an equation too).
 BTW the use of a standard padding is a good idea, both because the
padding is critical for the security and because it is a very common
padding scheme.

Regards

[email-masked]

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 5 Sep 2008 16:46:54 +0200 (MESZ)

Francis,

> [email-masked]

Francis, you are right.

But the structure of RFC 3447 doesn't make it easy to pick up the
proper details; and in fact, I missed these as well this week.  :-)
You remark has caused me to retry, and I did a better job now.

Therefore:

Jelte, if you want to go this way, please give a detailed
reference, pointing to Sections 8.2 and 9.2 of RFC 3447.

BTW: When reading RFC 3447 don't forget the Errata!   [ :-) again ]

Kind regards,
  Alfred.

---

From: Jelte Jansen <[email-masked]>
Date: Sun, 07 Sep 2008 14:18:13 +0200

> reference, pointing to Sections 8.2 and 9.2 of RFC 3447.

Err, i thought i already had (at the end there, at least to section 9.2
of 3447, maybe not to 8.2);

"These specifications are taken directly from the
 specification of EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2
 [RFC3447]."

So, i should change 'maximum number of times' to something like 'exact
number of times'?

> BTW: When reading RFC 3447 don't forget the Errata!   [ :-) again ]

arg, the ietf needs a better system for notifying people who only read
the .txt versions of rfcs that there are errata. That last one about 9.2
is very important :)

> Altogether, I recommend to replace the above snippit by:

I will most probably take your suggestions for the explanation grouping
and replace my text by that one, thanks.

> I suggest to sort the items in 9.1 and

Will do.

Thank you for your review and suggestions.

Jelte