On Wed, 2 Jun 2004, Seth Goodman wrote:
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,
I really hope people are not going to use it the way it is. It breaks way
way too much staff in current email path. A lot more then SPF mail-from
and similar systems.
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
Correct. Another big point here is that S/MIME requires end-user to support
it for in order to read the email (so if you send s/mime to somebody who
does not support it, he'll not be able to read your message). While domain
keys only puts small signature and email is still readable by end-users
who don't know about it.
- DomainKeys puts the domain public key in the DNS, while S/MIME puts each
author's public key in a certificate in the PKI
Which is kind of both good and bad feature.
Similarities include using a RSA-based PK crypto system and signing of most
headers plus the message body.
S/MIME is not usually used to sign headers, it signs message body (MIME
content), and that is good choice.
Signing of the headers is DK's biggest problem because if you sign all
headers and message goes to intermediate MTA that does not know about DK
but that modifies headers (almost every mail list is like that) and then
to recepient MTA that does know about DK, the end-result is that message
would be rejected because recepient MTA would see different hash of
message body that does not correspond to original message DK signature.
Though I haven't looked at the
implementation details, both of the differences listed above make DomainKeys
suitable as an automated forgery rejection mechanism.
Not really forgery rejection, but mechanism to make sure the email is not
changed in transit and that it corresponds to certain domain that provides
the holding place for public key.
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.
The sender can use "me(_at_)domain(_dot_)com" in his "From:" header and
different
email addresses in "Sender" and other headers. The DK knows nothing
about that and does not say anything about sender being authorized to
use such email address. But when message is then sent through MTA
example.com and that MTA supports DK and signs the message, what it does
tell us is that this user who says he is me(_at_)domain(_dot_)com is authorized
to
send messages through MTA that correponds to set of servers for example.com.
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.
That I do not see. Please descibe in more detail on how replay attack work
that DK would stop it.
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.
The message path does not matter only if the message has not been changed
in transit, but in many (majority even) of the cases of complex email path
that is not true. Above I already wrote about big problem when message is
changed and intermediate MTA does not know about it which would cause
dk supporting end-user mta to reject the message. At he same time if
intermeidate MTA does know about DK, it would need to resign the message
and that means recepient MTA will verify that new signature and not the
original or full 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.
That is what SPF is trying to do.
2) Be able to issue a meaningful complaint if they receive unsolicited
advertising or inducements into suspected illegal schemes.
Actually DK helps in this. You want to issue complaint to service that was
used by the sender and authorized him. In this case, DK provides link to
such a domain.
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.
Correct. SPF-CID is hop-hop validation.
But DK can become sender->recepient validation if it stops trying to sign
headers or does it in more appopriate way.
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.
MAIL FROM: is designed email address to recepive bounces per RFC2821.
It tells very little about the real sender and has no requirements to
correspond to it (and doesnt for many formwards and email lists).
The biggest problem is that MAIL FROM: address is abused in such a way
that wrong people receive bounces from spammer emails and these people
get very angry as a result (and this includes myself:)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net