Subject: [ietf-dkim] Alternative MAiling List Approach

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 Jul 2010 12:21:41 +0100

I promised to do this some while back, but only just got a round tuit.

Scenario:
     discardable.example publishes a 'discardable' ADSP
     MLM.example operates a mailing list that adds boilerplate that breaks  
signatures.
     [email-masked] sends mail to the mailing list with
         From: [email-masked]
     [email-masked] subscribes to the mailing list. He (or his  
boundary provider) observes the broken signature and 'discardable' ADSP  
and discards, perhaps noisily. So client does not see the message but,  
worse, MLM.example may see the noisy rejection and unsubscribe client from  
the list.

Various suggestions  to mitigate this problem have been mooted, but none  
of them works perfectly, mainly because they rely on certain behaviours by  
discardable.example, MLM.example and discardable.example, all of whom need  
to persuaded to observe whatever "Best Practice" is being proposed.

The REAL cause of the problem is that From: line. My proposal is that MLM  
should change the From: header in such a way that the mail appears to have  
come from MLM.example and not from discardable.example. Clearly, this  
removes the cause of the problem at a stroke (the mail will no longer be  
discarded), but obviously it raises several other issues instead.

Chiefly, list subscribers (such as [email-masked]) will not  
immediately see who the mail is from, and will not be able to reply  
directly to [email-masked]. There are several things that would  
need to be done to mitigate this:

1. Preserve in  an X-Old-From: [email-masked] (but mailing agents  
will tend not to display that header).

2. Add a Reply-To: [email-masked] (unless Joe had already  
supplied his own Reply-To:, or mailing list policy is to set Reply-To to  
point back to the list).

3. Preserve any <display-name> in the modified From: e.g.
        From "Joseph" <[email-masked]>

4. Somehow encode the original [email-masked] within the revised  
From: header, preferably in such a way that replies will still get back to  
Joe.

And it is #4 which is really going to solve the problem, though #1-3  
should still be applied as backup measures that will assist the confused  
recipient.

So how to encode the old address within the new? Here is my proposal:

        From: "Joseph" <[email-masked]>

Which is, of course, the old (discredited?) "percent hack". But here used  
in a safely controlled environment.

Firstly, a recipient seeing it should have no problem extracting the real  
address manually. But we can do better than that. All that is required is  
for MLM.example to honour the "percent hack". And if he is using sendmail  
or EXIM, this is just a matter of configuring it back on.

In reality, MLM should be a bit nore cautious, perhaps only implementing  
the percent hack for cases which are subscribers to his mailing list, or  
adresses to which he knows he has previously sent mofified From: headers.

And there are further things that MLM could and SHOULD do as a matter of  
good practice:

1. Only modify the From: in cases where the incoming mail was DKIM-signed.

2. Verify any incoming DKIM signature and record the fact in an  
Authentication-Results header (unless he chooses to discard it for lack of  
authentication).

3. (Re-)Sign it, covering any added Authentication-Results.

So there it is. Discussion?

And if people like the idea, I could write it up as an ID.

-- 
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: Douglas Otis <[email-masked]>
Date: Thu, 29 Jul 2010 14:46:22 +0200

> to persuaded to observe whatever "Best Practice" is being proposed.
Charles,

The TPA-Label approach does _not_ depend upon changes made by the 
mailing-list!  The TPA-Label limits change to code already handling ADSP 
records, and of course to domains making ADSP assertions.  There is only 
a small number of domains making actionable ADSP assertions.  The 
TPA-Label would allow Author Domains a means to assert explicit 
exceptions when processing their restrictive ADSP assertions.  Rather 
than thousands of mailing lists, and MUA clients requiring change, only 
recipients would be advised to sort these messages into separate 
folders, which most already do anyway.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Jul 2010 05:22:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Thursday, July 29, 2010 4:22 AM
> To: [email-masked]
> Subject: [ietf-dkim] Alternative MAiling List Approach
> 
> [...]

Wouldn't this or some version of it be easier to incorporate in the current lists draft as a discussion of alternate approaches?

---

From: Daniel Black <[email-masked]>
Date: Thu, 29 Jul 2010 22:14:32 +1000

> I promised to do this some while back, but only just got a round tuit.

Ah the mythical round tuit.

I put a similar idea through when once I had a round tuit. Feel free to follow 
the threads.
http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 29 Jul 2010 18:46:34 +0200

> discarded), but obviously it raises several other issues instead.

SRS on "From"?  It is intriguing that, after having taken a rather 
different approach, DKIM faces much the same problems that SPF had 
been criticized for, for the same minor fraction of the email traffic.

