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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Feb 2006 10:20:09 -0800

> [mailto:[email-masked]] On Behalf Of Tony Hansen

> I don't like being a guinea pig, but that's what it feels 
> like with the discussions on how to go about upgrading 
> algorithms. I don't think we know enough yet to even know how 
> to begin. This is a problem that a variety of protocols are 
> going to go through, so we are *not* alone (and
> *shouldn't* be alone) in trying to figure out how to do it.

Actually there is a major difference. We have almost complete
flexibility here and almost no legacy base to defend.

Our problem is much much easier than anyone else's. We can avoid the
need for a SHA 256 transition by making it a base requirement and we can
build in a transition strategy into the base.

Another major advantage we have uniquely is that we have a policy
record. The lack of security policy information is a major reason that
existing security protocols are difficult to upgrade and prone to
downgrade attack.

I think that we will find others are looking at us to see if they can
copy our solution.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Feb 2006 13:18:35 -0800

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:[email-masked]] 
> Sent: Thursday, February 23, 2006 4:13 PM
> To: Hallam-Baker, Phillip
> Cc: Douglas Otis; [email-masked]
> 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:[email-masked]]
> >> Sent: Thursday, February 23, 2006 3:16 PM
> >> To: Hallam-Baker, Phillip
> >> Cc: [email-masked]
> >> Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?
> >>
> >>
> >> On Feb 23, 2006, at 10:31 AM, Hallam-Baker, Phillip wrote:
> >>>> [mailto:[email-masked]] 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> > 
> > http://mipassoc.org/dkim/ietf-list-rules.html
> > 
> 
> 
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Feb 2006 19:25:59 -0800

> When a 2048 bit key is to be handled, with the 'g=' parameter 
> and a new hash callout, the space remaining is 93 bytes, 
> assuming a domain with 4 labels with a selector.  From these 
> 93 bytes, 5 labels, the local-part and hash function must be 
> defined where the average item size must be less than 14 
> bytes.  When a binary DKIM Key RR is used, the remaining 
> available space is 192 bytes, which then allows an average 
> item size to be greater than 27 bytes.  This provides twice 
> the available space, which is _not_ insignificant.  The cases 
> where the DNS payload overflows would be much fewer.

Irrelevant, there is no space for a DNSSEC signature in either case,
unless DNSSEC itself supported either ECC or some form of signature
compression a la Schnorr.

> There was not a suggestion to use a new binary record.  The 
> proposal was to employ an existing record in a binary fashion.

It may exist on paper, it is not supported in the running code and
getting support is a long time off.