From: Dennis Willson [mailto:taz(_at_)taz-mania(_dot_)com]
Sent: Friday, August 26, 2005 5:41 PM
How does the UDP call-back work? My mail hubs (which is where the
MX records point) don't know about any users. They only know they
can relay for domains specified in their configuration file so
they can't verify valid users. Also I didn't know that Sendmail
responded to UDP requests... My Firewall certainly doesn't allow it.
There are two methods. One is a custom UDP service that you currently don't
have and listens on a high-numbered port. You will have to open a hole in your
firewall for it. Because it does not run with root privileges, and it ignores
any packets that are not formatted specifically for this service, and it is UDP
with a single packet request and response, it is not a security issue. While
any open port is exploitable, this service does not leak any information other
than the sequence number of the incoming validation request and binary answer
to the question, "Did the return-path you submitted for validation come from
your domain within the expiration time window?".
The second method is considerably harder to build, though does not require
recipients to parse a modifier that is unknown to current SPF parsers. That
method uses DNS as a callback mechanism, but all validation requests for
domain.tld would be directed to _ses.domain.tld. You don't need a real DNS
server there, only a listening process on the DNS port that looks for an A
request for a return-path to _ses.domain.tld. The listening process then
rewrites the packet in the simpler custom UDP service format and passes it to
the appropriate port. You host the "nameserver" for _ses.domain.tld on
whatever machine that will do the validation.
We would have to do a Sendmail integration, just as SPF or DK does, to let
Sendmail use this. The custom UDP service (and DNS listener, if used), would
be a patch to install. You would obviously have to adjust the router and
firewall to pass this traffic. The Sendmail integration could probably be a
milter. I don't know how SPF was actually implemented on Sendmail, so I can't
say what is the best approach.
I receive eMail via a set of inbound only hubs and send eMail for
other servers. The servers that the users interact with and know
who is a valid user are different servers and don't interact
directly with the Internet (some send directly others send via the out
going hubs). Wouldn't the call-back break here if the inbound
hubs can't truly validate the users?
No it wouldn't. In general, validating the signatures does not require access
to the user list. The signatures are validated by doing an HMAC of the
return-path and a secret key. The granularity of the signatures is determined
by the owner of the sending MTA. The number of keys the validation process
needs access to depends on this granularity. The outbound MTA may use one
secret key for all domains, one key per domain, one key per user or any
combination of these methods. Selecting anything more granular than one secret
key per MTA only is worthwhile only if the MSA prevents cross-user forgery.
That is, if the MSA allows any authenticated user to claim any return-path
domain, signing with domain-specific keys is clearly useless (the same goes for
any signature scheme). If the MSA enforces that the return-path be from the
domain that the user authenticates with, but lets them use any local-part they
wish, signing with per-user keys is similarly a waste of time. In other words,
your submission policy should match your signing policy, and this is not unique
to SES.
You have three choices as to how to set this up with separate inbound and
outbound clusters.
1) run a validation server on both the inbound and outbound cluster
2) run a validation server on the outbound cluster, and have the inbound
cluster forward all validation requests to that server
3) run a validation server on a separate machine or cluster, i.e. your DNS
servers, and have the inbound cluster forward all validation requests to that
server
The outbound server always needs the ability to create signatures. While it is
possible to have a separate signing/validation server that both inbound and
outbound servers use, the signatures and validations are light weight enough
that the outbound servers should be able to handle it. Key distribution, is
not a major issue with this protocol, as it can be with some others. Future
keys are generated algorithmically from any key known to be valid at a
particular point in time, a fixed shared secret and the update schedule.
Distributing this information is an initial setup issue only and can occur via
any secure method. Cracking one key, which is not feasible anyway, does not
allow you to guess any future key because you also need the shared secret.
Cracking two consecutive keys does not allow you to crack the shared secret.
The only practical way to crack this system is to either compromise a machine
with the needed information or have an insider give it to you. As with any
centrally administered signature method, if either these happens, the signature
leak is the least of your problems.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
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