[ietf-dkim] New DKIM threat analysis draft

[Amir Herzberg]

Jim Fenton wrote:
> Amir Herzberg wrote:

>> I have only one real reservation. In section 6.3, discussing the 
>> message replay attack, esp. in 2nd paragraph... It is presented as if 
>> DKIM cannot be applied against replay since replay is 
>> indistinguishable from acceptable acts e.g. forwarding. This is not 
>> necessarily true. A legitimate application of DKIM may require senders 
>> to indicate specific recipient; this would allow replay prevention, of 
>> course in the price of requiring additional support to deal with 
>> legitimate forwarding. I'm not suggesting DKIM should be modified to 
>> support that, indeed this is not required at DKIM level at all, but I 
>> think the text now seems to exclude this usage, and this should be 
>> fixed imho.
> 
> What matters here is really the envelope-to address.  There are some 
> fairly large obstacles to signing the envelope-to address, including the 
> fact that it's not available to MUAs and the fact that it gets changed 
> when a message is legitimately forwarded, so I'm not sure how this would 
> work.  Can you provide more details of what you have in mind?

Please notice, I'm _not_ suggesting that signing the recipient should be 
another DKIM requirement. On the contrary, I agree that DKIM can have 
significant value without this and that signing recipients is a 
non-trivial issue, e.g. with legitimate forwarding scenarios. But I 
think it is fair to say that this is not a DKIM issue, in the sense that 
some DKIM users (senders and recipients) may agree on some standard 
solution, without requiring change to DKIM - so, the text simply needs 
to be modified so that we don't _exclude_ such usage of DKIM. BTW, I 
believe this issue is Ok with Meta-Signatures.

I can write a proposal for the text, if this can help fix the text or at 
least clarify the issue.

If you (or others) ask `how could it work at all`... let me give one 
example (again: NOT suggesting this specific mechanism - for DKIM or at 
all...). Remember: it's just an example, I'm not suggesting this for DKIM!!

Suppose after we deploy DKIM, everybody is happy for a while, but then 
spammers begin using Zombies to send their spam (by sending it from a 
DKIM-compliant domain to a host they control, and from there 
`forwarding` it to many victim recipients). At that point, some of us 
decide to try this idea over DKIM, rather than reinvent DKIM from 
scratch. So we want to design a `DKIM extension` or maybe I should call 
it `DKIM application` since it does not require changing DKIM at all.

One way to do so: senders (or more precisely the DKIM agent, usually 
domain outgoing MTA) indicate their support for `recipient signing` by 
some tag (x-recipient-signing: enabled). The DKIM-recipients may now 
have an option for handling messages with x-recipient-signing enabled. 
This option may be to (always or when spam suspect level is high) to 
`bounce` this message, indicating recipient signing is required - and a 
recipient identity (e.g. rcpt-to to recipient match). Sender may cache 
this information for later use.

How can this help? Well, my favorite use is to make any signed spam 
message (with a recipient identity) equivalent to a mini-check - 
therefore, charge the signer (spammer) for the spam.
-- 
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame