Subject: RE: [ietf-dkim] agenda item on upgrading hash algorithms?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Feb 2006 18:47:43 -0800

> > santronics.com exposes it supports the algorithms:
> >
> >    k=sha1, sha256, sha512, whirlpool, other;
> >
> > If bankofamerica.com had a relationship with one of our 
> users, it can 
> > lookup the santronics.com capability and choose the highest 
> strength.

I do not think this works at all. If we could predict where email was
going to end up the problem would be one heck of a lot easier.

>From a practical point of view the only mechanism that has worked to
date is to have a small number of algorithms that are universally
supported. The problem with options is that you usually end up with the
strength being set by the weakest algorithm, not the strongest.

I would be much happier with a suites approach, vis

Suite1: RSA 1024 with SHA-256
Suite2: ECDSS 256 with SHA-3/256

Aiming to begin introducing Suite2 in the 2009-2010 time period, after
the digest algorithm contest is complete and after we get some clarity
on which forms of ECC are definitively unencumbered. ECC was first
proposed in 1985, therefore the original patents have expired and there
are at least some forms that are not encumbered. I will happily trade
speed, key size and Suite B compliance for unencumbered.

In rebuttal to Doug's point about not depending on the DNS supporting
longer key sizes, an ECDSA key that gives equivalent strength to a 128
bit symmetric cipher is 256 bits with point compression and 512 bits
without. An equivalent ECDSA signature is 512 bits in either case. The
comparable key size for RSA is 3072 bits for key and signature.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 19:52:07 -0800

On Feb 22, 2006, at 6:47 PM, Hallam-Baker, Phillip wrote:

> In rebuttal to Doug's point about not depending on the DNS  
> supporting longer key sizes, an ECDSA key that gives equivalent  
> strength to a 128 bit symmetric cipher is 256 bits with point  
> compression and 512 bits without. An equivalent ECDSA signature is  
> 512 bits in either case. The comparable key size for RSA is 3072  
> bits for key and signature.

This looks great, but at what price?  From what other companies  
beyond Certicom Inc. would licenses need to be obtained in order to  
support the EC algorithm?  Is there any information with respect to  
existing terms?

Adapting to limitations of some fashion always seems par for the  
course.  DKIM should be agile and able to adapt to its environment.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Feb 2006 09:16:13 -0800

> support the EC algorithm?  Is there any information with respect to  

As a follow-on:

Certicom may grant royalty free licenses in some cases.

http://www.certicom.com/download/aid-545/IETF.pdf

http://www1.ietf.org/ietf/IPR/IETF-2006Jan26-Certicom-IPR.pdf

http://www.ietf.org/ietf/IPR/certicom-ipr-rfc3526-rfc2409-ikev2.txt

http://www.ietf.org/ietf/IPR/CERTICOM-SMIME
http://www.ietf.org/ietf/IPR/certicom_smime_license.pdf

http://www.ietf.org/ietf/IPR/CERTICOM-IPSEC-ECC

http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Feb 2006 12:58:50 -0500

> http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA
One of the points that DKIM currently has in its favor is that it can be 
implemented in all major MTAs without conflicting with the existing licensing 
of those programs (both proprietary and open, including GPL).  

I think that if DKIM were to be dependent on crypto technology with more 
restrictive licensing terms, it would represent a substantial impediment to 
adoption.  IANAL, so I have no idea if the representations above would 
present a problem or not, but I do think that we should understand the 
impacts of these patents on the ability of DKIM to be implemented everywhere 
before we proceed to far towards a solution with additional licensing 
considerations.

Scott K