Subject: Re: DH/DSA I-Ds

From: Ben Laurie <[email-masked]>
Date: Sun, 26 Mar 2006 14:06:51 +0100

Eastlake III Donald-LDE008 wrote:
> Hi,
> 
> See below at @@@
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ben Laurie
> Sent: Wednesday, March 22, 2006 5:25 AM
> To: [email-masked]
> Subject: DH/DSA I-Ds
> 
> Here's my review of the DSA/DH I-Ds. You may regret asking for
> volunteers in my presence :-)
> 
> RFC 2536bis - DSA keys
> 
> 1. When referring to FIPS 186-2 I believe it is called DSS Digital
> Signature Standard), not DSA.
> 
> @@@ Indeed, the FIPS document is DSS. But this draft is intended to only
> cover DSA = Digital Signature Algorithm keys and signatures. The new DSS
> document covers RSA and ECDSA signatures also. The right term needs to
> be used for the particular context.

OK.

> 2. I object to Schneier as a reference when Handbook of Applied
> Cryptography is a) better and b) freely available on the web.
> 
> @@@ I assume you are referring to Menezes. I've got no problem with
> adding that as a reference but I'm more reluctant to remove an existing
> reference. What's the URL for Menezes on-line?

http://www.cacr.math.uwaterloo.ca/hac/

> 3. This assumes a 160 bit hash. NIST has just approved all the other
> SHAs as appropriate hashes for DSS, so it seems silly not to revise the
> I-D to allow for that, especially since we should generally remove hard
> dependencies on SHA-1.
> 
> 4. The prime is limited to 2560 bits, which may be small by modern
> standards.
> 
> @@@ Responding to both of the above comments, yes, I understand that
> FIPS 186-3 has just been approved. I'll look it over and see what
> changes would be needed. I do think that this document should cover the
> new extended DSA. In general, limitations on size of primes and the like
> ought to appear where the specific RR is defined that makes use of this
> DSA key/signature format. However, where that has not been done, as for
> example in RFC 4034, the limitations for pre-existing RR uses of the DSA
> format probably have to be in this document.
> 
> @@@ You suggest raising the 2560 bit limit, I assume for DNSKEY. Would
> that break code? If it were to be changed, what new value would you
> suggest? I'm inclined to say that, to minimize change, the size limit
> should not change for DNSKEY and KEY.

You will have to change the limit to fully support 186-3. The largest
prime used is 3072 bits. Also, there's less flexibility in size.

The allowed parameters can be found in section 4.2 of 186-3 and are:

L = 1024, N = 160
L = 2048, N = 224
L = 2048, N = 256
L = 3072, N = 256

where N is the hash size (and hence the size of Q) and L is the size of P.

I would be inclined to provide a 2 for each of L and N (unless you want
to deduce N from the hash). You'll also have to add a field to select
the hash, of course.

I'm not sure in what sense you are asking about breaking code - I would
be surprised if the underlying DSA implementation would break as a
result of using larger primes, but since the wire format has to change,
code depending on that will obviously break. Also, current
implementations are quite likely to have N hardwired as 160.

> RFC 2539bis - DH
> 
> 3. 768 bit primes are _weak_ and should be killed.
> 
> @@@ What minimum size would you suggest? I'm inclined to leave this
> alone for existing RRs and to say that any future RRs that are defined
> to use this format need to also specify the limitations on use.

1024.

> 4. Perhaps larger "standard" primes should be included (the biggest is
> currently 1536 bits).
> 
> @@@ Yes, the additional ones references in my response to point 2 above
> are larger and should be included.

OK.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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