Re: [Asrg] misconception in SPF

On 10/12/2012 08:43, Martijn Grooten wrote:
> > but what will I say them when they´ll see
> > mails "comming" from a subdomain of the real domain that the mail
> > claims to be from and no checks failed?
> As others have pointed out, SPF is not for end-users. If you desperately want 
> them to make sense of SPF checks, make sure you tell them that not failing SPF 
> means exactly nothing; it definitely does not mean the emails passed SPF, or 
> anything else that should give you extra reason to assume the domain is not 
> forged.
>
> If you believe they are really clever, you may consider telling them that in 
> case of important emails, not passing SPF is a reason to be extra suspicious. 
> But I personally wouldn't go there, even if the users had invented the Internet.
Well, it generally doesn't actually matter who an email is from - if 
you're just going to read it. It only matters if you're going to click 
on links in it, or open attachments.
It doesn't really even matter who the email is from if you're going to 
click on links - all that matters is where those links go. If I get a 
forged email telling me to click on 'www.facebook.com', then what harm 
will it do - as long as the link REALLY is www.facebook.com.
So, what we really need (AFAICS) is not a way to detect forged messages, 
but a way to check that links in the message go to where the user would 
expect them to go.
So, two things:

1) I believe that any prime 'phishing target' (banks, Facebook, etc) 
should not put links in their emails - EVER. If you get an email from 
Facebook telling you you have new notifications, then the user should 
just go to Facebook independently. That way, you're pretty much 
protected from phishing emails. Unfortunately, this isn't going to 
happen, because users are generally too lazy, so want the emails they do 
get from Facebook etc to contain easy to click links/'buttons'.
2) A possible solution. Nothing amazingly clever, but AFAICS it would 
make it easier for users if it was implemented. I don't doubt it'll get 
shot down, but here goes...
(this isn't the "final" description of the idea, given that its likely 
to get shot down. it's just a rough outline)
 - The mail receiver (MUA or a spam checker) gets the message, and 
either looks at the return path domain, or some other 'marker' in the 
email to find the 'canonical domain' (doesn't have to be encrypted or 
secret)
 - The mail received software checks a DNS record at that domain to see 
if they support this facility. (as a method of protecting against a DDOS 
against random companies)
 - The mail receiver software checks a certificate at the domain it 
found in the step above (eg by going to https://www.<the domain>, or 
some other). It checks that the certificate is a valid, CA signed 
certificate, and can thus, reasonably confidently, give an organisation 
name where this message purports to be from. It can display this to the 
user.
 - The mail receiver software then checks the links in the message 
against something at that domain - eg download a list of valid link 
hostnames from the domain (using https), or use a surbl-like check using 
that domain as the database, or whatever
 - The mail receiver software now has a bit more confidence that the 
email only contains links which the purported originator would approve of.
Possible flaws I can see
- the DNS/website of the phish target could be hacked. If that is done, 
then there's a bigger problem...
- the certificate may show that the organisation is www.paypaI.com, 
because the phisher has got a certificate which only verifies the domain 
name, not the organisation. This may fool some users. Could we mandate 
certain types of certificate for this facility?
- extra work by the receiving software. But, given that things like 
Thunderbird already look at email links and suggest that they may be 
dodgy, the extra load may be considered acceptable
- possible DDOS vector against someone's DNS/web servers

- if the phish target uses unprotected redirection URLs, those could be 
used to get around it
- if the phish target doesn't know what domains they use, that could 
cause false positives


-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg