From: wayne
Sent: Tuesday, October 26, 2004 3:29 PM
In <MHEGIFHMACFNNIMMBACAGEJBINAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>
"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:
This protocol has been worked on for a number of months on a
separate list subsequent to discussing it here early in the year.
I thought the mailing list that you were discussing this on was
sender-auth(_at_)lists(_dot_)infradead(_dot_)org, but either that list is
dead, or I
was bounced off it. Which mailing list is the SES discussion on?
Sorry if we did not announce this properly, or if we buried in a
inappropriate thread. Anyone can join the SES mailing list by sending an
empty email to mailto:ses-devel-subscribe(_at_)codeshare(_dot_)ca There are
archives
available, though I have to apologize in advance for the interface to read
them.
Signature verification by a DNS server is sufficiently lightweight
that it is little more than a normal DNS query, several of which
occur for every message received in any case.
Both SPF and DK are DNS cache-friendly (or about as friendly as they
can be). All messages coming from the same source within the DNS TTL
of the SPF or DK record require no new DNS lookups. (Now, for some
reasons, companies like google and AOL both have 5 minute TTLs.
*Yech*)
So, I'm doubt your claim that several DNS lookups are required per
message. Especially for larger MTAs that use local copies of DNSBLs
and such.
It is certainly true that the DNS load of SES is higher than DK. This is
especially true, as you mention, since there will be many DNS cache hits for
A, PTR and TXT (DK public key) queries and virtually none, except in the
case of replay attack, for SES signature validation. So it is incorrect for
me to imply that there would be several external lookups per message,
particularly in large MTA arrays. However, I still maintain that the
overall transaction cost of SES, meaning total CPU + bandwidth for sender +
recipient is lower for SES than DK. I am quite willing to examine this in
detail to satisfy your legitimate question or prove my contention wrong.
Another aspect to consider is abuse potential. Though a joe-job of a domain
that uses SES will result in a lot of queries in a short time period to the
nameserver that is responsible for signature validation, the responses are
inexpensive and my understanding is that DNS servers are equipped to handle
this type of traffic. Depending on the nature of the joe-job (i.e. replay
of a harvested signature), DNS caching will help. As a DDoS exploit, SES is
rather weak compared to other exploits of DNS, as I understand them. SES
did not create the weaknesses in DNS and does not materially exacerbate
them. OTOH, DomainKeys has a significant multiplier effect as a direct DDoS
on the recipient's MTA. It takes virtually no CPU or bandwidth to create a
message whose RSA signature of the SHA-1 message body hash does not
validate. If the sender uses a long RSA key, even with a short message body
it can take in the neighborhood of 8msec for the recipient to invalidate the
signature alone. When fed to a large zombie array that is not yet
blacklisted, a barrage of short messages to validate could conceivably
utilize much of the combined CPU of a large MTA cluster.
The major problem I see with your specialized NS server is that in
order for the forwarder problem to be solved every sender must run
one. Also, unless you either integrate the specialized code into a
standard NS or having your specialized NS act as a proxy, you need a
separate IP address for the server.
It is true that in order to utilize SES, a domain must run a specialized
nameserver. An alternate is a specialized UDP validation server, though the
code for this is not yet tested. However, several people have successfully
implemented specialized nameservers. Since it is a distinct subdomain, it
is easy to delegate to a server that is integrated with the MTA array or is
attached to the domain nameservers. Tony Finch has dubbed these "stunt" DNS
servers, though they need not be completely separate. Roger Moser has
modified BIND to do his SES address validation. Stuart Gathman has
implemented a specialized server in Python. Rather than go further in an
area in which I am not expert and I know that you have considerable
experience, I would refer you to these folks and ask them to answer with
their experiences running these servers for the last several months. Feel
free to bring this discussion to the SES forum or continue it here, as you
feel appropriate.
I like your idea of a SES NS server and SPF records, and it certainly
can work well for many situations. Sadly, I don't think it is a
cure-all. :-<
I'm glad you like the idea, but I'm more interested in your criticism. What
aspect of mail authentication does the combination of SPF and SES not handle
properly? As an aside, SES is usable as an end-to-end protocol in the
absence of SPF, exactly like DK, should anyone have the desire to do so.
The interesting thing about that architectural possibility, even though SPF
has wide support today, is that it does not require domain owners to publish
any policy records. If the specialized nameserver were to be part of the
distribution for a particular MTA patch, implementation could be somewhat
easier.
recipient looks up the SPF record for "domain" and finds an SES
modifier in the record, such as:
v=spf1 a mx ses=exists:{%l}._ses.{%o} -all
This modifier is evaluated like a mechanism for those parsers that
understand it, with a possible caveat.
Why use a modifier instead of just the exists: mechanism?
I typed this out too quickly and didn't tell the whole story, plus I didn't
even get the syntax quite right. The exists mechanism works fine by itself,
and that is what the implementations running today use. No one knows what
an "ses" modifier is and would ignore it. We planned on a future "ses"
modifier that would cause special behavior to minimize overhead and unneeded
queries as an optimization. The special behavior caused by the "ses"
modifier would be as follows:
1) Only do an SES query if no mechanism results in PASS.
2) Only do an SES query if the return-path appears to be an SES signature.
3) If there is an "ses" modifier and the return-path does not appear to be
an SES signature, the SPF result is FAIL.
We get exactly the same result in every case by using the exists: mechanism,
there are just more queries done than necessary. The syntax I showed was
not correct for the proposed "ses" modifier. To have it work both with
SES-aware SPF parsers and SPF classic parsers, we would use it as a
positional modifier along the lines of:
v=spf1 a mx ses=dns exists:{%l}._ses.{%o} -all
SPF classic parsers would ignore the unknown modifier and always evaluate
the exists: mechanism. SES-aware SPF parsers would utilize the above rules
for the exists: mechanism immediately following.
--
Seth Goodman