Re: [ietf-dkim] Core algorithm support/use, draft text v2

On 02/25/2006 16:56, Dave Crocker wrote:
> My proposal for language to cover supported text was confounded by
> suggesting some alternative language.  Discussion since then has frequently
> expressed agreement with my text, but even I am not sure what exact text
> folks are agreeing with.  I also think that Ned's point about the benefit
> of citing sender-side support, versus what is actually sent, is
> significant.
>
> Based on all that, here is what I think reflects groups consensus.  Those
> agreeing should say something simple, like "agree".  Those disagreeing,
> should say something simple, like, "I proposal the following alternate
> text...".
>
> Here goes:
>
>     A validator MUST support {SHA-1, SHA-256}.
>
>     A signer MUST support {SHA-1, SHA-26}.  A signer SHOULD use {SHA-256}
> for its higher security strength. However a signer MAY use {SHA-1}, such as
> for compatibility with an installed base, lower computational cost, or
> easier implementation effort.
>
>
> Consensus?
>
> d/
I'm not experienced enough with IETF processes to know if the following would 
be a useful approach in an IETF context or not, but here goes anyway...

In other venues that I've worked in I've run into problems before when a spec 
had to be reopened "just to fix one little thing" and then the next thing you 
know, the engineers are loose and the whole thing has been updated in an 
incompatible way.  When there are aspects of a design the you KNOW are going 
to have to be periodically changed, it may be useful to break them out into a 
separate document so that the entire design doesn't get exposed every time 
you revise for the known item that will have to be updated.  I'm thinking 
this may be a similar case.  

Might it be useful to break the exact crypto algorithm out into a separate 
(very short) RFC so that it can be revised as necessary?  Something like:

     A validator MUST support all crypto algorithms listed as not deprecated 
in RFC ZZZZ or it's successors, initially {SHA-1, SHA-256}.

     A signer MUST support all crypto algorithms listed as not deprecated in 
RFC ZZZZ or it's successors, initially {SHA-1, SHA-26}.  A signer SHOULD use 
the highest strength algorithm in RFC ZZZZ or its sucessors, initially 
{SHA-256} for its higher security strength. However a signer MAY use earlier, 
non-deprecated algorithhms, initially {SHA-1}, for compatibility with an 
installed base, lower computational cost, or  easier implementation effort.

The initial text for RFC ZZZZ would be along the lines of:

For DKIM the following cryptographic algorithms are specified:

Deprecated:  None

Required:  SHA-1, SHA-256

High strength:  SHA-256

ZZZZ then could be easily revised at the point it becomes clear what the next 
high strength hash algorithm is or if SHA-1 is determined to be broken to the 
extent it should be deprecated.

None of this affects what has to be implemented now, but may make future 
transitions easier.

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