Douglas Otis wrote:
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
Once it gets to the MUA, it's too late. I want to reject the message
during SMTP (after DATA, but before OK).
Your notion seems to consider mailbox address authorization will be the
principle mechanism used to reject messages, as far as signatures are
concerned. While that may sound good, I find it incredible. Do you
expect abusers to be that cooperative? More is accomplished with
expectations of good governance by those that sign email, than by
creating a matrix of authorization hurdles for mail administrators to
navigate. Abusers will nevertheless be the most adept.
Yes. I agree that once deployed it's a scenario that isn't likely to
come up that often. Because the abusers will adapt and once a certain
minimum deployment level is reached, they will be alrgely deterred from
using protected domains in protected identities.
If it's an SMTP rejection that gives no opportunity for social
engineering to work, the threshold for deterrence is likely to be much
lower.
If phishes targetting popular domains such as ebay.com start saying
From: service(_at_)3bay(_dot_)com instead of From: service(_at_)ebay(_dot_)com, I think that's
significant progress. What I'm suggesting is not a panacea against
phishing (so you can stop arguing that it won't be, I agree), but to
give domain owners and receivers a simple tool to defend against a class
of attacks.
After going through these efforts, incidence of mailbox-address
authorization failure will likely be infrequent. Adding a means for the
recipient to capture bindings based upon a message held in high
confidence, can be effective against targeted spoofing. An MUA captured
binding mechanism can check for pretty name collisions, as well as
checking against the mailbox-address. The MUA can even attempt to
detect character substitution schemes or drill down a list of known
exploits.
I'm not opposed to exploring something like this in the working group.
Perhaps it has merit. We need to make sure we get the scope of the
charter right. I just want the SMTP time approach too (and first if it
comes to that, but if it's so easy, we can probably have both to provide
broader protections).
This could work like self-signed certificates used to handle typical SSH
sessions. When there is no reason to believe things have changed, then
being prompted to save a new binding, which should also show the
accountable domain, provides an opportunity to mark this binding for all
future messages as good or bad automatically. The opportunity to spoof
someone would be rather remote with this type of semi-automatic
protection. If this were the case, do you really think there would be a
need to ensure the mechanism for the initial rejection in this case must
be optimal?
Yes. Your proposed mechanism needs to wait for MUA upgrades. An
MTA/MDA solution could be more widely deployed more quickly.
It would seem our biggest disagreement is where mailbox-authorization
schemes should reside. I would rather not muck with changing behaviors
and be more pragmatic about how security can be enhanced without placing
ever growing burden upon DNS and email administrators. DNS may face a
real challenge with DNSsec as well.
I would rather give domain owners/receivers the tools to do that job
where it can most easily be done. I think that's in the MTA.
I expect that if the protocol is well designed, the impact on DNS
performance will evolve gradually and the infrastructure will have time
to adapt. Given the rate of DNSsec deployment, I think that's not
something that's likely to sneak up on us.
I think we are starting to circle again and so perhaps we should try to
move on. It does seem to me that there are methods that might be
developed relatively easily to provide some anti-forgery protection in
DKIM. Clearly there is more than one view on how this should be done.
Let's include it in the work of the group and then get to it.
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org