ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] New DKIM threat analysis draft

2005-10-10 10:16:18
I think this problem goes away if we understand the purpose of DKIM to be to 
allow parties to provide the recipient of an email with additional information 
that allows them to make a more efficient and/or more accurate determination of 
whether they are willing to accept it.
 
There is the capability to provide this information in the existing DKIM core, 
there is also a capability that allows message senders to establish per message 
revocation using the DNS hack described. Provided we do not allow 'wrecking 
ammendments' whose only purpose is to prevent these applications these can and 
should be left to later.
 
What I would like to see eventually is a 'DKIM cookbook' RFC that describes 
standard signing strategies that might be used by particular types of sender 
and/or forwarder. But that is something that I think can only be written in the 
light of experience.
 
 
Phill

________________________________

From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Amir Herzberg
Sent: Sun 09/10/2005 10:14 AM
To: Jim Fenton
Cc: IETF-DKIM; herzbea(_at_)macs(_dot_)biu(_dot_)ac(_dot_)il
Subject: Re: [ietf-dkim] New DKIM threat analysis draft



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
_______________________________________________
ietf-dkim mailing list
http://dkim.org



_______________________________________________
ietf-dkim mailing list
http://dkim.org