spf-discuss
[Top] [All Lists]

RE: HELO vs. envelope checks

2004-05-18 08:04:43
From: Greg Connor
Sent: Tuesday, May 18, 2004 12:22 AM


[Regarding SES in combination with localpart macros, exists:%{l}....]


Thanks for the detailed response.  I have some further questions about how
to do this using DNS instead of CBV's.


<...>

Putting all timestamped sending addresses into the DNS for a domain is a
really interesting idea.  However, you're talking about adding and
expiring _lots_ of addresses every day into a domain's DNS.  Not being a
DNS guru, I don't know about the implications of this, but it does sound
complicated. I'm willing to be educated on the matter.


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.

SES can be implemented in a couple of ways, but basically it boils down to
whether or not you need protection against replay attacks and how much
reduction in local part length you are willing to put up with.  In my post

Subject: RE: [srs-discuss] CBV
Date: Mon, 17 May 2004 12:11:46 -0500
Message-ID: 
<MHEGIFHMACFNNIMMBACAMEGMHOAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>

I gave several possible implementations.  For those who don't care to go
through all that, here's a summary.

For accounts that don't need protection against replay attacks, which
comprise the great majority of accounts today, the SES signature for a given
account only changes daily.  This means that if it were in the DNS, either
the new signature would have to be added to the zone file each day (and the
expired signatures removed) or the DNS server would need access to the list
of legitimate local addresses at each domain and the key for creating the
HMAC in the SES address.  The latter would be the ultimate in efficiency but
involves a security risk.

For accounts that do need protection against replay attacks (a small
minority of accounts), there were three basic approaches proposed.  The
first two approaches makes the SES signatures unique per message by
extending the timestamp resolution to both act as a message ID and salt the
HMAC calculation.  The 'lite' version of this approach involves the user
noticing that a joe-job is taking place and manually invalidating that
timestamp.

The 'full' version of this approach is more involved and was pretty specific
to CBV's and RFC2821 (the original idea was Stuart Gathman's).  It basically
ties the use of a particular MAIL FROM: signed return-path to a specific
list of RCPT TO: addresses to prevent replays.  To accomplish this, the
sending MTA keeps track of each outgoing timestamp+local-part(_at_)domain
combination and stores with it the list of original RCPT TO: addresses.  The
recipient does a CBV, and if the result is a 250, they then issue an EXPN
command for the timestamped local address.  The MX answering the CBV then
looks up the original recipient list and gives it to the recipient as a
normal RFC2821 EXPN result.  The recipient can then compare the RCPT TO:
list for the current message, taking into account the list of forwarders
that the recipients have set up and whitelisted that may substitute for the
original recipient addresses, to make sure that the MAIL FROM: has not been
used to send a message to a different group of recipients.  If the test
fails, the message can still be rejected before DATA, making this fairly
discouraging to spammers.

The third proposed method for protecting accounts subject to replay attacks
involved putting a body MAC in the MAIL FROM:.  The body check can only be
done at the end of DATA, so it begins to look like a PK solution but without
the PKI.  This also generates unique MAIL FROM: addresses for each outgoing
message, but is subject to mailing lists adding junk to the message body.
Since this ultimately needs to be fixed for any PKI system to work properly,
it may or may not be a show-stopper.  Today it certainly is.

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.  While this would be optimal, I
have no idea how much effort that involves.  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)?  If SRS was used, we would have to do SES CBV's on
all messages that are SRS rewritten plus messages that are not SRS rewritten
and don't pass SPF.  In other words, the first hop can trust SPF but beyond
that, you need something else.  The CBV does put some burden on the
recipient, but it averages out to significantly less than one CBV per
received message (the ones that don't have a forwarder just use SPF).  The
sender always has a larger burden, and their average will be several CBV's
per outgoing message.  At least that gets the proportions right.  Might that
not be an acceptable load for each end?

The other issue is that if special DNS servers were built that could
validate SES addresses, doesn't that imply that the DNS servers know the
hash secrets for each account?  Is the DNS system secure enough for that
information?


<...>

Right!  I think we are on the same wavelength (or at least a
similar one :)

I still believe that SRS is the right way to go for most bulk forwarders.
Some senders could still screw with forwarders by writing -all
anyway.  The
nice thing about SES is that the verification methods that work
on SES also
work on SRS the same way.  So, my thought is that early adopters
might like
SES as an alternative to ?all or -all, and to control bounces
received from
non-SPF sites, but that eventually the forwarders need to take
responsibility for their own return paths anyway.

If SRS is used, for the recipient to have confidence in the return path
claimed by the message originator, they still need to do a CBV (or the DNS
equivalent) even if the forwarder passes the SPF check.  Because of this, I
don't see what SRS adds to the verification picture.  Maybe you could clue
me in as to what I'm missing.

--

Seth Goodman