Re: sender vs author, channel vs object, designated sender vs crypto sig

Meng Weng Wong wrote:
> On Thu, Mar 18, 2004 at 09:38:49AM -0800, Dave Crocker wrote:
> | MWW> 1) I believe that it is important to protect the RFC2821 MAIL FROM from
> | MWW>    illegitimate spoofing, independent of the RFC2822 header From:.
> | 
> | That phrasing sounds like an assertion that we can have productive
> | discussion about.
>
> Thanks for your comments Dave, I'm glad we can agree on this.
Sounds good to me also.

> | MWW> 3) I believe that it is also important to protect the RFC2822 header 
> From:
> | MWW>    from illegitimate spoofing, independent of the RFC2821 MAIL FROM.
> | 
> | Hard to argue with that view.  (Although, of course, a community like
> | this can argue about anything...)
While it may be independent, it may also be done via the same mechanism 
for both (which is what Phil is arguing).
> (For people who were not at the BOF, widespread outbreaks of agreement
> like this are now called the Dave Crocker Lovefest Effect. :)
Good to know :)

> I wanted to focus on these two items because they are facts that exist
> in the field; we can have endless debates about different identity roles
> but the fact is there is RFC2821 MAIL FROM and there are RFC2822 From:
> and Sender: and Resent-From and Resent-Sender so let's see what we can
> do with that.  The former is read more by machines than users; the
> second is read more by users than machines.
>
> http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt
> section 2.1 identiifies four types of forgeries.  I associate
> phishing-spam with 2822 forgery, designed to fool humans.  I associate
> joe-jobs with 2821 forgery, designed to fool machines.
I am not so sure about joe-jobs. Joe-jobs that are meant to generate 
lots of bounces are done with MAIL FROM, but joe jobs that promote child 
pornography with someone's domain or are designed to annoy a domain 
owner with angry letters, can be done via either one since they are 
intended for human consumption.
> (I believe MTAs whitelist on the basis of 2821 FROM, MUAs whitelist on
> the basis of 2822 From:.)
>
> | MWW> 2) I believe that the most appropriate way to do so is with a designated
> | MWW>    sender scheme.
> | 
> | When the working group starts debating particular schemes for achieving
> | the desired authentication (and maybe authorization) we can pursue of
> | this scheme, and others, further.
>
> Does anybody not agree that designated sender is the best way to combat
> RFC2821 MAIL FROM forgery?  Show of hands please ...
I am not sure if it is the best way to do it, but it is one way to do it.

> Does anybody not agree that crypto is the best way to combat RFC2822
> header From: forgery?
While designated sender schemes can be used for fight header forgery 
(like CID does), they might be breaking too many things. The question we 
should be asking is whether we should be verifying the "from" header, 
not whether proposal X is better. We need to establish that this 
proposal might not the be the best one suited for this, but while others 
are available we don't have to pick a specific one.
So while I have doubts about whether "from" header forgery is something 
we should be applying this scheme to, I do not agree that crypto is the 
best option. But it is irrelevant whether crypto is the right option, 
since that's not what we are deciding here.
> By "best" I mean "best combination of timely, deployable, implementable,
> gaming-proof, long-term effective, deterministic, and politically
> palatable".
>
> If we have rough consensus on the above two points, then I propose that
> we proceed to the question of whether designated sender can be
> appropriate for attacking RFC2822 forgery in certain circumstances.
The main problem with RFC2822 forgery and MARID schemes is that too many 
things tend to break. We can try to figure out whether specific use 
cases can be done without breakage, but I don't know if in real life 
people will bother. They just might verify "from" headers in every case.
Also, while Phil does make a compelling argument of killing two birds 
with one stone, there are alternatives. If we want to use this scheme 
for "from" header checking, then MUAs have to be modified. If we verify 
the RFC2821 from instead which is the return path, than MUAs can be 
modified to display it to the user since it is verified. Either way 
modifications in MUAs can help.
Yakov