Re: antiphishing idea
Steve Atkins <[email protected]>
| Newsgroups | gmane.ietf.asrg |
|---|---|
| Message-ID | <[email protected]> |
On Nov 17, 2011, at 10:30 AM, Christian Grunfeld wrote: > Domains should have to publish in their DNSs the message-id (among any > other thing) through a TXT or A record of any legit mail sent by them. > The TTLs of those records can be adjusted to compensate for queued > mails, etc. The obvious flaw with a simple version of this proposal is replay attacks. Once someone has sent me an email, I can send email "from" them just by reusing the message-id. One obvious fix to that is to allow each message-id to be used and validated exactly once. The first MTA to see that message-id considers the message to be valid, anyone after that doesn't. That's very similar to the goodmail token approach. Another obvious fix would be to include a timestamp and invalidate messages that are "too old" - but the window in which you'd expect to see legitimate delayed messages is longer than the time you'd expect replay attacks to be attempted. Another obvious fix is to tie the message-id to the content of the message in some way, by including a hash of the message and a subset of the headers. That would work quite well, but still leads to the operational problem of requiring a tight binding between the sending MTA and the DNS server for that domain, and the significant problem of it defeating the caching that DNS provides, leading to both high traffic DNS queries and a likelihood of DNS lookup failures (and hence delayed or lost email). One way to work around that would be to look up not a unique token from the message-id for a simple match, rather to look up a substring of the message-id to retrieve a cryptographic key that could be used to validate the rest of the message-id. That key entry would be cached well by DNS and would work pretty well. Replace message-id with DKIM headers and you have DKIM. The less obvious flaw is that you're trying to combat phishing by "protecting" the From: header by requiring it be authenticated, and requiring all email using that From: domain be sent through a small number of "trusted" MTAs. That's exactly what ADSP attempts to do, and it's been shown to cause fairly serious loss of legitimate email (because it's extremely rare that you really know all legitimate email is sent from just the servers youo think it is). And it's been shown not to work terribly well against phishing, as there's not enough information in a From: header to tell you if the mail is legitimate. If I register the domain paypal-billing.com, send mail From: it, with valid-by-your-scheme message-id headers then it's 100% legitimate email as far as recipients are concerned. And it is legitimate - it's just not from paypal. Cheers, Steve