Charles Lindsey wrote:
On Sun, 25 Feb 2007 22:09:06 -0000, John Levine <johnl(_at_)iecc(_dot_)com>
wrote:
So now let's say I have a message that has at least one good
signature. As far as I'm concerned, I'm done, it's verified. If I
were to check the SSP, the most that could happen is a variation on
the "I sign nothing" scenario, if the SSP claims there's some set of
signature algorithms other than what I found. That is not useful to
the receiver, other than perhaps to identify senders insufficiently
competent to publish consistent key and SSP records.
If the message has enough good signatures which match the From
(whatever) header to meet whatever your local policy requires, then
indeed you accept it; end of story; no need for SSP.
Or I have a message that didn't have any good signatures. I can't
tell whether that was because it was unsigned, it had a good signature
that broke in transit, it had a good signature that I didn't know how
to verify, or it had a bogus signature applied by a bad guy. So, as a
receiver, this is all the same situation, it's unsigned. If you
believe that SSP can state "I sign everything", you might throw it
away if that's what the SSP says. Otherwise, what?
Eh? If it was unsigned, you know that.
If it was signed with an algorithm you couldn't verify, you know that,
I suspect the key word here is "signed". All you know is that it has
something that looks like a DKIM-SIGNATURE. The verifier has no way to
differentiate sha0 from sha1024 since it is ignorant about both. Thus
for all intents and purposes it is just as broken as any other reason
that a signature might break, and needs to be handled in the identical
way lest you give attackers a leg up.
If the signature was broken, you know that (but not why it was broken).
All those situations are to be classified as 'unsigned' (but more
detailed information is available to you if you want to use it).
So, being "unsigned", you consult the SSP, which maybe tells you "we
sign everything". You might then reject it regardless on that basis and
thus lose some genuine message simply because you couldn't verify the
algorithm in use; more likley, you would want to allow such cases
through (whilst also persuading your local geeks to implement the new
algorithm ASAP).
Um, that sounds like a great way to make dkim completely impotent: if
an attacker knows that you treat unverifiable signatures better, they
only have to put those majick bytes in the signature header and voila.
But, in the example quoted (message signed only by
unverifiable algorithm B) you would then accept the bogus message. But
an SSP response of "we sign everything with both A and B" would allow
you to accept genuine messages from that site (because you can veriffy
algorithm A) but reject the bogus one.
As I mentioned, you can already determine what algorithms are supported
by a given selector. Why does putting in SSP help?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html