IMHO, the real cause of the problem is that the same "From" field is 
being used for entirely different message streams.  On the one hand, 
the MLM wants the input message to be signed, so it can authenticate 
the poster.  On the other hand, MLM output isn't the land of the 
author domain (including IPR, usually) even if the original "From" 
stays there to identify the author.

As for the solution, it is much cleaner if Joe himself sets up an 
ADSP-unencumbered address to start with.  I see phishermen use 
approach #3 even if it is not standardized.  Perhaps, we should find 
ways to avoid that, rather than introducing new possibilities.

On 29/Jul/10 14:46, Douglas Otis wrote:
> exceptions when processing their restrictive ADSP assertions.

I agree that TPA-Label would make it more practical to use policies 
other than "unknown".  However, I have the feeling that it is more 
useful for small domains that want to use external services, than for 
mailing lists.  For a large domain whose users are free to subscribe 
to any list, I see two major concerns:

1. There is no standard way for the domain to learn when any of its
    users subscribe to a new list.  In practice, users would have to
    check whether the relevant TPA already exists, and possibly apply
    for it internally, before subscribing.

2. Granting a TPA implies a good degree of trust.  I don't think
    /any/ mailing list would obtain a TPA from, say, PayPal; the sites
    who would could then be trusted "by proxy" by anyone who takes
    PayPal's assessments for good...

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 29 Jul 2010 19:24:34 +0100

--On 29 July 2010 18:46:34 +0200 Alessandro Vesely <[email-masked]> wrote:

>> should change the From: header in such a way that the mail appears to
>> have come from MLM.example and not from discardable.example. Clearly,
>> this removes the cause of the problem at a stroke (the mail will no
>> longer be discarded), but obviously it raises several other issues
>> instead.
>

Actually, importantly, it's a *different* minor fraction of the email 
traffic. Mailing lists that break DKIM headers will almost certainly 
rewrite the envelope.

This is important, because it means that widespread deployment of DKIM 
*and* SPF would mean that almost all legitimate email would either carry a 
good DKIM signature, or pass SPF.

That means that the recipient should be able to make a judgement against 
either a DKIM signer reputation engine, or a return-path email address 
reputation engine, or an EHLO string reputation engine. I guess those 
reputation engines might all be the same domain keyed machine, but they 
could also encompass user-driven whitelists for authenticated email 
addresses (return paths, From addresses with domain matches, etc).

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: John Levine <[email-masked]>
Date: 29 Jul 2010 18:26:55 -0000

>come from MLM.example and not from discardable.example.

Hmmn.  I don't see how this does what ADSP users want.  There's the
obvious issue that this screws up lists that work perfectly well for
the 99% of people who don't use ADSP for the benefit of the 1% that do
use ADSP, but I'm assuming you don't see that as a problem.

The issue, as I understand it, is that very important people use ADSP
and send mail through mailing lists.  Even if list recipients have
full confidence in what the list sends, e.g., because it puts its own
signature on outgoing list mail, it's still essential to provide the
extra assurance that mail from the ADSP user is really from him.
Simply changing the From: header doesn't do that, since there's no way
to be sure that the list software did adequate verification of the
sender's identity.

One obvious solution is to forget ADSP and use S/MIME.  Header changes
don't affect it, and text footers added after the last MIME section
delimiter won't matter either.  Every current MUA supports S/MIME, so
users can easily verify that your mail is signed and really from you.

If S/MIME is too heavyweight, another simple approach is to put the
message body on a web page, and put an https: URL in the message body,
in a web server whose domain matches the From: address.  If the
message is From: [email-masked], and the URL is something like
https://important.example/bob/msg-1234.txt, recipients can be
confident that they're reading an untampered message.

I'll be happy to write this up for addition to the mailing list draft.
Or not.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Thu, 29 Jul 2010 10:51:52 -0700

> been criticized for, for the same minor fraction of the email traffic.

DKIM doesn't suffer from them, really.

OTOH, ADSP is broken in pretty much the same way SPF is, and
so it's not surprising that the bodges proposed to fix it
look similar.

I know you're not actually confusing the two but lets try and
not conflate them, just to keep the discussion clear. ADSP
is not DKIM any more than SPF is IP.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 29 Jul 2010 14:06:58 -0400

> stays there to identify the author.

First, it's a different minor fraction of email traffice (forwarding versus 
mailing lists), but more importantly there's clear support in the standards 
for treating mailing list mails as a new transmission, rather than a 
continuation of the old one.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 29 Jul 2010 21:35:32 +0200

> so it's not surprising that the bodges proposed to fix it

+1

But to elaborate, for those missing the point:

0.  As Steve notes, ADSP creates the problem, not DKIM.

