From: Carl Hutzler
Sent: Tuesday, October 26, 2004 11:12 AM
SRS is not a requirement. Solving the forwarding problem is. There are
better ways to do this than SRS that require nothing to change at
forwarders.
Well if there is a better way than SRS or PRA which does NOT require
forwarders to change, then we should be looking at it really hard
and really quickly.
<...>
So how can SPF/SenderID fix the forwarding issues without
forwarders needing to change?
It's an answer we've discussed in the past and have more recently improved
to answer various objections/perceived problems. The protocol is called
Signed Envelope Sender (SES) and was the predecessor of BATV. The most
recent version of it has similar authentication properties to DomainKeys but
is lighter weight. It also has a validation step before data, which allows
the possibility of rejecting trivial forgeries early. This protocol has
been worked on for a number of months on a separate list subsequent to
discussing it here early in the year. Here is a brief overview.
The sender creates a SHA-1 message digest of the originating headers plus
the message body using one of two canonicalization algorithms, just as in
DomainKeys. Instead of using a public key signature, the digest is signed
by an HMAC-SHA1 and both the HMAC signature and the digest are placed in the
local-part of the return-path. In order for them not to take up too much
local-part space, both the digest and HMAC signature are truncated. We can
show that the strength of the cryptography is more than adequate for even
the largest sites under extremely conservative assumptions with reasonable
length local-part strings. Since the signature is based on a one-way hash
function, the sender must verify the signature in stead of the recipient,
typically via a DNS request. There are several key differences between SES
and DomainKeys that make it more suitable as an adjunct protocol for SPF.
1) The HMAC-SHA1 signature is far lower overhead than either RSA signature
creation or verification, even with short RSA keys. 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. Thus, the total transaction cost, sender+recipient, is far lower for
SES than DK, particularly for short messages (like spam) and particularly
for the sender.
2) The DNS query for signature validation is only required when SPF-mailfrom
does not result in a PASS due to the other mechanisms in the SPF record.
That is, the DNS signature validation query is only performed on messages
that have been forwarded. It adds zero overhead to recipients of single-hop
(nor forwarding) message transfers. DomainKeys adds overhead to every
message received.
3) Even on forwarded messages where a DNS signature validation is necessary,
the load on the recipient if extremely light. The only steps are requesting
validation of the return-path via DNS, and then only if it passes does the
recipient compute the SHA1 hash of the message body to compare to the digest
in the return-path.
4) If the DNS signature validation returns FAIL or NXDOMAIN, the recipient
can reject the message before data.
A typical signed return-path might look like:
MAIL FROM:<S=XXXXXXXX(_dot_)DDDDDDDD=local-part(_at_)domain>
where
XXXXXXXX = [ HHHHHHH ts ]
HHHHHHH = base-38 encoded n-bits of HMAC-SHA1 of
"ts(_dot_)DDDDDDDD=local-part(_at_)domain"; the bits
may be any selection and ordering determined
by the sender
ts = timestamp consisting of the t least significant
bits of the number of days since epoch
DDDDDDDD = base-38 encoded m most significant bits of SHA-1
digest of the message body
Upon receiving this return-path at the beginning of the SMTP session, the
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. If any of the preceding mechanisms
result in PASS, the "ses" modifier need not be evaluated. In the case of a
single-hop message transfer, the "a" or "mx" mechanisms will produce a PASS.
Since you know you receiving the message from the originating gateway MTA,
you have just validated the return-path. In the case of a forward, the "a"
and "mx" mechanisms will both result in FAIL, so the "ses" modifier is
evaluated. For the example return-path, this generates a DNS request
similar to this:
MAIL FROM:<S=XXXXXXXX(_dot_)DDDDDDDD=local-part(_at_)domain>
dig S=XXXXXXXX.DDDDDDDD=local-part._ses.domain A
The subdomain "_ses.domain" is delegated to a DNS server that contains code
to validate the HMAC-SHA1 signature. The DNS server knows the secret key
used by the domain on the date encoded by "ts", and it uses that secret key
to calculate the HMAC-SHA1 of "ts(_dot_)DDDDDDDD=local-part(_at_)domain" and
compares
it to the "HHHHHHH" in the return-path. If they match, it returns 127.0.0.1
with a TTL that is the remaining useful life of the signature. If the they
don't match, it returns NXDOMAIN with a TTL that is the time until that date
code will next appear. The results are fully cacheable in the event of
replay attack. On a forwarded message, if the return-path validates via DNS
query and the SHA-1 message digest matches that in the return-path, the
recipient is assured that the return-path is valid and the return-path
domain is taking responsibility for the complete message, including the
originating 2822 identity. In contrast, DomainKeys does not make any
assertion about the return-path. It only protects the 2822 originating
identity.
There are a number of options and refinements not mentioned here. I would
be happy to discuss this proposal at any time, as would the other
individuals who co-developed the SES concept.
--
Seth Goodman