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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jul 2006 05:58:40 -0700

I think that the first step here is to get a document out that details any changes to the DNSSEC spec that may be necessary. When the DSA part was written the DSA key size was fixed and so was the hash algorithm.

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]] 
> Sent: Saturday, July 15, 2006 10:47 PM
> To: [email-masked]
> Cc: Hallam-Baker, Phillip
> Subject: RE: New DSA key sizes RE: 
> draft-ietf-dnsext-rfc2536bis-dsa-06.txt 
> 
>  
> 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/>

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 17 Jul 2006 02:59:53 -0400

Maybe we don't mean the same thing by "the DNSSEC spec" but I don't
think that changes to extend an algorithm like this should require a
change in the DNSSEC protocol spec. Just changes in the DSA
key/signature DNS format specification and in the linking document which
gives the algorithm IDs and implementation requirements and limits.

Donald

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Sunday, July 16, 2006 8:59 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: New DSA key sizes RE:

I think that the first step here is to get a document out that details
any changes to the DNSSEC spec that may be necessary. When the DSA part
was written the DSA key size was fixed and so was the hash algorithm.

> I agree that the DSA algorithm DNS key/signature format RFC should 
> cover the extensions by NIST to DSA.
> 
> 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
> 
> 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.
> 
> But the signature blob is only 64 bits. The cipher strength is 
> equivalent to
> 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:
> 
> 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.
> 
> 
> 
>