1.  SPF creates a path dependency that breaks when mail is relayed through 
multiple MTAs; hence it breaks with even basic email.  ADSP creates a path 
dependency that breaks when mail is re-posted; that is, after it is delivered 
and then re-submitted; hence it breaks for value-added functionality.  These are 
at completely different layers of the architecture, although yes, they both 
derive from creating a handling path dependency that is not present in 'regular' 
email.

2.  Folks need to take note of the fact that a problem that is created by added 
functionality which is needed by only specialized scenarios is probably best not 
"fixed" by adding more mechanism.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Jul 2010 15:45:44 -0700

> have

It looked to me that a couple of people agreed with this.  That's far from consensus but it indicates a question that should be posed:

Should the MLM draft suggest From: replacement and addition of Reply-To: as a specific example of DKIM-friendly MLM behavior?

Those things could be deployed by only touching MLMs; Charles' #4 above would also require MUA and/or general MTA co-operation, so it's probably too ambitious for this effort.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 29 Jul 2010 20:56:19 -0700

> Should the MLM draft suggest From: replacement and addition of Reply-To: as a specific example of DKIM-friendly MLM behavior?

No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for "DKIM-friendly" behaviour would be nonsensical.

It might be a reasonable suggestion for the benefit of other protocols, but that's a different question.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Jul 2010 00:26:34 -0700

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, July 29, 2010 8:56 PM
> To: DKIM List
> Subject: Re: [ietf-dkim] Alternative MAiling List Approach
> 
> > Should the MLM draft suggest From: replacement and addition of Reply-
> To: as a specific example of DKIM-friendly MLM behavior?
> 
> No. DKIM doesn't really say much about either the From: address or the
> Reply-To: address, so such a suggestion for "DKIM-friendly" behaviour
> would be nonsensical.
> 

Is it not an ADSP issue though?  Covering ADSP issues is (at least implicitly) in scope for this document.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Jul 2010 09:40:26 +0200

> Is it not an ADSP issue though?  Covering ADSP issues is (at least implicitly) in scope for this document.

This purporting to be a technical group, precision in the use of labels is 
broadly viewed as a Good Thing.

If you want to characterize it as ADSP-friendly, that would be precise and 
possibly accurate.

As Steve notes, this has nothing to do with DKIM and therefore must not be 
labeled DKIM-friendly.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Jul 2010 10:33:31 +0200

On 7/29/10 9:35 PM, Dave CROCKER wrote:
> Folks need to take note of the fact that a problem that is created by added
Dave,

The TPA-Label draft offers an ADSP practice that will not disrupt MLM, 
or other types of informal third-party services.  These practices will 
not depend upon changes in third-party services.  In other words, it 
does not depend upon other mechanisms.  It is limited to ADSP.  Changes 
to ADSP will not impact the few existing domains current, limited, and 
problematic ADSP practices.

For domains that will benefit by a strong ADSP anti-phishing stratagem 
and also wish to use informal third-party services, the overhead of 
providing authorization should not be a hardship.  It will likely 
require informing their users of an internal webpage where requests for 
these service can be authorized.  Perhaps the industry might even 
establish a comprehensive list of these informal third-party services, 
where any outbound traffic to any of these domains could automatically 
generate needed authorizations, or offer immediate feedback to users 
without any problematic message even being sent.

Prior to authorization, only a few minor checks are needed, which also 
could be compiled in the industry list of these services.
  1) the email-address of the subscriber is confirmed by a pingback 
message.
  2) the messages from the list can be recognized by way of annotation, 
list-id header fields, etc.

If these two elements are met, using "tpa-sig" or "tpa-path" assertions 
in ADSP practice should offer adequate anti-phishing protection.  
Authorization can be quickly withdrawn when a problem is reported.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Jul 2010 10:58:02 +0200

On 7/29/10 6:46 PM, Alessandro Vesely wrote:
> >> The TPA-Label approach does _not_ depend upon changes made by
> >> the mailing-list!  The TPA-Label limits change to code already
> >> handling ADSP records, and of course to domains making ADSP
> >> assertions.  There is only a small number of domains making
> >> actionable ADSP assertions.  The TPA-Label would allow Author
> >> Domains a means to assert explicit exceptions when processing
> >> their restrictive ADSP assertions.
 >
>  check whether the relevant TPA already exists, and possibly apply for
>  it internally, before subscribing.

Disagree. Likely most of the domains being heavily phished are already 
required to careful monitor outbound traffic. If the industry were to 
compile a list of informal third-party service domains, along with their 
recommended TPA-Label assertions, any outbound traffic could quickly 
confirm whether authorization had been granted, and use the compiled 
list to automatically generate the authorization, or simply point their 
"_tpa" list to such an industry list already being published, or 
immediately reject the message and inform the user they need to find a 
different alternative.

