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(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops