Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 01 Feb 2008 17:08:31 -0000

On Thu, 31 Jan 2008 22:00:18 -0000, Hector Santos <[email-masked]>  
wrote:

> Charles Lindsey wrote:
>
>> Agreed. If the Sender domain was already one of the From domains, there  
>> is no need to consider it further.
>>  But suppose that there were 4 From addresses, from domains which  
>> published no SSP. But for some reason the 4 authors had engaged someone  
>> from domain E to Send it for them. Suppose E publishes a strict SSP.  
>> Then they are going to sign it on the way out, and so it is a 1st party  
>> signature.
>
> Charles, unless I missed you points, don't you see the conflicts in this  
> scenario?  The lack of protocol consistency?
>
> I just have a hard them believing that an organization (DOMAIN E), small  
> or large, who is going to invest time, money and energy in implementing  
> DKIM/SSP and go through in what will mostly likely be an extensive  
> company review process and due diligence of their domain properties and  
> usage by employees, to decide they want use a DKIM=STRICT policy  
> accompanied with new company wide stated mandate for all employees and  
> then turn around and go against its own new company mandate to use the  
> domain in ways that a) are against the current SSP guidelines and b) are  
> 100% exploitable.
>
> I just don't get it.

All sorts of strange email practices exist which you might have a hard  
time believing until they suddenly happen, and even become popular :-( .

In this case, somebody employed by E agreed to send this message on behalf  
of the From authors (whether in compliance with E's internal policies, or  
not). Maybe the message contained some scurrilous material that the Sender  
did not care to sign himself, though he agreed that it ought to be  
published in the interests of free speech. At least by sending it through,  
and getting it signed by, E made it traceable; maybe the From authors were  
regularly spoofed, but had no way of getting their messages signed though  
their own providers (maybe they all had google or hotmail addresses, or  
alt.net addresses, or the other usual suspects).
>
> I am not suggesting that the scenario is not possible, but that in this  
> case, DOMAIN E will not volunteer or agree to do this on behalf of the  
> other four domains simply because it can't, not in this mode of  
> operation, without violating the SSP specifications and continue to  
> subject its domain to unprotected exploitation.

E is not being 'exploited' here. All it is afirmoing is exactly what is  
implied by its signature and the headers it covers.

Or, if you don't like that scenario, maybe it was a Resent-From header  
within E's domain, rather than a Sender (again, with or without the  
blessing of E's internal policies).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 1 Feb 2008 16:44:56 -0500

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Frank Ellermann
>Sent: Thursday, January 31, 2008 2:32 PM
>To: [email-masked]
>Subject: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting 
>byfirstAuthorbreaks email semantics
>
>MH Michael Hammer (5304) wrote:
>
>> By what mechanism do you know that the 4 authors (from addresses) 
>> engaged someone from domain E?
>
>By definition (in RFC 822).
>

By definition you don't know. You only know that someone CLAIMS that it
is on behalf of someone else. Please cite the relevant section that
SHOWS the authorization - it doesn't exist. There is a presumption of
goodwill in the RFC that doesn't necessarily exist in a world where 85%+
of email is abusive (reference:
http://www.maawg.org/about/MAAWG20072Q_Metrics_Report.pdf )

>> We currently have no way of knowing that across domains 
>other than the 
>> fact that the person from domain E claims it.
>
>Yes, but you only somebody you wish to hold responsible, and 
>if E signed it you have someone.  If nobody signed it, with 
>E's SSP saying "strict signer", you can reject it.
>
>It's a semantical matter, do you want to protect senders (as 
>the name SSP suggests) or authors (in conflict with e-mail practice).
>For the typical case one From, no Sender, there's no difference. 
>

Sometimes semantics actually matter. You have succinctly put the
question but instead of a binary (author/originator vs sender/injector),
let's phrase it slightly differently.....what are we trying to protect
from? And if all we are trying to protect is the sender, why would
receiving domains (or MUAs) have any incentive to use DKIM or SSP? The
more likely answer is that we are trying to protect receivers.....from
abuse.

How frequently do we see authors/originators abusing senders/injectors
(other than compromised accounts or compromised hosts)? The more likely
(and common real world) scenario is individuals using sender to abuse
from.

>> What about the cases where domain E has no reputation?
>
>Same problem as a PASS "From: A" (no B, C, D, E).
> 

Not quite the same problem. From claims that it comes from A. It is DKIM
signed by A and the signature has been verified. As a receiver I can
make a link between the message and the origination domain for the
purported author. I have no conflict to consider. 

I can come up with 3rd party domains all day long (ok, I better hurry
before ICANN moves on kiting/tasting) to sign arbitrary messages.
Without a reputation - and if this approach is used for abuse - then the
likely outcome is that reputation systems will consider a domain without
reputation as significantly more likely to be abusive.

>> There is nothing that states that sender is authorized by the 
>> purported authors unless it is case #2
>
>| originator  =   authentic                   ; authenticated addr
>|                 [ "Reply-To"   ":" 1#address] )
>|
>| authentic   =   "From"       ":"   mailbox  ; Single author
>|             / ( "Sender"     ":"   mailbox  ; Actual submittor
>|                 "From"       ":" 1#mailbox) ; Multiple authors
>|                                             ;  or not sender
>
>You could ask Dave what "authenticated addr" for <authentic> 
>was supposed to mean back in 1982 ;-)  The sender is the "submittor"
>of the mail - not necessarily to SMTP, the envelope sender can 
>be different in e.g. UUCP -> UUCP gateway SMTP -> SMTP scenarios.
>

Haven't seen a bang path in a long while <G>.

Without a method of authentication, authentic does not = authorized.
A claim of authentic/authenticated addr means nothing without a
recognized mechanism for authenticating. My personal hunch is that,
particularly given the examples used in the RFC, is that it was assumed
the person (From or Sender) was authenticated by logging into the
server. A kind of Mayberry RFD approach if you will.

The envelope sender is Mail From:. We are talking about RFC2822 Sender

Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 1 Feb 2008 15:17:30 -0800

On Feb 1, 2008, at 1:44 PM, MH Michael Hammer (5304) wrote:
> By definition you don't know. You only know that someone CLAIMS that  
> it is on behalf of someone else. Please cite the relevant section  
> that SHOWS the authorization - it doesn't exist. There is a  
> presumption of goodwill in the RFC that doesn't necessarily exist in  
> a world where 85%+ of email is abusive (reference:

The spam percentages are actually worse.  Metrics are limited to some  
extent by the detection rates.  Unfortunately, a growing percentage of  
spam is not detected by filters. : (

>>> We currently have no way of knowing that across domains other than  
>>> the fact that the person from domain E claims it.
>>
>> Yes, but you only somebody you wish to hold responsible, and if E  
>> signed it you have someone.  If nobody signed it, with E's SSP  
>> saying "strict signer", you can reject it.
>>
>> It's a semantical matter, do you want to protect senders (as the  
>> name SSP suggests) or authors (in conflict with e-mail practice).  
> question but instead of a binary (author/originator vs sender/ 
> injector), let's phrase it slightly differently.....what are we  
> trying to protect from? And if all we are trying to protect is the  
> sender, why would receiving domains (or MUAs) have any incentive to  
> use DKIM or SSP? The more likely answer is that we are trying to  
> protect receivers.....from abuse.
>
> How frequently do we see authors/originators abusing senders/ 
> injectors (other than compromised accounts or compromised hosts)?  
> The more likely (and common real world) scenario is individuals  
> using sender to abuse from.

DKIM can make an improvement by allowing the signer to clearly  
indicate which identity provided the message while also indicating all  
messages are signed.  This identity does not need to match with the  
entity found within the From header.  Any MUA highlighted information  
should exclude that not included within the signature's hash and not  
encompassed by the key g= and t= restrictions.

The next consideration might be whether unmodified MUAs can benefit  
from a compliance assertion.  The answer is yes, provided the identity  
protected by an ASP or SSP compliance assertions can be encompassed by  
the key used to sign the message.  SSP takes this too far, and ASP  
does not take this far enough.

IMHO ASP is less problematic.  ASP at least requires a signature by  
the domain asserting policy.  The time for MTA validation adoption  
will be longer than the distribution of intelligent MUAs able to make  
sane presentations of which DKIM identities are being assured.  : )

The SSP _requires_ identity information to be falsified or  
ambiguous.   It is ridiculous for domains to add two signatures, one  
to clarify an assured identity, and another to be SSP compliant. : (

> Not quite the same problem. From claims that it comes from A. It is  
> DKIM signed by A and the signature has been verified. As a receiver  
> I can make a link between the message and the origination domain for  
> the purported author. I have no conflict to consider.

Agreed.  For unmodified MUA protection, one might also wish to include  
the g= and t= parameter information contained within the key.

> I can come up with 3rd party domains all day long (ok, I better  
> hurry before ICANN moves on kiting/tasting) to sign arbitrary  
> messages. Without a reputation - and if this approach is used for  
> abuse - then the likely outcome is that reputation systems will  
> consider a domain without reputation as significantly more likely to  
> be abusive.

Agreed.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 Feb 2008 15:39:10 -0800

Doug,

> encompassed by the key g= and t= restrictions.
[etc.]

You make a number of points that might be valid issues, but I can't tell 
because they're all mixed together and all under the subject line of 
issue 1525.

Now that ssp-02 is out and doesn't say anything about "first Author", 
can we move this discussion to a more relevant subject?

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 2 Feb 2008 15:16:04 +0100

Michael Hammer wrote:

> There is a presumption of goodwill in the RFC that doesn't
> necessarily exist in a world where 85%+ of email is abusive

Yes.  I'd put mailing lists overwriting my Reply-To into the
"abusive" category, and maybe a sender forging Reply-To can
be up to something really bad.

SSP or ASP won't protect Reply-To domains, I hope nobody adds
an "RSP" to the mix... :-)  For the sender vs. author issue
I think (2)822(upd) suggest to pick their concept of sender,
not the alleged author(s) where they are different.

> let's phrase it slightly differently.....what are we trying
> to protect from? And if all we are trying to protect is the
> sender, why would receiving domains (or MUAs) have any 
> incentive to use DKIM or SSP? The more likely answer is that
> we are trying to protect receivers.....from abuse.

A spammer claiming to be "sender: me" explicitly or implicitly
with an 2822 "from: me" without "sender: spammer" (or similar)
certainly abuses my address and/or the domain in this address.

That's relevant for receivers bothering to check it.  On the
other hand "sender: me" with "author: you" (or similar) could
be a perfectly legit use of 2822 no matter what your ASP says.

It could be also "sender: whatever" with "author: paypal" in a
phishing attempt.  Receivers white listing "paypal DKIM PASS"
won't get a white listed "DKIM PASS" for this phish.

> The more likely (and common real world) scenario is 
> individuals using sender to abuse from.

True, but is that really relevant ?  Why would I put the bad
guy "sender: whatever", assuming that results in a DKIM PASS,
on my white list ? 

For MUAs showing "whatever on behalf of paypal" it is obvious
without DKIM, SSP, ASP, etc. that the sender was NOT paypal.

MUAs showing only the author(s) are IMO doomed.  And receivers
thinking that an 2822 From is always true don't have the money
to use email and the Intenet, they have already lost everything.

> messages.

[OT:  Good that ICANN will stop this criminal practice.  I hope
 ICANN also terminates their "accreditation" of NetSol a.s.a.p.]

>> ask Dave what "authenticated addr" for <authentic> was supposed
>> to mean back in 1982 ;-)  The sender is the "submittor" of the
>> mail - not necessarily to SMTP, the envelope sender can be 
>> different in e.g. UUCP -> UUCP gateway SMTP -> SMTP scenarios.
 
> Haven't seen a bang path in a long while <G>.

Let's say RFC 1123 got rid of it.  Other gateways not limited
to news2mail exist, I'm just not familiar with MMS, Mixer, etc.
(and I forgot the fine print of "fido/maus/z-net to rfc822" :-)

> The envelope sender is Mail From:. We are talking about RFC2822

Yes, I mentioned "not necessarily" just for the records.  For SPF
it's important that folks don't confuse PRA with envelope sender,
or claim that it's almost always the same, because they've never
seen any email scenarios where that's plain wrong.  

Ignoring legit corner cases will backfire, "issue 1525" is tough,
at least we're ready with the "first author" over-simplification.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 2 Feb 2008 16:10:42 +0100

> maybe a sender forging Reply-To can be up to
> something really bad.

Strike "maybe":
http://isc.sans.org/diary.php?storyid=3917