ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] updated threat analysis outline

2005-08-25 08:33:08
On Thu, 2005-08-25 at 12:37 +0100, Tony Finch wrote:
On Wed, 24 Aug 2005, Douglas Otis wrote:

I don't see where that talks about using the revocation ID to detect
forgery.

The recent suggestion was to consider the binding of the
mailbox-address/ signing-domain/revocation-identifier by the MUA as an
opportunistic identification, rather than attempting less protective
domain-wide assertions by the SSP. The MUA is able to associate visual
items from prior correspondents and obtain a higher granularity and
history of signed message sources without using any DNS lookups.

That seems plausible, but it assumes that the revocation ID will be varied
per sender and I don't think this will always be the case. For example:

attack: Mr Vendetta signs up for marketing email from example.com, then
spams it widely in order to damage the company's reputation. (This is a
direct reputation attack, as opposed to the parasytic reputation attack we
have considered so far.)

defence: Example.com wants to revoke email sent to Mr Vendetta without
affecting their other customers. Therefore they use a revocation ID per
recipient.

This doesn't break your scheme, but it does make it look a bit shaky.

I am having some difficulty following the scenario being described, so I
will respond to what I think is being said.  My apologies if I
misunderstood.

Example.com is having messages replayed by Mr. Vendetta sent to large
numbers of unintended recipients.  Although Example.com knows their
messages were not intended to be abused, they have discovered someone
like Mr. Vendetta is attempting to cause trouble after receiving abuse
reports or abuse feedback.

I liked the idea of including a hash of the RCPT TO line within a signed
portion of the message.  We will assume this protection does not exist
at this point.  

Example.com could wait a number of days for these messages to expire,
but they fear too many recipients will have taken steps to exclude mail
from their domains.   Upon a rudimentary check, it appears to be
marketing at example.com has gone berserk.

Example.com could decide to discontinue the use of the account used to
send the marketing material.  This problem has happened before, so in
this case example.com rotates between accounts when sending high volume
mail runs to ensure each run has its own revocation-identifier.

Had the RCPT TO hash idea been used, then example.com could also have an
idea where not to send their next run of mail to help prevent future
occurrences, but this does not exist.  It could be that example.com has
marked each message so they know where Mr. Vendetta obtained the initial
copy, as this has been a problem in the past.  That address is then
excluded from their mailing lists in subsequent runs, and perhaps they
may have their legal services contact Mr. Vendetta.

Now to protect their reputation, Example.com issues a revocation of the
message being replayed by Mr. Vendetta.  This revocation may affect the
delivery of some intended recipients, but the damage being done to their
reputation warrants this strategy.

Those who then see a continuation of messages sent by Mr. Vendetta will
also see that example.com has placed this message on their bad-list.
The recipients will immediately have cause to suspect the IP address
used to send such messages.  If Mr. Vendetta purchased the use of a
zombie army to send these messages, the revocation of the message
clearly marks each source.  Mr. Vendetta will may have difficulty
repeating this act, and example.com protected they reputation by
protecting unintended recipients.

This ignores the opportunistic identifications made possible by the
revocation-identifier.  However, example.com will have recommended the
bindings of the mailbox-domain and the signing-domain which excludes the
revocation-identifier, as they completely control the use of their
domain's mail and want their mail accepted without causing any user
prompts for approval.

-Doug  


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

<Prev in Thread] Current Thread [Next in Thread>