From: Dustin D. Trammell
Sent: Thursday, June 03, 2004 4:15 PM
On Thu, 2004-06-03 at 15:54, Ryan Malayter wrote:
Unless I'm missing something, a message with these properties:
ENVELOPE-SENDER: someguy(_at_)phisher(_dot_)com (no RFROM)
RFC-2822 From: Operations(_at_)FirstNationalBank(_dot_)com
RFC-2822 Sender: someguy(_at_)phisher(_dot_)com
will pass under the new SPF, assuming phisher.com has valid SPF records.
The responsible sender will be evaluated as phisher.com. The message
will display in many MUAs as something like:
From: someguy(_at_)phisher(_dot_)com on behalf of
Operations(_at_)FirstNationalBank(_dot_)com
My mother could be fooled by this, thinking phisher.com was somehow
associated with her bank.
Especially if 'someguy(_at_)phisher(_dot_)com' looks legitimately associated
to the
emulated entity, something like:
From: dtrammell(_at_)FNB-CustomerService(_dot_)com on behalf of
Operations(_at_)FirstNationalBank(_dot_)com
That's one stinky phish, Dustin. Never mind my grandmother, that one would
fool me. If things don't work out for you where you are, you've got a
brilliant career waiting for you as the uber-phisher :)
Going into SPF, I think we all realized that doing 2821 validation was
necessary but not sufficient to stop forgeries. At least we put
responsibility on the sending domain. However, From: and Sender: are what
the end user sees after a message passes 2821 validation tests, so end user
complaints to the wrong domain will still be common. Crypto signing is the
ultimate solution, but it is not cheap and will not likely appear for some
time. Anything that we can do now to address this problem would add a lot
of value for end users, make their providers lives easier and thus make SPF
look even better than it already does.
To start, I can think of five sender authentication problems that remain
after SPF operates, some more important than others. There may be more and
I welcome comments for anything I've missed. I leave out message body
authentication because that is not important to most user and it is best
served by a real crypto solution.
1) MAIL FROM: is not required to have any relationship with From: or
Sender:. The only place it is required to appear is the Return-Path:
header, which the end user never sees.
2) From: and Sender: aren't required to be related in any way. The intended
uses of Sender: are clear, but there is currently no way to enforce it. It
is either used to send mail on behalf of another individual/group
(generally within the same organization), by a mailing list to redistribute
mail or to indicate who the actual sender was when there are multiple From:
addresses (most MUA's don't even support this feature).
3) SPF cannot validate From: or Sender:, unless the PRA extraction on the
first hop operates to validate one of those. It certainly can't do both. I
have no idea how PRA extraction actually works. If anyone else has details,
please clue us in to inform this discussion.
4) SPF validates MAIL FROM: on the first hop only. It validates forwarders
on subsequent hops. Though forwarders operate at the behest of the final
recipient, unless that recipient is technically adept, they don't know how
well MAIL FROM: was validated by their forwarder. Depending on how good
forwarders become at SPF validation of incoming messages, this will be more
or less of a real problem.
5) SPF validates domains, not individual users.
I know that getting into anything during the DATA phase will bother some
people because SPF was originally intended to just deal with RFC2821
information. Having validated the 2821 information, I would suggest that we
might as well leverage the information we already have in hand to do any
2822 checks that we can. Besides, we've already stepped in it by agreeing
to do the PRA extraction to prevent one more kind of forgery. Since our
boots are already soiled, why not see how much validation we can do with the
information we already have? Think of SPF as a bundle of functionality.
The more useful work we can do with the DNS query we already did, the better
SPF looks as a package for people to adopt. In addition, how badly do we
want to implement an XML framework to deal with all the 2822 issues? Do we
look forward to publishing such an XML policy statement for our domains in
addition to the SPF policy statement?
So, how much of the five authentication problems above, and any that others
come up with, can we address with the results SPF queries? I think the
answer is, some of it, and that part could turn out to be useful for most
email.
To address problem #1, I propose that we _require_ the MAIL FROM: address to
appear in either From: or Sender: and enforce that by rejecting messages
where this is not the case. If Sender: exists, MAIL FROM: would have to
match Sender:. I still haven't seen any practical examples of why MAIL
FROM: _needs_ to be distinct from From:/Sender: that can't be easily handled
some other way. The small inconvenience this causes a few parties is, IMHO,
greatly outweighed by the benefits to everyone else. If this were required,
an SPF PASS on the first hop would mean that, for a single-sender message,
the From: domain is valid. This is a _huge_ benefit for everyone and the
down side appears pretty small, at least so far.
Problems #2 and #3 are much harder. For single-sender messages, there is
the degenerate case where the From: and Sender: addresses have the same
domain. This is obviously a PASS, since we already validated the domain
once (assuming Sender: == MAIL FROM: ).
When the domains are different, as in Dustin's stinking phish example, we
really have a problem. We could imagine requiring that someone sending mail
on behalf of someone in a different domain be listed as a designated sender
in their SPF record. Unfortunately, since all mailing lists operate this
way, it is not workable, unless we are willing to whitelist mailing lists
per-user.
An alternate solution is that we recognize that whenever the From: address
has a different domain from the Sender:, we regard the From: address as
untrusted _unless_ From: bears a crypto signature. If there is a crypto
signature, most MUA's already display visual indication of validation. This
implies, as Shevek pointed out, that MUA's need to flag untrusted addresses,
such as when From: and Sender: have different domains and From: is not
cryptographically signed. The From: would also be untrusted if there were
no Sender: and the From: domain had no SPF record (this implies the MTA did
not reject, but flagged the message). While that is a tough thing to make
happen, I agree with him that it is the only sensible thing to do. They are
already doing the difficult half of it (validate a signature and show when
it validates), so the rest should be much easier.
Problem #4 is only as big a problem as forwarders make it. If they reliably
do SPF checks on incoming mail, reject what they care to and flag everything
else with the SPF result (presumably in a special header), we could rely on
the MUA to display the trust status of the From: address. To the extent
that we don't know how carefully our forwarders do SPF checks and flag
messages they accept, we can't have a lot of trust in the visual indication
the MUA gives. Unfortunately, most end users do not know enough about their
forwarders to evaluate the quality of incoming mail checks the forwarder
does. The only way around that trust problem, aside from a reputation
system, is to have end-to-end validation in addition to the hop-to-hop
validation that SPF gives. Here are three ways to do that:
a) Strong crypto, such as S/MIME, PGP, etc.
b) Moderate crypto, such as DomainKeys or similar based on DNS instead of
PKI.
c) Moderate crypto consisting of SES signed outgoing messages with
signatures validated by the sender's DNS server.
Strong crypto is great, but it has been available for a long time and
adoption has occurred at a snail's pace. DomainKeys makes me queasy, since
it has the potential to break so many things.
The third possibility, validating SES signatures with a custom DNS server
module, is intriguing. The recipient would do a normal DNS query (I'm not
sure what type of query to propose, but it could be similar to the query for
a DNSBL) and the SES-aware DNS server would validate the signature and
return yes or no. To do this, the DNS server needs to know the hash key
(which should itself be a hash) for each domain or each user in a domain.
It also needs to have the user list for each domain and know the expiration
period for timestamps.
This keeps the network bandwidth ultra-light but puts some computational
load on the sender's nameserver. If there has to be a load, it arguably
belongs with the sender. The load could be easily reduced with hardware
assist for hash validation. This could be used as a DoS mechanism, but so
can any DNS query, including SPF and DomainKeys. DNS servers do tend to be
built for huge numbers of concurrent queries, so they are well-suited for
the task.
What I am proposing is to do the normal SPF hop-to-hop validation and the
destination gateway MTA would additionally validate MAIL FROM: via this DNS
mechanism _only_ for the case where there was a forwarder. In the absence
of a forwarder, SPF validates MAIL FROM: so there is no need to go further.
I would like to propose that we make SES signatures in MAIL FROM: part of
the SPF system. I suggest this because it gives immunity to bogus
null-sender messages. It would also eventually allow recipient MTA's to
reject in the absence of an SES signature without even having to do a DNS
query. That would be possible only if we _require_ the SES signature. The
originating sender address is still visible as clear text in the signature,
and I am no longer suggesting using CBV's for verification. This is simply
a practical matter: a system that SES signs its outgoing mail can reject
_all_ bogus null-sender mail before DATA without dropping a single valid
DSN. As part of an SPF "package", this will increase the benefits to the
adopters and thus encourage rapid adoption. It will also reduce the
backwash from worms and viruses, so why not do it?
Problem #5 is addressed by the same solutions as problem #4. Strong crypto
obviously validates the sender. DomainKeys was intended to validate only
domains, but someone suggested that it is possible to use it to validate
individual users. The SES+DNS validation scheme can certainly validate
individual users, as long as the nameserver has the hash key for each user
at each domain.
--
Seth Goodman