Re: [ietf-dkim] Suggested alternate algorithm specification language, f

I was reminded that Dave actually had suggested wording changes for two
places in the spec. I was referring to both.

        Tony Hansen
        tony(_at_)att(_dot_)com

Tony Hansen wrote:
> I vote for Dave's language to be added to ietf-dkim-base.
>
>       Tony
>
> Dave Crocker wrote:
> > Folks,
> >
> >
> > > > DKIM's base spec already has a mechanism that supports alternate
> > > > algorithms.
> > > >
> > > > Are there any changes to the mechanism that anyone is suggesting?
> > > No, we're still on MUSTs and SHOULDs for which ones.
> > As I understand the current situation, there are only two candidate
> > algorithms being discussed, SHA-1 and SHA-256.  There is also the
> > question of an alternative to SHA-256.  The security community's
> > assessment of a preferred longer-term choice is underway and will,
> > someday, converge in some formal way.
> >
> > Until then, we need language in the DKIM specification that a) deals
> > with the concerns about SHA-1 at least by allowing specification of
> > alternative algorithms, and b) cites at least one other "preferred"
> > algorithm in some fashion.  Again, at the moment, I've only seen SHA-256
> > as the candidate.
> >
> > We already have satisfied a), with the algorithm-choice mechanism.
> >
> > As Ned's note this morning has reminded us all:  The key to
> > interoperability is defining a core of requirements that everyone must
> > satisfy.
> >
> > (My unkind response to anyone suggesting that we not satisfy this basic
> > requirement is that the IETF is the wrong forum for the work, and they
> > need to move to some environment like OSI community had, since it
> > enjoyed creating non-interoperable specifications.)
> >
> > In the case of DKIM, I believe that specifying what a *validator* MUST
> > support is all that is essential to ensure interoperability.
> >
> > That is, if we say that a validator MUST support SHA-1 and SHA-256, we
> > have solved the interoperability problem.  A signer that chooses any
> > other algorithm risks non-interoperability.  They are free to go down
> > that path, but they had better have some basis for the choice.
> >
> > In other words, we are trying to juggle two different requirements:
> > interoperability and security.  The problem is that the latter one is a
> > bit fuzzy at the moment. *Better still is that this working group can't
> > resolve it.*
> >
> > As I say, defining what the validator MUST support solves our
> > requirement to ensure an interoperable base.
> >
> > If we say that a signer SHOULD use SHA-256, then I think we have solved
> > the security-strength concerns, for the moment.
> >
> > If the security community converges on a different preference, prior to
> > our WG Last Call for the base, then we can plug in something other than
> > SHA-256.  It's a minor change.
> >
> > However I think the model for the spec language is clear:
> >
> >    A validator MUST support {SHA-1, SHA-256}.
> >
> >    A signer SHOULD use {SHA-256}.
> >
> > We can, of course, add discussion about the trade-offs.  This might lead
> > to the somewhat unusual alternative for signer language, along the lines
> > of:
> >
> >    A signer MAY use {SHA-1} for its lower overhead, in spite of
> > potentially reduced security strength.  A signer SHOULD use {SHA-256}
> > for its higher security strength.
> >
> >
> > Ok, folks.  What have I missed?
> >
> > d/
> _______________________________________________
> 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