Bootstrapping trust model (was Re: a "never relays" parameter)

--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
> > Actually I think I see where Seth is going here.  The ses:
> > implies that we
> > are checking the MAIL FROM: of the original hop, not the rewritten MAIL
> > FROM.
> Yes, that's exactly what I'm saying.

Cool, it sounds like we are thinking along the same lines.


> > I think this means checking the SES at every step, even if MAIL FROM is
> > rewritten to another forwarding domain.  (or, stating that in
> > terms of the
> > Layers post I just wrote, if you are able to validate Layer 2,
> > that trumps
> > Layer 1, and the mail is considered Verified Direct.)
> Exactly!  SPF is a hop-by-hop validation (layer 1).  If you can validate
> the original source of a forwarded (end-to-end validation, layer 2), the
> hop-by-hop validation (layer 1) is redundant.  If forwarders do SPF checks
> on incoming, we can trust that anything they hand us has been validated at
> the source, so long as we validate their identity with SPF.  In other
> words, if a forwarder is on a local list of trusted forwarders (they
> perform SPF test on incoming), validating the forwarder's identity (layer
> 1) indirectly accomplishes originator validation (layer 2).  This is a
> very useful shortcut.

Right.  That's what I was thinking when I posted the Layer concept but I 
hadn't got around to writing the follow-up, which says basically that.
This kind of "bootstrapping" is important.  If you are getting mail 
forwarded to you, you are going to miss pretty much all the benefits of a 
straight IP-based check, because the thing you are checking (either PRA or 
SRS) will always be your forwarder.
This is even more reason why the forwarder should appear on a personal 
whitelist.  Once you check the box that says "Trust this sender as a 
forwarder" then you can believe whatever previous thing they validated. 
They are working on your behalf, after all.
One step further... let's say the message has clearly been forwarded, but 
the forwarder doesn't check SPF.  You could probably apply SPF-Like checks 
to the data that came before it, by pulling data out of the now-trusted 
Received: lines.

> However, a forger can pose as a forwarder very easily.  If a forwarder is
> _not_ on the local list of trusted forwarders, or if there is _no_ local
> list of trusted forwarders, we can't tell if he is:
>
> i)   a legitimate forwarder who does SPF on incoming,
> ii)  a legitimate forwarder who does not do SPF on incoming or
> iii) a forger.
>
> For cases ii) and iii), we need to validate the originator address if we
> want to avoid forgery.  However, unless the forwarder is on the local list
> of trusted forwarders, we can't distinguish i) from ii) and iii), so we
> have to originator checks whenever the forwarder is not on the local list
> of trusted forwarders, _if_ we really want to avoid forgeries.

I agree, and I think that people will probably be aware of their forwarding 
addresses enough to list them, so usually it won't be a problem.
One of my axioms is: You are either an agent for the sender, or an agent 
for the receiver.  If you aren't either, you have no business handling the 
mail.
If a sender uses submitter, not a big deal, as long as it matches PRA and 
matches their IP.  But since they are not MY forwarder, I won't take their 
word on who it's *really* from.  I will probably accept the message, but 
will mark it as "really from the PRA/submitter" and I would mark the From: 
and Sender: as "Unverified"
And as you say, if the From: or Sender: checks out with the IP, never mind 
the Submitter, though it's likely to be the same.  If the sender uses some 
kind of forwarding arrangement, they should list that in their SPF record. 
"Sender-side forwarding" is just a subset of "sending" to me :)
Mailing lists are an interesting problem, since they are usually agents for 
the sender AND agents for the receiver.  Mostly the mail you get from the 
mailing list will just be identified as "From X List"... but if you take 
the time to add the list robot to your trusted forwarders list, you could 
take the chain of trust back one level there as well (either by groveling 
*their* received line, or taking whatever result they already validated in 
Received-SPF).

> > but SES will
> > always match successfully, since it is not based on IP of the
> > current MTA.
> > Usually you would not want to reject based on the SPF of the From: but in
> > this case the domain owner is trying to tell you "Go ahead and
> > reject based
> > on this"
> The only problem is that unless we _always_ query the SPF record for the
> originating domain, we have no way of knowing that the domain owner said
> that.  We could require that, but it is an extra DNS query at every hop
> (not really that bad).  If we did that query _before_ the query for the
> current sender, and the result was pass, we could skip the query for the
> current sender.  Another alternative is to say that a forwarder on the
> local list of trusted forwarders has already validated the originator
> address, so we don't have to.  The only fly in the ointment here is that
> we have to be sure that the forwarder also uses this same methodology
> when they encounter a forward on incoming.  Unless our forwarder also
> checks originating addresses on incoming forwards where the incoming
> forwarder is not whitelisted, the shortcut scheme falls apart.  We could
> easily test our forwarders with some contrived forgeries, including
> forged forwards, to make sure that they reject them before whitelisting
> them.
>
> Considering how easy it is to get the above forwarder audit wrong, it
> might be sensible to _require_ first trying to do originator validation.
> What do people think?

I would probably want to do one of:
* Always check both layer 1 and layer 2 identity
* Check the forwarder (trust and IP) and then trust what they say

I probably would not stop with only the layer 2 From:/Sender: check, but I 
haven't had time to think about that much, perhaps I will change my mind.
If there are more than 1 forwarders involved, all of them should be on your 
trusted list (for example, alumni and pobox, or mailing list and 
forwarder).  Something acting like a forwarder (ie. PRA is Resent-From and 
!= From: or Sender:) but isn't on your trusted list can be flagged as a 
suspicious thing but I probably wouldn't reject it - it could just be 
because the From: is sf.net and PRA is sourceforge.net.  Just mark it as 
"really from" the entity giving the Pass result, by your check or by a 
trusted third party.
In other words, there are probably some cases where there are more than 1 
forwarder, but if they are all trusted and all verified, no problem... 
bootstrapping is still possible.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>