spf-discuss
[Top] [All Lists]

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

2006-08-12 11:11:36
On Saturday 12 August 2006 13:46, william(at)elan.net wrote:
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.

Of course.

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.


I think that SPF can benefit from DKIM in the non-SRS forwarding case.  For 
normal forwarding 2821.Mail From == 2822.From in all cases I'm familiar with.  
I think it's only in the case where the values of the two entities are the 
same that mixing the layers can be done safely.  As it happens, that's where 
SPF could use some help.

I think the signing domain must also pass a 2822.From SSP check here too.  In 
this case I think one could count as SSP validated mail signed by the same 
domain or mail signed by a domain listed as an authorized signing domain (if 
the ability to provide a list survives the current debate)

I'm not sure that's exactly right, but I think if carefully specified this can 
be done safely.

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.

Agreed.

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.

Absolutely.

Scott K

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

<Prev in Thread] Current Thread [Next in Thread>