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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg