spf-discuss
[Top] [All Lists]

RE: Security Paper on forgery bounce DDoS

2004-04-19 11:34:18
From: Tony Finch
Sent: Monday, April 19, 2004 4:50 AM


On Sat, 17 Apr 2004, Seth Goodman wrote:

I put forward the proposition that SES does everything that
SPF+SRS does,
delivers more confidence in the end result and causes less
breakage.  Here are some arguments to support this position.

3) SES allows the final recipient to directly query the domain MX for
verification and have high confidence in the result.

Note that callout verification works across firewalls etc., if it is
routed in the same way that a normal message would. E.g. an MUA would do a
callout via its smart host, which would in turn callout to the MX in
order to check the envelope presented by the MUA.

Agreed, but you get more benefits if the MTA does the checks during the SMTP
session and rejects messages with forged return-paths before DATA.



7) SES does not break forwarding, which makes it very easy to phase in.

SES does not break forwarding on the outgoing path of a message, but it
does place restrictions on forwarding bounces -- a signed envelope sender
address must refer directly to a mailbox on a final delivery system. (If
the bounce is forwarded it will end up with unsigned recipient address
which is not valid for bounces.)

This was brought up by Neil Brown and discussed a good bit.  SPF has a
similar problem if a forwarder does not implement SRS (or SPF).  What
emerged from kicking around the ideas that Neil brought up was a system that
uses a static signed address that the forwarding account sends received mail
(and bounces) back to.  This amounts to a secure back door into your MTA
with pretty good assurance that the messages all came through your
forwarding account.  If the forwarder did not do SPF or SES tests upon
receiving messages, there is no easy way to do forgery detection later.
That's just the way SPF and SES work.  It amounts to a semi-automated way to
do whitelisting, with some additional identity confirmation for the
whitelisted addresses.  It would work equally well with SPF as a workaround
for non-SPF compliant forwarders.



11) SES is easily extended to verifying addresses in the 822 header. If
a standard SES address format is used such that an MUA can turn an SES
address into an unsigned recipient address, you can do something like

      From: Tony Finch <dot(_at_)dotat(_dot_)at>
      Verify-From: 
<SES0(_dot_)SVoTm6oIlgKDmBlRbOmA(_dot_)dot(_at_)dotat(_dot_)at>

The MUA knows the addresses correspond, and can verify the SES form using
a callout. This is trivially extensible to multiple From: addresses,
Sender:  addresses, and Resent- addresses, etc.

That's exactly right, and the verification mechanism doesn't have to be CBV.
Asymmetric crypto seems pretty appropriate here, with public keys provided
in the DNS as an alternative to CBV's.  Solutions of the latter type is
exactly what was originally discussed on Sender-Auth, though the discussions
have been off-list since then.  If you're interested in securing the other
parts of the RFC2822 header, try
http://lists.infradead.org/mailman/listinfo/sender-auth

--

Seth Goodman