From: [EMAIL PROTECTED] on behalf of Amir Herzberg
Sent: Sun 09/10/2005 10:14 AM
To: Jim Fenton
Cc: IETF-DKIM; [EMAIL PROTECTED]
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
