Dave CROCKER wrote: > 2. The h= mechanism is to protect against a bid-down attack. When > looking for what to strip from DKIM I thought it was a candidate > until I understood this purpose. I can be used for other reasons, > but it's justification really is an operational assessment of > what's needed for adequate security.[1] > > 3. The spec cannot expect anyone's code to know about relatively > strength or preference among different algorithms. So the fact > that someone does h=sha1 without sha256 is a strange choice it > I'd strongly urge against having code 'know' that it ought to be ok.
I think we all firmly agree with the general security recommendations to minimized discovery information that can enable attacks on sites using legacy and known insecure features. But I am having a problem seeing how the inner discovery for DKIM signer hash method (higher hurdle outer discovery is finding the public key itself) is the real concern related to DKIM SHA1 exploits? I guess it helps to understand how a SHA1 exploit is applied to DKIM. Does anyone have an example? The way I see it is there are many hurdles the bad guy needs to jump before even trying a SHA1 exploit for DKIM. h=sha1 is a bad idea for the domain to set, but it really doesn't matter it is said sha256 or any other future higher strength method because the bad guy only interest is in SHA1 and will try that only. I don't see how h= helps with bid-down attack prevention. The exploit is with SHA1 only. Practically speaking not SHA256 and of course, future hash methods are going to be presumed to be even stronger. So the only concern as I see it is finding DKIM sites period - the outer discovery. But then again, I guess that all depends on what exactly is the DKIM vulnerability when using SHA1. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ dkim-ops mailing list dkim-ops@mipassoc.org http://mipassoc.org/mailman/listinfo/dkim-ops
