Re: Trust, and who knows what (was Re: SPF abused by spammers )

On Sun, 2004-09-19 at 12:05, Chris Haynes wrote:
> "Mark C. Langston" opined:
> > On Sun, Sep 19, 2004 at 10:57:22AM +0100, Chris Haynes wrote:
> > >  "Alan DeKok" replied:
> > > >
> > > >   It's not the MAIL FROM which is flawed, it's the ability of
> > > > the recipient to believe the senders trust in the shared MTA, as
> > > > anything other than a statement of faith made by the vendor.
> > >
> > > Ah! Now here we can agree. We may differ as to _whose_ trust is
> > > broken, but the crucial point is that a shared MTA is being
> > > trusted to have ensured that the sender is authorized to use the
> > > Mail-From. There is no indication in the SMTP protocol, or in the
> > > message headers, that this authorization is actually taking place.
> >
> > But with SPF, the trust you're being asked to place is not whether the
> > sender is authorized to use that MAIL FROM:; it's whether the entity
> > connecting to your MTA (the destination MTA, presumably) is one
> > associated with the MAIL FROM: RHS.  It's a somewhat subtle, but
> > important, distinction.
> 
> I beg to differ.
> 
> SPF can check the whole of the MAIL-FROM address, not just the RHS. 
> You can construct policies which use the macro function to insert the
> LHS into a further look-up - thus giving a policy which is
> user-specific, not just domain-specific.
> 
> A 'trusted' shared MTA must prevent cross-customer forgery to at least
> the level of granularity of the corresponding SPF policy.  So, to be
> _sure_ of providing the level of trust required in offering the
> message it must, I think, ensure that the whole Mail-From address
> LHS@RHS may be used by whatever entity is asking it to send the
> message.
> 
> My language "sender is authorized to use..." relates to the tests
> which a trusted MTA server needs to undertake internally to discharge
> the trust that is placed in it, not to the semantics of the SPF test
> itself.

There are a few security concerns using a script that can reference
labels for a third parties (victims) to resolve in sequence.  The
ability to direct lookups to one DNS server and then another will
identify the source port for some implementations.  This then makes a
birthday attack relatively simple.  Using this label construction
macro's ability to resolve valid users is also fraught with additional
security problems.  In addition with a need to create a replicate user
list for each IP address used by the outbound MTA, the NXT function will
allow this list to be discovered.

As was illustrated by the marid-mpr draft, multiple MTA domains can be
associated with a mailbox domain without requiring these dangerous
subsequent DNS lookup on different servers.  The TXT script approach may
already overwhelm the DNS resolver.  To include a function normally
performed by the source domain only seems to be in denial of the
problem.  The dangerous macro language allows TXT, A, AAAA, MX, and PTR
records to be queried using arbitrary labels.  This seems like a really
bad idea and one nearly impossible to defend, especially when the use is
to grant authorizations.

-Doug