spf-discuss
[Top] [All Lists]

RE: Domain Keys vs Sender Permitted From vs Sender Policy Framework

2004-06-03 04:09:51

On Wed, 2 Jun 2004, Seth Goodman wrote:

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.

That would be an advantage.  I believe that S/MIME support is pretty broad,
though, just like PGP and variants.
Call it a "feature" then as its both good and bad depending on circumstance.
But certainly having more MUAs being able to handle encrypted and signed 
emails is better for adaption of such email methods.

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

I don't know whether or not it actually signs the From: header, but it does
enforce the fact that the address in that header is the same as the address
on the signing certificate. I thought it actually signed the From: and
Date: but not Subject:, though I could be all wet on that.
Since user's email is part of his s/mime certificate, it is basicly true, 
although it does not specifically sign the From header. The X.509 structure
has two date fields - issue data and expiration date.
 
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.

I didn't look at the details of the DK signing, but that sounds like a real
problem.  Do you know exactly which headers DK signs?
All of them. Per specification the DK signature is added to the top most 
of the email and signs everything below it. If intermediate system wants
to resign it, they add additional signature (above the existing received
headers) but it opens up a problem while intermediate MTA doesnt know
about DK while both sender and recepient do. And as with many other 
proposals they should be evaluated on how their adaption would work with 
existing infrastructure and should not assume that every MTA in the mail 
path would support new feature.
 
I guess I'm confused here.  If DK doesn't care about From: and Sender:, it
wouldn't add anything to what SPF already does.
Not quite, in comparison DK maybe though of like authorization of EHLO 
name, i.e. authorization of the MTA itself (not specific to "From:" line), 
except that with EHLO its always hop-hop where as DK has possiblity to 
provide multi-hop verification as long as intermediate systems only add 
additional received headers and not actually modify any other headers in 
the email. And obviously because it actually signs the message it also 
provides possibility to confirm that message has not been tempered with
by something in the middle of the transport.

If, as you say, the MTA
makes sure the user is authorized to send mail from a particular domain,
what fields does it use to determine who the user is?
It does not use any fields for that. What it is that DK signature header 
itself is composed of multiple parts, one part is crypto signature, other 
parts include "domain" and "selector" (can be actual user or possibly 
just reference to common signature). 

I have to note that just today (as I was writing this) Microsoft released
its own "Email Postmarks" proposal to compete with Yahoo Domain Keys. It 
is the same concept of signature in the mail to be added by MTAs and verified
through dns. Their proposal tries to reuse S/MIME for this and as such does
not require signing of the headers and only the body. In my view this is 
generally a better proposal (and those who know me will probably be really
surprised to not hear me critisize Microsoft). Their proposal document 
(not yet in draft format) can be found at:
 http://www.lessspam.org/EmailPostmarks.pdf
 
My main problem with their proposal is that yet again they want to use
dns txt records (same _ep record as with callerid) now to store multiple
certificates and yet again in xml format. I'm very concerned that DNS
infrastruture will simply not handle well if we put such large data into 
it for every domain and at this time I can even agree with proposal to
reference such complex SPF record from simple dns record. I would go 
futher and say that new protocol needs to be developed for general policy 
information exchange.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net