Re: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-02.txt

[Jelte Jansen <jelte@NLnetLabs.nl>]

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


Thanks, very good points.

Michael StJohns wrote:
> A couple of comments and questions:
> 
> Since 3110 permits RSA keys as short as 512 bits you should probably note that SHA512 can't be used with keys of that length due to padding considerations.  Per PKCS1 the hash size has to be at least 11 octets shorter than the key length.
> 

Yes, a discussion about lengths (both of keys and signatures) is missing
and will be added. Also, I structured the document so that if we do
decide on adding or removing specific algorithms from the SHA-2
document, it's easily done. Although I think that with 256 and 512 we
have an acceptable middle ground between needs and combination-complexity.

> The ID lists allocations for SHA256-NSEC3 etc - but there's no body text related to NSEC3.  This is probably not the right place to list those allocations.  Given that NSEC3 ID still isn't closed (or may only have closed today) it may be more appropriate to list the allocations there.
> 

It kind of depends which document gets finalized first. It seems that
NSEC3 will be finalized before this document, in which case I think this
 (sha2) document will be the right place. There should indeed be some
actual text and a reference in that case. If this document would seem to
be done first, I'll remove the NSEC3 references altogether.

> This document doesn't specify WHICH signature mechanism of the two listed in PKCS1 should be used - from context its PKCS 1 v1.5, but should be stated explicitly.
> 

Yes, thanks.

> There's some low level mumbling in the security community to deprecate 1.5 padding and the original signature mechanism and replace them with RSASSA-PSS and RSA-OAEP.  There should at least be a discussion about this set of choices and why DNSSEC is sticking with RSASSA-PKCS1-v1_5.
> 

Hmm, I kind of went for a least-surprise and
least-fuss-for-users-of-crypto-libraries method, with the most widely
used padding mechanism, which obviously I think is this one. If I'm
wrong, or if there are strong hints that they will indeed be deprecated,
using another method is probably the way to go. Otherwise I'll gladly
add some text to explain the choice.

> Following the item above on key length, there needs to either be a discussion of the appropriate hash algorithm to use with which key lengths or a pointer a document which describes this (e.g. NIST 800-57) or preferably both.
> 

Ok

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX5Tc4nZCKsdOncURAknaAKCyGulawnZE+F0BV1IjVkuX4npsywCfcdWd
gdOuyktmcLs7e3DilGaGbDs=
=SEeM
-----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/>