From: Meng Weng Wong
Sent: Wednesday, June 02, 2004 2:42 AM
On Tue, Jun 01, 2004 at 04:46:51PM -0400, Stuart D. Gathman wrote:
|
| There is actually no need for any mechanism other than exists.
| The other
| mechanisms exist only as an optimization for common checks
| which can be safely
| performed on the receiving MTA without consulting the sender domain.
The above is true if we limit sender authentication to
designated sender schemes. However, if we admit the
possibility of non-IP-based schemes eg. DomainKeys, PGP,
SMIME, Vanquish, PennyBlack, etc etc, the case for new
mechanisms makes more sense.
Along with Meng's terrific recent piece on the ideas surrounding SPF,
Stuart's important realization above and Meng's answer have gotten me
thinking about how far a designated sender scheme could/should go as a
sender authentication mechanism. After all, there a lot of other techniques
that could fit into the larger picture that Meng presented so well.
Many people consider DomainKeys the next step in this framework, so I
recently took another look at it. I was interested to see how it differs
from S/MIME, which despite what the DomainKeys description claims, is widely
supported today. It appears that there are two main differences:
- DomainKeys seeks to be a mailer-to-mailer solution operating on a
per-domain level, while S/MIME is an end-to-end solution whose result the
end user interprets
- DomainKeys puts the domain public key in the DNS, while S/MIME puts each
author's public key in a certificate in the PKI
Similarities include using a RSA-based PK crypto system and signing of most
headers plus the message body. Though I haven't looked at the
implementation details, both of the differences listed above make DomainKeys
suitable as an automated forgery rejection mechanism.
Back to the original question: how far could/should a designated sender
scheme go into sender authentication? The easy answer, for me, is as far as
it can without hindering it from accomplishing its original goals. With
that in mind, let's ask what, exactly, does DomainKeys offer the mail system
and its end users?
1) It signs some of the headers with the private domain key. This proves
origination by a designated domain MTA.
2) It signs the message body with the private domain key, which accomplishes
two things:
a) This protects the recipient against message tampering.
b) This protects the sender against joe-jobs using a replay attack.
The first point is particularly interesting. Though it uses a crypto
design, it still only validates that the mail came from an MTA that had the
domain private key. Therefore, it is still a designated sender scheme. It
does not validate authorship, unless that is guaranteed indirectly via the
use of authentication to the MSA. However, it does allow the final gateway
MTA to do the validation, regardless of message path.
While point 2b above, protection of the sending domain against joe-jobs
through replay is an important goal, it just keeps the protocol from being
abused. Point 2a above, protecting against message tampering is arguably of
very little value to most users. Though most of us have used one or more of
the PK schemes for a while, how common have we detected message tampering,
aside from mailing list or forwarder "add-ons"? I would argue that
detection of message tampering is an uncommon need and the majority of email
messages need not be encumbered by it.
What does a typical email user really need in the way of sender and message
authentication?
1) Trust that the mail is from who it says it's from. This means the
RFC2822 From: and Sender: headers.
2) Be able to issue a meaningful complaint if they receive unsolicited
advertising or inducements into suspected illegal schemes.
SPF currently checks only designated sender at each hop. At the first hop,
however, validating the designated sender actually validates the
return-path, which we have all identified as a necessary first step for
sender authentication. If the mail is forwarded, the final recipient has to
trust that the forwarders they set up do this originating hop checking for
them. This is not an unreasonable assumption, but it requires average users
to understand something about email authentication, which is not realistic.
The current SPF does not provide a method for the final gateway MTA to
validate MAIL FROM: in the presence of forwards.
In the merged SPF-CID proposal, a receiving MTA parses the 2822 headers to
make sure that they are consistent with the current hop designated sender
that SPF checks. This function is a useful and inexpensive enhancement, and
I hope people can separate this from the whole XML/MS/CID argument. Despite
all this, From: and Sender: are still not validated.
The question I ask is: _could_ we do better, within the confines of an SPF
system, without jeopardizing our original goal of lightweight checking the
designated senders at each hop? I think we can, and here are a couple of
thoughts.
1) We could require that the originator's MAIL FROM: appears in From: or
Sender:. I have been trying to think of something this breaks, and so far,
I come up empty. Even in the case of SRS or SES, the originating address is
still visible inside the signed address. For SRS, only the opaque
database-driven signing method obscures the originating address. Since this
variant has not been widely deployed, it is not an impediment.
2) We could give the destination gateway MTA the ability to verify the MAIL
FROM:, in the case where the mail has been through a forwarder. We could do
this, for example, using an SES signature and, as Stuart pointed out, the
exists macro along with a DNS server that knows how to validate SES
signatures. This puts the validation load on the sender side, where it
belongs, but keeps it lightweight because it uses DNS and existing SPF
mechanisms.
3) Implementing both #1 and #2 above, along with per-user hash keys gives us
a system where the recipient can also validate authorship, which goes
farther than DomainKeys. This is not as strong as what you get from an
X.509 certificate pair, a CA and the PKI, but it is pretty darn good
authentication (PDGA!) considering it only uses a little bit of DNS
resources over and above the present SPF check.
Stuart has argued, with much merit, that pre-DATA and post-DATA checks
naturally fall into separate categories and anything post-DATA should use
some other mechanism, like XML (gasp). I would like to argue that any
post-DATA checks that we can _easily_ do without mucking up the language, we
should do, despite the apparently convenient dividing line between before
and after DATA operations.
The suggestion in #1 above falls into this category and is independent of #2
and #3 above. This would add considerable merit to the SPF case by
increasing confidence in From: and Sender:. The first hop recipient knows
they are talking to the originating gateway MTA. Their SPF check on MAIL
FROM: validates the return-path. That recipient could require that the MAIL
FROM: address appears in either the From: or Sender: headers and reject the
mail if it does not. How does a given ISP know if they can allow one of
their users to originate a message claiming a foreign domain name? Easy,
check the SPF record for the foreign domain and see if the ISP (and perhaps
the specific user, if the SPF record includes that) is a designated sender.
If not, the MSA can return the message to the author as not having the
domain owner's permission to use that domain name. If this were part of SPF
requirements, that would further encourage domain owners to publish an SPF
record. This is because the domain owner gets some assurance that
responsible ISP's will check the SPF record before allowing any of their
users to utilize the domain name.
This tends to address forgeries at the source by not allowing them out of
their originating networks. This also accomplishes a very important feature
of DomainKeys: making sure that From: and Sender: are valid at the domain
level. I would argue that the incremental cost of doing this in conjunction
with present SPF checks is exceedingly low. The potential benefit is large
enough that we almost need a good reason _not_ to do this.
If we can do the admittedly harder job of #2 above, we now allow the
destination gateway MTA to validate MAIL FROM: when there was a forwarder
involved. This system adds the MTA-to-MTA validation that DomainKeys does
but at a much lower cost. More importantly, the validation cost is not
borne by the recipient MTA, but instead by the sender's DNS. The important
realization here is that DomainKeys is still a designated sender scheme, and
nothing more, despite the crypto implementation.
If we can get to the system of #3 above, we will have used a designated
sender mechanism to authenticate authorship without burdening recipient's
MTA and without extending SPF semantics. This offers a lot more value to
the end user than DomainKeys at very low incremental cost over existing SPF.
If a user really needs to detect message tampering, they are part of a small
subset of users that existing PK crypto mechanisms serve very nicely.
--
Seth Goodman