ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Supporting alternate algorithms

2006-02-21 08:16:11
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 
bill(_dot_)oxley(_at_)cox(_dot_)com 

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Monday, February 20, 2006 6:52 PM
To: Stephen Farrell
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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