spf-discuss
[Top] [All Lists]

Re: [spf-discuss] DKIM-SSP integration SPF

2006-08-12 10:47:43

On Fri, 11 Aug 2006, Scott Kitterman wrote:

On Thu, 10 Aug 2006 22:53:13 -0700 (PDT) "william(at)elan.net"
<william(_at_)elan(_dot_)net> wrote:

Later I did come up with way to "mix" SPF & MAIL FROM authorization
with signatures. The idea was to include name of the server doing
signing as part of the signature data and then do SPF authentication
against that name (i.e. resolve that name to ip address and check if
that ip address is allowed based on MAIL FROM - the answer should be
yes and this way it also bypasses direct SPF forwarding failures). But
this is not possible to do with DKIM as it does not include server name.

Doesn't DKIM include the ability to sign arbitrary header fields? If so, I would imagine we could define a new X- header like X-SPF-Origin and senders could sign it. As long as it's signed, I think that's as good as in the signature...

This is an interesting idea but its not all that simple.

Consider what will happen when somebody who you don't know just takes
your mail server name and puts it in X-SPF-Origin field. Then he uses
your domain's MAIL FROM his email and sends email out signing it with
public key from some other domain. You get the email, verify that its
signature is correct and then assume that X-SPF-Origin is right and
verify SPF based on that. But what happened is that you're totally
dependent on the signature and here that "some other domain" a bad
guy could have just registered that domain (with bad whois, etc) just
for purposes of sending bad email and forging your MAIL FROM.

This BTW was actually a great example to illustrate why mixing different
authorizations methods has to be done very carefully. Basically the issue is that truthfulness from SPF would fully depend on the signature and on some other domain in the signature and that is not ok. The first one (that it depends on security of the signature system, i.e.that signature PKI can not easily be broken and bad signatures created) would have to be accepted but 2nd one (tat it depends on some other identity) is not typically something you want to accept.

The correct system to deal with it would have to require signature to
be verifiable based on mail server name you enter in that extra header field, i.e. it in case of DKIM it would mean that public key is not
only available at _selector._domainkey.<domain in d tag> but also in
_selector._domainkey.<host name in X-SPF-Origin> field. This is too
much to expect for addition like this and instead its possible to use
SRV records (like in IIM or the way I've done authorization in META
Signatures) i.e. if you have
  DKIM-Signature: d=example.net s=s1 ...
  X-SPF-Origin: mymailserv.example.org'
then you'd need this
  _dkim_auth.mymailserv.example.org IN SRV 0 0 0 s1._domainkey.example.net.
Or Its also possible to put this instead in the SPF record with special
modifier, i.e. "v=spf1 ... dkim_auth=*._domainkey.example.net".

Another option is to say that location of the signature key must also
be authorized by means of the SPF record. That would mean that if s1.example.net is a location of the selector then its address would
have to be verifiable using SPF record you find based on MAIL FROM
(just like mymailserv.example.org would have to be verifiable). This
is less secure but it does not require extra modifier or extra record syntax. However the problem here is that selectors typically would
not have an associated ip address and current SPF syntax is also such
that expressing "*._demainkey.example.net" is difficult (maybe something for v2.5 discussion) instead however you could say that
dns server itself would have to be within netblock authorized
by SPF (which makes it even less secure).

Anyway, hopefully you get some idea why this (or any other type
of mix with different identity and authorization systems) is not easy and requires careful design and security review.

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

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com