Re: [ietf-dkim] Issue #1184, 1196, 1271

On May 23, 2006, at 4:26 PM, Stephen Farrell wrote:
> Douglas Otis wrote:
> > On May 22, 2006, at 4:25 PM, Douglas Otis wrote:
> > > It could be helpful for details related to the algorithm's  
> > > representation in the binary key be posted for review.  Resolving  
> > > the method of representation should allay some possible concerns.
> That's too vague to handle. Suggest you raise whatever issues you
> see whenever a binary format spec is published.
There still should be a strategy defined in the base draft to ensure  
an unknown algorithm can be confirmed.
This requires consensus on whether:

 - A binary assertion of an algorithm can be made in the future.
 - A list of query mechanisms can return keys expressing the  
algorithm in different formats.

> > > The review of a strategy for using a key deprecation flag should  
> > > also be possible.  Once there is an assured method to confirm an  
> > > unknown algorithm is currently offered by a signing domain,  
> > > detecting removal of a non-deprecated signature during a  
> > > transition is possible.  A signed message must contain at least  
> > > one non-deprecated signature where the algorithm, even though  
> > > unsupported by the verifier, must still be confirmed as supported  
> > > by the signing domain in the referenced key.  Without such a  
> > > strategy, an opportunity to exploit a deprecated algorithm  
> > > continues over the entire duration for a complete transition to  
> > > occur, even in cases where both the signing and the verifying  
> > > domains supported a newer non-exploited algorithm.
> Does anyone else see this as a serious issue? On the last jabber [1]
> I think it wasn't seen as such and 1184 & 1196 were marked for
> closure/rejection (to be confirmed on the list of course).
Without a strategy devised within the base draft, if there is a  
weakness discovered, an exploit can not be fully prevented until it  
becomes practical not to use an algorithm that might be the subject  
of some exploit.
With a relatively simple deprecation flag, and a requirement that a  
message must include a non-deprecated signature from the signing  
domain, once both the signing and verifying domain upgrade, inclusion  
of a deprecated signature will not introduce an additional risk.   
This is a genuine security concern, as email does not offer a means  
to negotiate and a transition period may take years, hence offering a  
deprecated signature must not permit an exploit beyond where both  
signing and verifying domains handle the non-deprecated signature.
-Doug


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