Subject: RE: [ietf-dkim] Supporting alternate algorithms

From: <[email-masked]>
Date: Tue, 21 Feb 2006 10:03:55 -0500

Why is determining the crypto methodology part of this groups efforts?
Shouldn't DKIM specs state where in the dns record the signing entity
stores what method they are using for crypto. If joe.stonage.com wants
to use the original nix crypt command to sign should he not be allowed
to do so? Of course the community would note that decision with
suspicion, but that is his choice.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Monday, February 20, 2006 6:52 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [ietf-dkim] Supporting alternate algorithms

Stephen Farrell wrote:
> 
> While I wouldn't quibble with anyone's position on whether sha-1 is
> still ok, or whether sha-256 is interestingly stronger, (not being
> qualified myself), I do think the place from which DKIM ought to
> accept guidance is the saag.

Is there some reason that the DKIM working group needs to spend much
effort 
discussing the details of the preferred algorithm?  I would think that
that is 
primarily a recommendation to be made by the security community.

The DKIM WG must to specify a choice of specific algorithms, of course,
but the 
design of DKIM and the specification of its mechanism for labeling its 
algorithms is fully flexible.  The spec document can plug in any
algorithm that 
the IETF security community recommends.

That is,

1. DKIM needs to have a mechanism that permits specifying alternative 
algorithms.  And it already does. So that requirement is already
satisfied.

2. DKIM needs to specify a requirement for signer and validator support
of a 
core sets of algorithms, where a set may have a single member or
multiple. It 
already does, but clearly one or more of the sets need to be changed.

3. The DKIM working group needs to worry about things like cost of the 
algorithms, availability of implementations for them, impact on backward

compatibility, transition, and so on.  But I am failing to see why this
group 
needs to put energy into discussing the relative merits of different
algorithm's 
strength or lifespan.

4. On the matter of backward compatibility and transition, there has
been some 
recommended text.  As nearly as I can tell, it did not get pursued or
resolved.

No doubt, I am missing something fundamental that requires that we focus
on the 
level of detail that occurs every time a thread touches algorithm
choice, but I 
am not seeing what it is.  Can someone explain how and why this is where
we 
should be putting our energy?

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Feb 2006 07:40:16 -0800

> suspicion, but that is his choice.

An IETF specification needs to contain a core of requirements that guarantee 
interoperability between participants who have no prior arrangement.  That means 
that all both sides must support a core of capabilities that match, including 
algorithms such as crypto, if that's part of the service.

If that core of specified required algorithm support is not in the spec, then I 
can choose to sign with whatever algorithms I like and you can choose to support 
whatever algorithms you like, and there might not be an overlap between the two 
sets.

So a good IETF protocol defines a basic, guaranteed level of automatic 
interoperability, and then often has mechanisms that permit supporting optional 
enhancements.

Hence, the DKIM group needs to specify a basic set of algorithms for doing the 
signing calculations.  So, for example, we really do need to specify SHA-256, or 
whatever will be acceptable to the security community's experts.

My own point is that this venue is not the place to have a discussion about 
relative security merits of the chosen algorithm.  Rather, that is the job of 
the security algorithm experts.

Our job is to:

1. Specify a mechanism for specifying which algorithms are used for a particular 
signature.

2. Specify the core set of algorithms that everyone must support

3. Specify any additional details needed to support legacy senders and/or future 
transitions.

-- 

Dave Crocker