This message contains editorial comments on draft-ietf-dkim-base-00.
In a separate message I'll explore a larger scale issue: whether
it's a good idea to invent a totally new protocol rather than
reusing something existing (e.g., S/MIME).
S 1.1.
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities,
This claims seems somewhat disingenous. DKIM depends for its
security on DNS, which is *known*to be insecure. S 8.4 suggests
that this problem will be overcome via DNSSEC, which certainly
does require well-known, trusted CAs, namely the roots. Note also
that in classic PKI systems, the public and private key pairs
are not ISSUED by the CAs, just attested to by then,
S 3.3.
As noted previously by Russ, I think 512 keys are unwise.
S 3.5.
require the attacker to choose both sets of input text; given
a preexisting input (a "preimaging" attack), it is still hard
(1) Typically people use the term "preimage" rather than preimaging.
Even more precisely, this is a second preimage attack.
(2) As noted in my review of a previous version of this
document, collisions are actually an issue here if the
MTA does content filtering before signing.
"I'm not sure that I agree with this analysis. If the model for the
MTA is that it's going to blindly sign any message from someone
who is authorized, then I agree with you, but that's not the
only model. Consider an MTA which does some outgoing spam filtering
and only signs messages it thinks aren't spam--this is to contain
botnet compromise.
In this case, the attacker prepares two colliding messages, one
spam and one innocuous. He gets the MTA to sign the innocuous one
and then substitutes on output. Note that this is possible because
of the extension property of SHA-1 and the choice to put the message
contents first in the SHA-1."
It seems to me that the x= needs some explanation about what happens
in the case of clock skew.
S 3.6.
DKIM keys do not require third party signatures by Certificate
Authorities in order to be trusted, since the public key is retrieved
directly from the signer.
Well, no, it's retrieved from the DNS server for the signer's
domain, which may or may not be the same thing.
S 4.
For these reasons, multiple signatures are not prohibited but are
left undefined.
I don't see how this makes sense:
(1) If they're undefined, that means that two parallel signatures
can be rejected by the verifier, even if they're both verifiable?
(2) Given that multiple signatures are required for algorithm transitions,
I don't see how you can avoid specifying behavior here. The obvious
behavior seems to be to accept any valid signature and ignore the
others.
S 6.3.
o Based on the algorithm indicated in the "a=" tag,
* Compute the message hash from the canonical copy as described
in Section 3.7.
* Decrypt the signature using the signer's public key.
o Compare the decrypted signature to the message hash. If they are
identical, the hash computed by the signer must be the same as the
hash computed by the verifier, and hence the signature verifies;
otherwise, the signature fails.
GAH! Please please please don't describe digital signature verification
this way. This only applies to RSA, not, say, DSA. I note that
my previous review of draft-allman-dkim-base pointed out this error
as well.
S 8.2.
What about a compromised MTA?
Also, it's worth noting that malware could suppress bounces.
S 8.4.
To systematically thwart the intent of DKIM, an attacker must conduct
a very costly and very extensive attack on many parts of the DNS over
an extended period. No one knows for sure how attackers will
respond, however the cost/benefit of conducting prolonged DNS attacks
of this nature is expected to be uneconomical.
I don't find this at all convincing. The resources being used are
compromised computers, of which there are plenty. Not only is this
likely to be economical, it seems quite likely if DKIM is widely
deployed.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html