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

At 5:12 PM -0700 5/23/06, Douglas Otis wrote:
> There still should be a strategy defined in the base draft to ensure 
> an unknown algorithm can be confirmed.
Could you define "confirmed"?

> 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.
Of course. So?

> 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.
It doesn't anyway: the verifier simply doesn't use the signature that 
uses the now-bad algorithm.
> 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.
How is the DKIM case any different than in S/MIME and OpenPGP? Or are 
you claiming that they too need to be fixed with your "simple 
deprectation flag" as well? The value of DKIM signatures is orders of 
magnitude less than the value of these other signature formats, and 
yet those IETF WGs (which have been around for a decade) have not 
found a need to solve this "genuine security concern".
At 12:26 AM +0100 5/24/06, Stephen Farrell wrote:
> Does anyone else see this as a serious issue?
Not I.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html