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

From: [email-masked]
Date: Tue, 11 Dec 2007 09:10:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
	Author(s)       : J. Jansen
	Filename        : draft-ietf-dnsext-dnssec-rsasha256-02.txt
	Pages           : 8
	Date            : 2007-12-11

This document describes how to produce RSA/SHA-256 and RSA/SHA-512
DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-rsasha256-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Tue, 11 Dec 2007 16:04:01 +0000

> Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).

I think it is a good idea to add that the use of SHA-2 algorithms over 
SHA-1 does not have an impact on the RRSIG length. 

Roy

--
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: Michael StJohns <[email-masked]>
Date: Tue, 11 Dec 2007 12:24:55 -0500

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.

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.

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.

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.

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.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 12 Dec 2007 09:59:24 +0200

Thanks, very good points.

> 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 lea…

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 (…

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 di…

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…

Ok

Jelte

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 12 Dec 2007 08:20:26 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jelte Jansen>
>
> > 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.
> >
>
> > 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.
> >
>

From the discussion about the -13 draft, I hope that gets out soon.
Probably before this.

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

NIST 800-57 Part 1 (specifically) gives the recommended key lengths based on
minimum bits of security.  Not sure where this should be added - security
considerations?

Scott

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