[ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

[Scott Kitterman]

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.com instead of From: service at ebay.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