[mail-vet-discuss] draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04

[Scott Kitterman]

On Monday 10 November 2008 03:24, Douglas Otis wrote:
> On Nov 7, 2008, at 5:25 PM, Scott Kitterman wrote:
> > On Fri, 7 Nov 2008 16:09:22 -0800 Douglas Otis <dotis at mail-
> > abuse.org> wrote:
> > ....
> > I think it's worth pointing out when considering how much to worry
> > about Doug's latest "SPF will melt the Internet" theory that shared
> > MTA concerns are directly addressed in the RFC 4408 security
> > considerations.  This is nothing new that wasn't carefully
> > considered during the protocol design.
>
> Scott,
>
> Thanks you for the opportunity to respond to this mistaken view.
>
... snipped repeat of accusations Doug's been repeating for years.

For those of you who haven't been involved in the previous rounds of this 
discussion, the SPF project did take Doug's concerns seriously enough to 
expend time on a detailed review of his analysis and conclusions.  Rather 
that rehash all that, I'll just point people here:

http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

Doug: I know you disagree with that conclusion, but I'm not going to argue it 
again.

> > I think it's reasonable to assume that implementers pay attention to
> > RFC security considerations.  I think there are plenty of protocols
> > that would have security holes if their security considerations were
> > ignored.
>
> Unfortunately,  adopting security considerations in RFC 4408 is not
> enough.  Also, SPF combines both IPv4 and IPv6 into a common data-
> set.  As network address diversity grows, so will the size and number
> of SPF related transactions.

Yes.  As the internet gets bigger, more stuff happens.  This is not a suprise 
to anyone and rather tangential to the discussion.

> > If a DKIM signing shared MTA were to sign a message sent by somone
> > not authorized to use the domain, the exact some situation arises.
>
> Unlike SPF that requires separate IP addresses to isolate each
> customer's traffic, DKIM offers an unlimited number of domain names
> per MTA without the need to impose any header field restrictions.
> Seldom will a single MTA be assigned more than 8 IP addresses, and yet
> many MTAs handle thousands of different domains.

Actually it doesn't require a separate IP.  I think your sense of actual 
operational options to ensure users don't forge each other is somewhat 
limited if that's the only approach you can envision.

> It is nonsense to suggest that SPF or Sender-ID authenticates a PRA or
> MailFrom domain.  It is normal for many domains to share the IP
> address of an MTA.  There is no way to discern which instance of an
> published SPF record represents a unique IP address, or one that
> adequately protects or adequately modifies the PRA.  Few really do, so
> assessments should not be based upon the Sender-ID or SPF authorized
> domain, but instead should be based upon the MTA IP address or on a
> non-authorized MTA.

I understand that's your view and based on past experience it's clear you 
aren't open to changing your mind, so I'll just leave it as I disagree.  Your 
assumption here is that security considerations are ignored and for purposes 
of standards work, I don't think that's appropriate.

> A cynic may view the absence of the IP address from the
> "authentication-results" header for Sender-ID or SPF as an effort to
> shift blame toward hapless domain owners, and away from email
> providers.  Not including the IP address discourages recipients or
> filters from checking with their trusted public IP address reputation
> service at least.  Most of the abuse seen today is introduced through
> compromised systems.  For Sender-ID or SPF, compromised systems are
> best tracked by the MTA IP address.

That's just a way of saying 'don't use SPF'.  You've been claiming that SPF 
will make the internet melt for years now and I just don't agree with it one 
bit.

The IP address is generally already enshrined in the Received header field, so 
I don't see the point in redundant information.  How to grovel through the 
various Received fields in a reasonably reliable is fairly well advanced.

Scott K