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

My point is not that we should try to implement ECC in v1 of the spec,
or even in v2.

The possibility of using 256 bit ECC in place of 4096 bit RSA does have
a very significant effect on the choices we might make for extension
though and we should certainly bear them in mind.

Another option we should probably consider as a low cost, low tech
solution would be some sort of multiple record solution similar to the
one proposed in Caller-ID.

-----Original Message-----
From: Stephen Farrell 
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] 
Sent: Thursday, February 23, 2006 4:13 PM
To: Hallam-Baker, Phillip
Cc: Douglas Otis; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?

This is a long thread!

My take is that DKIM doesn't need ECC now, and I absolutely 
don't want to put it on the critical path, not that anyone's 
suggesting that I hope.

But if someone wants to go write a separate draft, later on 
in the year, then the wg could consider taking that on, say 
after the base is through wg last call.

Stephen.

PS: I would not like us to be the 1st wg to try work around 
ECC encumbrances, even though I agree its probably do-able. 
Getting PKIX or S/MIME or PGP or KITTEN to figure that out 
first would be better IMO.

Hallam-Baker, Phillip wrote:

I think that we are all aware that IP owners have a duty to their 
shareholders to promote the value of their IP in the best possible 
light.

We do not need point compression for our purposes. Nor is

efficiency a

critical issue. The only crucial criteria is a bit length

of 1024 bits

or less.

-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Thursday, February 23, 2006 3:16 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?


On Feb 23, 2006, at 10:31 AM, Hallam-Baker, Phillip wrote:

[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott

Kitterman

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.

The point I was making here is that we do not need CertiCom

to do ECC.

Certicom have a number of patents relating to ECC, the

earliest of

which was filed in 1997. Practical means of performing ECC were 
published in 1985.

ECC is attractive from a performance standpoint, but not without 
problems.

Quote from Certicom Inc.
http://www.certicom.com/index.php?action=ip,keygen
---
The security of public-key systems rests on keeping the

private keys

secret. Recent discoveries have revealed that the presence

of a bias

in the process of generating private keys may leak

information about

the private key into the public key. As an example, a

recent attack

on a system with a biased key-generation process obtained

information

about the private key by examining a number of signatures.  The 
attacks work against such discrete-log-based signature

schemes as the

DSA and the ECDSA. One patent protects against this attack by 
teaching methods of eliminating bias in the generation of private 
keys or per-message secrets. One such method comprises testing the 
hashed output of a random-number generator against preset criteria 
(determined by the order of the group underlying the cryptosystem).
If the output fails the test, the pre-hashed value is

modified by a

deterministic amount, hashed, and retested until the output passes 
the test.
---

There is a good papers at:
http://www.secg.org/?action=secg,docs_draft

Certicom's extensive portfolio of patents related to

elliptic-curve

cryptography, and the extensive IPR claims affecting IETF

protocols

using the elliptic-curve algorithms seems to suggest avoiding 
Certicom may not be that easy.
Their royalty-free license, if granted for DKIM, does not

seem overly

problematic.  Certicom also provides a developers kit.  Is

there safe

elliptic-curve cryptography code available known to be free of any 
IPR restrictions?

-Doug


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


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