Any recommendation that suggests a targeted and recognized domain should 
start using other domains or subdomains to conduct public exchanges 
simply creates new avenues for phishing and will cause greater recipient 
confusion.  In other words, a very bad practice.

>  PayPal's assessments for good...

Most mailing lists would be safe for a domain in their position to 
authorize.  Most who subscribe already sort these messages.  The 
TPA-Label can even ensure whether a message came from the authorized 
list.  Any mailing list that confirms subscriptions, and adds  typical 
annotations should be safe to authorize.  Of course, things like A-R 
headers would be better.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Jul 2010 13:05:15 +0200

On 30/Jul/10 10:58, Douglas Otis wrote:
>>   users subscribe to a new list.
>
> Disagree.

I'm happy to hear that.  The possibility that a domain becomes aware 
of all of its users' subscriptions has been aired various times 
before.  I think that is in many people's desiderata, and have even 
tried to devise a way of collaboratively doing it (fixforwarding.org.)

Anyway, let's assume that a domain has somehow managed to maintain a 
database of all the lists that its users are subscribed to.  That 
domain signs all outbound mail and publishes a non-default ADSP.  I 
propose that, when a message is destined to a list, the author domain 
signs a few header fields only, not the body, and tags the message 
with a (signed) list-signature-required sort of advice.  Messages to 
multiple list and non-list recipients have to be split, regularly 
signing the non-list copy.

Another way of achieving the same effect would be to standardize all 
acceptable message changes, together with a MIME-compliant 
canonicalization.  We've already noted that in some cases (plain text, 
poster-added subject tags, not signing "Content-Type", l=) it may work 
as-is.  For the general case, and for the time being, the advice 
requiring the added list signature guards against replay attacks: 
Verifiers must ensure that both signatures are valid, unless they are 
the domain whose signature is missing.

>>   2. Granting a TPA implies a good degree of trust.
>
> authorize.

Except that phishermen.com may set up a mailing list for the sole 
purpose of getting that auth.

W.r.t. TPA, this joint-signature proposal only authorizes messages 
actually destined to a mailing list.  Although the list can change the 
whole body, it is still constrained by the few signed fields.

---

From: John Levine <[email-masked]>
Date: 30 Jul 2010 15:34:55 -0000

>No. DKIM doesn't really say much about either the From: address or
>the Reply-To: address, so such a suggestion for "DKIM-friendly"
>behaviour would be nonsensical.

+1 on Steve's -1

Mailing lists work perfectly well with DKIM.  All this stuff about trying
to peer through them and removely validate contributors is something that
lists have never done before and we have no reason to invent now.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 30 Jul 2010 08:48:22 -0700

> Is it not an ADSP issue though?  Covering ADSP issues is (at least implicitly) in scope for this document.

It may well be an ADSP issue - I've not looked in detail at the
proposal - and it may be in scope for this document. (I suspect
it's also a bad idea, but that's a separate discussion).

It's definitely not a DKIM issue, though, and any labeling of a
non-DKIM issue as "DKIM-friendly" would be misleading.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 Jul 2010 16:15:27 -0400

> non-DKIM issue as "DKIM-friendly" would be misleading.

IIRC we used to refer to the DKIM base signing spec and ADSP (and all the 
names it previously had, most of which I've fortunately forgotten) as both 
being part of DKIM.  It seems a bit odd to me to refer to issues with specs 
produced by the DKIM working group as "non-DKIM".

Scott K

---

From: Wietse Venema <[email-masked]>
Date: Fri, 30 Jul 2010 20:20:26 -0400 (EDT)

> produced by the DKIM working group as "non-DKIM".

-1.

ADSP is fundamentally broken (not as badly as its predecessors)
but DKIM is not.

	Wietse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 31 Jul 2010 02:26:50 -0700

> [email-masked]] On Behalf Of John Levine
> Sent: Friday, July 30, 2010 8:35 AM
> lists have never done before

That's true, but...

> and we have no reason to invent now.

That may not be.  There are some major installations out there that want this capability (and in fact are already doing it, and roughly this way).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 31 Jul 2010 02:27:20 -0700

> Sent: Friday, July 30, 2010 8:48 AM
> To: DKIM List

I concur that this specific issue is an ADSP one and not a DKIM (i.e. RFC4871) one.  I don't have any problem being more clear about that.

But I disagree that ADSP is out of scope in general (re: the ADSP is or is not part of DKIM debate), unless we also want to remove all the other stuff in the lists draft about ADSP that people generally seem to like (currently 27 instances).