[Asrg] mail security

[Ian Eiloart]

--On 20 January 2009 11:44:26 -0800 Dave CROCKER <dhc at dcrocker.net> wrote:

>
>
> John Levine wrote:
>> DKIM at least starts to address those problems, but it still doesn't
>> begin to try to deal with the much harder problem of lookalike
>> domains.  Let's say you get a message from security at pay-pal.com, which
>> is 100% DKIM, SPF, and Sender-ID approved.  Is that Paypal?  How can
>> you tell short of manually looking up WHOIS registrations?
>
>
>
> Two points:
>
> 1.  The word "security" is not all that helpful in these discussions.  To
> security technology experts, it means too many things to know what is
> meant in a particular case.  To the rest of us, it carries too little
> precise meaning.
>
> 2.  Almost all of the discussions about these authentication-related
> technologies start with the authenticated identifier and then talk about
> what you can derive from it or how it might be spoofed or otherwise
> abused.  Since that is exactly what must be done with suspect messages,
> the model seems to make sense to (re-)apply for authentication.  I now
> believe it is exactly the wrong model.  That's a model that looks for the
> problem, the attack, the basis for suspicion.
>
>
>
> A very different model starts as a model of trust and specifies a table
> of who is part of the model.  In other words, it works in the oppsoite
> direction. When a message shows up, the only question is whether that
> message falls under that umbrella of trust.  If it doesn't, then we are
> done with that model, for that message.  Any further consideration of
> that message has nothing at all to do with the trust model.  The
> authenticated identifier is the sole, simple lookup string into that the
> model.  Either the identifier string works or it doesn't.

Agreed. That's why I'm discussing SPF or DKIM with a reputation service. In 
the first instance, my reputation service is going to be a local 
whitelisting mechanism. I'll probably have some domains whitelisted for my 
entire site. Perhaps all .ac.uk domains, for example. Then I'll allow users 
to whitelist domains and addresses that they trust. However, the 
whitelisting mechanism will rely on an SPF or DKIM pass.

So, as you say, I'll check that the sender address falls under my umbrella 
of trust - that it's in my whitelist. If not, I'll fall back to my old 
mechanisms. But, if it does fall under my umbrella of trust, I'm still 
going to check for either an SPF or a DKIM positive match. If I don't get 
that, then I fall back to my old mechanisms.

I hope that an trustworthy external reputation service will emerge that 
allows me to place others under my umbrella of trust, even when they're not 
listed locally.

I'll need some rules about who people can whitelist (and blacklist, too). 
For example, I don't think I'd allow anyone to whitelist hotmail.com as a 
domain, but I'd allow then to whitelist specific addresses. On the other 
hand, I'd allow them to whitelist the domain of a local school or local 
government organisation.

> Concerns about spoofing the identifier, re-purposing its use, and
> corrupting the content -- authentication, authorization and data and
> signature integrity -- are all valid for evaluating the underlying
> technology but they really are secondary to any serious discussion of the
> model.  After the briefest review to ensure that a particular technology
> has made specific and acceptable choices for the "security" questions,
> the questions should not burden debate about use of the technology.
> Instead we seem to find these questions hashed, rehashed and hashed
> again, as the focus of community debate.
>
> When the anti-abuse world discusses use of these authentication
> technologies, we need to stop being the anti-abuse world and start being
> the trust world.  The anti-abuse world really has the receiving assessor
> as an isolated island of suspicious.  In today's Internet, that's
> required.  But the trust world is quite different.  It is collaborative
> -- between signer and receiving assessor -- and deterministic, rather
> than vague and heuristic, and strictly the effort of the receiving
> assessor.
>
> Totally different model.  So we need a totally different approach to
> talking about it.
>
> d/



-- 
Ian Eiloart
IT Services, University of Sussex
x3148