Subject: RE: DH/DSA I-Ds

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 25 Mar 2006 19:42:17 -0500

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.

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?

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.

RFC 2539bis - DH

1. See 2 above.

2. The prime/generator pairs described in the appendix are generally
known as Oakley Groups - it would be good to name them properly.

@@@ OK. There are also two more of them now that have been adopted in
IPSEC which should be added. See my response to Mike StJohns.

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.

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.

Cheers,

Ben.

@@@ Thanks,
@@@ Donald

--
http://www.links.org/

--
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: Ben Laurie <[email-masked]>
Date: Sun, 26 Mar 2006 14:06:51 +0100

> be used for the particular context.

OK.

> reference. What's the URL for Menezes on-line?

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

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

> to use this format need to also specify the limitations on use.

1024.

> 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