From: Greg Connor
Sent: Friday, May 21, 2004 7:14 PM
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
From: Greg Connor
Sent: Tuesday, May 18, 2004 12:22 AM
[Regarding SES in combination with localpart macros, exists:%{l}....]
I guess we now have to take account of the fact that SPF checks are only
done on MAIL FROM: at the first hop. At the second and subsequent hops, we
now use (RFROM -> FRED ->) DAVE parameter, the SPF check on (PRD ->) PRA
does not validate the return-path.
<...>
I didn't really take replay into account, but it is a good point.
Probably
either CBV or DNS exists: tag could be implemented in such a way
that flags
(or even denies) the same message being checked hundreds of times.
Replay attacks are only an issue for a narrow class of sender. Most mail
users are not in that class. For these majority users, let's say that their
SES signature was the same for an entire day of outgoing messages, since
their timestamps only have one day resolution. For that case, it does allow
caching of the outgoing SES signatures at the MX. In a DNS implementation,
it would limit the number of signatures that would have added to one per
user per day, which is roughly the same number that would have to be removed
due to expiration. If we did put the daily SES signatures into the DNS, we
would have to severely limit zone transfers to keep the information secret,
as pointed out by Tony Finch.
Would typical DNS installations be up to the task of maintaining concurrency
on multiple nameservers for data that changes this rapidly? For this
application, an outgoing MTA might send a new SES signature to the domain
nameserver and the first query for that data might occur within seconds.
This is not an issue with the CBV approach because the domain MX simply
calculates the hash if it is not cached. If the DNS server could be taught
to validate the hashes, the only information it would need would be the
user's hash secret. If this could be accomplished, it would be an
ultra-efficient solution.
For the case where replay attack is an issue, of the several methods to foil
these that we have so far, two of them seem most promising. Both methods
used an extended precision timestamp to act as a message ID, thus making the
hash value (most likely) different for each every outgoing message for a
given user.
The first method relied on the user to invalidate a given timestamp, but it
would be a huge improvement to automate it, as you suggested above. I will
incorporate this idea into the current SES description. This method does
allow a certain number of forgeries to get through, though the number is
configurable at the sender. An MX could handle this relatively easily
through CBV's by calculating the hash for each SES signature. The DNS
implementation would either need an entry for every outgoing message, or
know how to calculate the hash, just like the MX responding to a CBV.
The second method involved having the message source return a list of RCPT
TO:'s when presented with a valid SES signature. This method allows no
forgeries to get through, but involves keeping more information around for
each outgoing message. This is difficult for either a CBV or a DNS
implementation, since a per-message recipient list is required.
All three of these would be tricky in the DNS, but perhaps you can see
reasonable ways to do it. Could you give some overview of the
possibilities for DNS dilettantes such as myself?
From what you've implied, it sounds like doing SES through DNS would
involve constructing special purpose DNS servers.
Right, that is part of it... I don't think I was completely clear
on what I
was proposing.
I previously wrote:
Right, storing the SES return addresses used becomes a problem,
especially
with multiple servers sending. The key to making it feasible
would be a
DNS server that answers Yes for valid signatures and No for
invalid ones
without recording the whole history. But, if we can build a
rate-limiting
DNS server, we can probably build a signature-verifying server as well.
This probably should have read "When used in conjunction with an
spf record
that uses something like +exists:%{l}.localpart.%{d}". In that case, the
message results in a PASS only if the localpart is fed back to my own DNS
and gets an A record back.
Nice. But now we have the additional problem that there are two things to
validate on forwarded mail: the responsible sender (RFROM/FRED/DAVE) and
the return-path. On forwarded mail (there is a DAVE parameter), recipients
will always verify responsible sender via SPF, but we would need a second
check to validate the return-path.
I am willing to bet that implementing a DNS server that also knows how to
differentiate between good and bad localparts is not trivial... it's
probably more difficult than setting up the MX server to reject
bad SES and
accept good ones. Something like 127.0.0.1 would be returned for a good
left-hand-side and "nonexistent" for bad.
It sounds like the implementation would be something like a RHS-DNSBL.
The possible advantage over SES+CBV is that if the receiver checks SPF,
they do not need to add anything else. A receiver doesn't need
CBV as long
as the SPF record contains "exists" and uses %{l} to give the
left-hand-side of the return address back to the DNS server. Also, a DNS
server should be able to reply in one UDP packet which is slightly lower
overhead for the network, though this is a very small advantage if any.
With the DAVE parameter, we have to do a separate validation for the
return-path after a forwarding hop. This would still be most efficient as a
DNS query.
What I really like about the DNS exists: and SES is that the
costs are 100%
borne by the sender... as long as the receiver can do standard SPF, the
effect is similar to CBV without having to actually add CBV to the
receiving side.
I completely agree. I think that while a naive implementation would be
possible, i.e. dumping a daily load of fresh SES signatures, deleting the
expired ones and having the nameserver just check for existence of the
record, the SES-aware DNS server that knows each user's hash secret and
validates SES signatures would really be great. If we could do this, all
senders could go to the extended precision timestamp, which would give
everyone some measure of replay attack resistance. Having the nameserver
invalidate a particular timestamp+localpart after a certain number of
requests would make this automatic.
Having a DNS server that has to calculate hashes does introduce something
that DNS servers were not intended for, as far as I know. The extra CPU
load for SES requests could make it more feasible to DOS a nameserver. On
the other hand, as a hardware engineer, I know there are crypto accelerator
cards around that can help. I wouldn't mind designing a network appliance
or USB 2.0 box that validated SES hashes at very high speed. A PCI express
card that did this would be a way to accomplish the same thing for upcoming
server platforms. None of these would have to be expensive.
While this would be optimal, I
have no idea how much effort that involves.
I don't actually know the answer to that :)
Do you know any DNS gurus or can anyone else comment on this?
One question is how much
worse is it to do SES CBV's only on the messages that don't pass SPF
(assuming that SRS is not used)?
That is an excellent idea. I think even if you did have the magic DNS
server I am imagining, you would also skip those checks if the IP address
is known good. I'm thinking of something similar to
v=spf1 +a +mx +exists:%{l}.localpart.%{d} -all"
So if A or MX are matching, answer PASS, otherwise do the DNS check.
That's quite nice. The new convergence makes this somewhat messier. On the
first hop, there is no DAVE parameter, so the SPF test is done on MAIL FROM:
and your SPF record would do the job quite nicely. On forwarding hops, the
DAVE parameter is SPF checked and the 'exists' part is no longer
appropriate, at least with current SPF macros. To make this practical, we'd
need additional SPF macro terms to specify the parts of the MAIL FROM:
address instead of the DAVE address.
--
Seth Goodman