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
