Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
The related attack would be as follows: A signer might
deploy a brand-new signature algorithm (I'll call it N) that
very few verifiers can yet handle. The attacker sees this,
and starts forging messages with invalid signatures
referencing the N selector, in hopes that some verifiers will
accept the message on the premise that they're just not
"smart enough" to verify using N yet. If this were to
happen, it would introduce a problem getting signers to start
using new algorithms.
That is exactly the attack that concerns me.
You're kidding. This is all about receivers who pass things that they
ought not? Wouldn't it be easier to just file a bug report?
Of course a solution to this is to make sure all verifiers
treat signatures they can't verify (as well as those that
fail verification) as if the signatures aren't there. But
perhaps some of the verifiers won't do this, because they
don't want to risk adverse consequences from taking action
against such messages.
The problem is that the verifier is acting on incomplete information.
If verifiers do this there is a disincentive for senders to use the new
signature algorithm until it is supported everywhere.
No, I'd say that the verifier has a bug and that it should just fix the
bug. There are a hopeless number of other bugs that a verifier can have,
so I don't see why this one is special.
The policy record would only be checked in the circumstance that a message was
received that ONLY bore a message that had a signature that the verifier
considered to be inadequate.
In which case you'd do SSP as usual and if it said "I sign everything",
then it wouldn't pass muster just like usual.
If there is an acceptably secure signature then the verifier would check that
and the job is done.
But the verifier would do that before it consulted SSP.
In practice I don't rate this as a very important attack for the deployment scenarios we are considering today. My concern here is that it is exactly the type of issue that a Bellovin or a Resorla or anyone else in the Security Area might point to as a protocol flaw and in this case they would be right.
As described, this isn't a protocol flaw it's an implementation error.
But what might be helpful here to state the *exact* text that you think
needs to go into the requirements draft and we can have a poll as to whether
to included or not and alleviate me from having to understand that which
I clearly do not.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html