Subject: RE: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 15 Jul 2006 22:46:52 -0400

Phil,

I agree that the DSA algorithm DNS key/signature format RFC should cover
the extensions by NIST to DSA.

As to what algorithms should actually have what level of implementation
requirement, that is a different question.

From the start of DNSSEC, I have thought that ECC, with its shorter keys
and signatures, would work well. There are some problems with patents
but those do tend to get sorted out eventually... :-)

Thanks,
Donald

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 11:19 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt 

NIST has recently proposed a new version of DSA that supports 2048 bit
(and
larger) keys and SHA2. I think that the draft should be updated to cover
this new algorithm as it overcomes one of the principle difficulties
with DNSSEC deployment, the size of the signature keys.

DSA-2048 with a 256 byte subgroup has the same key size as RSA: 256
bytes.
But the signature blob is only 64 bits. The cipher strength is
equivalent to
112 bit symmetric key cryptography as opposed to 80 bits for DSA. 

ECC certainly has benefits but at this point I can't see us navigating
the patent thicket quickly. It is much easier to get cipher hardware
vendors to support the new DSA than an entirely new algorithm. 

I propose that we reserve 2 signature algorithm identifiers for the new
DSA
signatures:

ID#1 for the DSA algorithm as currently specified.
ID#2 to be issued on completion of the hash algorithm competition for
DSA+NewHash

I don't know if this would be best done as a separate draft or as a
continuation of this draft. My preferred solution would be to create a
new draft using the same text. 

The one drawback to using DSA is that public key operations are slower
than private key operations. If you operate a large domain this is not
exactly a drawback :-) but my interest here is independent of the
registry, my concern is DKIM where this pushes the computation load in
an unfortunate direction.

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