[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.
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.
But the downgrade attack described in the last paragraph of
Phill's original message:
There is also a downgrade attack using essentially the same
principle except that in this case algorithm A is actually
broken and Algorithm B has a sunstantial amount of
deployment. Instead of creating a nonsense signature that
will fail validation the attacker forges a valid signature
for the untrustworthy algorithm.
would require that SSP be consulted in all cases, because the
attacker is able to forge a valid signature. However, I
think this is adequately dealt with by the signing domain
removing all selectors that reference the broken algorithm.
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.
If there is an acceptably secure signature then the verifier would check that
and the job is done.
Since an inadequate signature is by definition essentially the same as no
signature at all the need to check policy is inevitable and not an
optimization. You have to check policy if there is no signature and you have to
check policy if there is an inadequate signature.
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.
In particular if all you are going to be using DKIM for is to control spam
perhaps you could ignore the security issue. If on the other hand your key
record is
beta._domainkey.example.com. 1D IN TXT
"g=; k=rsa; t=y; p=MFwwDQYJKoZIhv...==
letterhead=http://repository.verisign.com/9652d63d06d1b0b0489db2452bf796e4";
Your security considerations have just become considerably more demanding.
What is going on here is that the letterhead URI points to an EV certificate
with a logotype extension that contains a subject icon.
OK now imagine that such a certificate is issued to an EBay or a Paypal. The
security demands we have just placed on DKIM have increased dramatically. At
this point there is an incentive to spend time factoring a weak modulus or
whatever.
Now I can of course come out with a convincing explanation as to why the issue
does not directly affect the usage but its much better to avoid the problem
entirely if possible.
I am also concerned that this is a multi-dimensional problem
which may lead to some very complex policy records.
That is the reason why the policy constraint mechanism proposed is a lexical
constraint on the key record selectors rather than a direct constraint in the
policy record.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html