From: (and maybe Sender:) header authentication

[David Woodhouse]

On Tue, 2004-02-24 at 14:59 +0000, Brian Candler wrote:
> > I wouldn't recommend editing the From: address. I think RFC2821 says you
> > MUST NOT. It will suffice to add a warning header that a MUA can look
> > for if it wants, or which procmail can use to dump the message into a
> > spam box.
> 
> OK. End-point policy decision, anyway.
> 
> Perhaps in extreme cases, where the sender is known to be very likely to be
> forged, the receiving MTA can wrap the entire message inside a
> message/rfc822, with a disclaimer on the outside saying that the From:
> address is bad.

Or just drop/reject it. Policy again. We can leave a _lot_ to local
policy, although we should perhaps offer guidelines. What I'm really
interested in providing is the _mechanism_ whereby we can sign such
email to authenticate the address(es) in the From: (and/or Sender:)
header.


> > > "this mail came through me, and it's one of my domains, the RHS may be right
> > > but I can't vouch for the LHS of the address" (this is roughly what SPF
> > > attempts)
> > > 
> > > - a mail from "random at myisp.net", where the user authenticated with SMTP
> > > AUTH and with a username which matched that address, could be signed "this
> > > mail came through me and I vouch for the authenticity of the sender"
> > 
> > I _can_ see the point in making a distinction between the above two
> > cases, but I wonder if it's really _necessary_. Any proposal has to be
> > lightweight and we must avoid featuritis.
> 
> The first is easy to implement now, but doesn't actually validate the sender
> (much). The second is a much more desirable position of having a
> fully-validated sender, which ought to be a long-term goal.

Yeah, that's true. Perhaps, then, the pubkeys listed in the DNS should
be accompanied by a 'trust level'. We might define 'domain' and 'user'
as the only two trust levels, for now. 

It's up to the MUA how this is represented to the user -- you might want
to display the From: addresses in a different colour, for example:
	Red: Should have been signed but wasn't.
	Green: Signed with 'user' key.
	Blue: Signed with 'domain' key.
	Black: Unsigned, shouldn't have been.

> > > - a mail from "b.candler at pobox.com", where I authenticated with SMTP AUTH as
> > > brian at myisp.net" could be signed "this mail came through me from the user
> > > brian at myisp.net, but I cannot vouch for the sender address given"
> > 
> > According to RFC2822, in this case you should have brian at myisp.net in
> > the Sender: header, and b.candler at pobox.com in the From: header. 
> 
> Sure. Sender: headers can be forged too, of course. Effectively this would
> be a crypto equivalent of the Sender: header though.

Yeah. As the risk of suffering from featuritis, we could also allow for
signing according to the addresses in the Sender: header, as well as the
addresses in the From: header. You'd end up with a parallel set of
headers, allowing two or more signatures to coexists.

Come to think of it, you have to allow for that anyway since a mail can
have more than one From: address. Let's put the signing address (or just
the domain if appropriate) into the Content-Hash- headers too, and that
way multiple such headers can coexist.

> The ISP would have to be involved by publishing the end-user's public key in
> the DNS somehow, e.g. under  "b.candler._at.pobox.com."
> 
> (or else by signing the end-user's key, as mentioned before)

The former is simpler -- verifying key signatures can get expensive,
especially if there's a long chain of signatures to be verified due to
multiple delegations. I think I'd prefer that unless there's a real need
to handle such delegation.

> The ISP probably does not want to be responsible for holding the user's
> *private* key, in which case the end-user's MUA must be responsible for
> signing the message. Here we move away from an ISP-centric solution to an
> end-user-centric solution, which has defied widespread acceptance to date.

If the ISP is doing SMTP AUTH and actually checking the _user_, or is
verifying usernames against actual live dialup records, the ISP _can_
use a key which has 'user' trust level. In fact the ISP can have two
keys for the same domain -- one with each trust level -- and use
whichever is appropriate for each mail.

We need to allow _either_ ISP-centric or user-centric signing. 

> It's essentially an ISP making a negative assertion: I do *not* handle mail
> for whitehouse.gov.

The ISP has no reason to state such a thing. That's the assumption that
SPF makes, and it's _wrong_. The ISP in question _does_ validly handle
mail for whitehouse.gov, if <monica at whitehouse.gov> happens to dial up
today and try sending mail, or if she sends mail to a user at $ISP who
happens to have a .forward file.

> > The ISP vouches for the user by listing the appropriate pubkey in the
> > DNS for that user at isp-domain. Isn't that sufficient?
> 
> Yes it would be. This wasn't discussed until now.

Sorry, I certainly _thought_ it quite hard. I appreciate that method of
communication leaves a little to be desired though :)

> The problem is that either we support keys and signing for all the various
> existing mechanisms, or we just implement a new mechanism which can sit on
> top of all of them anyway. If we do that, we don't care that it's already
> been GPG-signed, say.

Yes. I think we need to implement a new mechanism. Something basically
like the one I documented at the bottom (after the ================) of
http://lists.infradead.org/pipermail/sender-auth/2004-February/000002.html


> So I guess you mean, remove the goal that signatures can be checked offline.

I think that's reasonable, yes. After all, you don't really want to do
the verification more than once at the time you receive the mail, do
you? And you're likely to be online when you _receive_ the mail.


-- 
dwmw2