[Asrg] mail security

[John Leslie]

John Levine <johnl at taugh.com> wrote:
> 
> Why do you keep harping on SPF?  Of all of the proposed security
> schemes on offer, it is by far the worst.

   SPF has been due for its 2-year review (of Experimental Status) for
a while now. Hopefully it will get a useful review, and I choose to hope
it will get enough of an overhaul to become useful. With some simple
changes it could give a measured likelihood that a 5321-MailFrom deserves
to be trusted for generating bounces -- a major win.

> It doesn't even attempt to secure any part of the message visible to
> recipients,

   Nor should it, IMHO. Other approaches are better for that.

> and it only works for the subset of mail that is sent from a fixed point
> to recipients who don't remail or forward it.

   This feature could be substantially mitigated in a number of ways.
Unfortunately the Experimental spec freezes a moment in time where MARID
was struggling with that issue (and others) without having time to reach
a useful consensus.

   Fundamentally, of course, the attempt to have one-size-fits-all
processing by the receiving MTA is dubious. It's not the coding of SPF
records that breaks forwarding: it's the processing of them. Relaxing
the processing rules could help a lot.

> (Despite endless claims by SPF's fans, that last part is a fundamental
> design failure of SPF, not of the mail system.)

   The original SPF design tried to be all things to all emailers --
a hopeless task. I think two years of experience in Experimental status
has moderated that desire. And I see promise in the use of the pending
Authentication-Results header (though I must agree with Doug Otis that
it would be stronger if it included the IP address).

> 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. 

   Nor should it, IMHO.

> 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?

   Most folks couldn't tell if they _did_ look up WHOIS -- so at first
blush I'd say that's the wrong question.

   Let's think about it differently.

   Why does phishing work?

   It works because the security of financial transactions depends on
obviously insecure passwords (anything simple enough for average folks
to remember _must_ be insecure) entered onto loosely secured websites.

   Compare that to ssh. Is there a record kept of what certificate is
used? Are there obvious warnings when you start a session with a
server whose certificate you've never seen before? Or even a warning
when the certificate changes?

   More to the point: why do financial institutions depend upon code in
browsers instead of calling a separate application for authentication?
The quality of security in browsers varies from barely adequate to
downright laughable (with a lot of customers using outdated browsers
closer to the laughable end of that range).

   Is there actually any point in trying to solve phishing issues by
verifying the origin of email if the customer is going to depend on
a known-insecure web-browser?

--
John Leslie <john at jlc.net>