Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 03 May 2015 01:56:44 +0900

Kurt Andersen writes:

 > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin <[email-masked]>
 > wrote:

 > > my corporate email address, but I wanted to mention the presence of such
 > > headers is not foolproof.

 > With List-Id becoming a more generic feedback channel, I suspect
 > that its value for indicating the participation of a MLM will
 > further degrade.

Guys, if you want to attack a proposal, please make one first.  I did
not propose this.  My whole point was that it's easy to imagine ways
that the registration problem could be handled by "p=reject" domains
*if* they want to handle it, and therefore we *don't* need to make any
such proposal ourselves.  No more, and no less -- I wouldn't waste the
list's time on such a proposal if I were you.  But YMMV, be my guest.

Burning-strawmen-is-child's-play-ly y'rs,

Steve

---

From: "John Levine" <[email-masked]>
Date: 2 May 2015 17:34:19 -0000

>With List-Id becoming a more generic feedback channel, I suspect that its
>value for indicating the participation of a MLM will further degrade.

This is news to me.  Can you explain or give pointers?

The only application of List-ID with which I am familiar is to sort
(or filter depending on which coast you're from) mailing list traffic
more reliably.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 2 May 2015 21:47:57 +0200

> (or filter depending on which coast you're from) mailing list traffic

I see email marketing campaigns using List-ID, behold:

BEGIN===============================================================
 Return-Path: <bounce-mc.us3_22600075.764833-jgomez=[email-masked]>
 X-Original-To: [email-masked]
 Delivered-To: [email-masked]
 X-Greylist: delayed 902 seconds by postgrey-1.27 at gran.example.com; Thu, 23 Apr 2015 10:32:17 CEST
 Received-SPF: pass (mail173.atl61.mcsv.net: 205.201.135.173 is authorized to use 'bounce-mc.us3_22600075.764833-jgomez=[email-masked]' in 'mfrom' identity (mechanism 'ip4:205.201.135.173' matched)) receiver=gran.example.com; identity=mfrom; envelope-from="bounce-mc.us3_22600075.764833-jgomez=[email-masked]"; helo=mail173.atl61.mcsv.net; client-ip=205.201.135.173
 Received: from mail173.atl61.mcsv.net (mail173.atl61.mcsv.net [205.201.135.173])
  by gran.example.com (Postfix) with ESMTP id A58771335
  for <[email-masked]>; Thu, 23 Apr 2015 10:32:17 +0200 (CEST)
 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail173.atl61.mcsv.net;
  h=Subject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=info=[email-masked];
  bh=wGF7q/xDOPhln8GsTOwUyofYAmk=;
  b=X3o/vsisNJ2otny+LFofvyn0QboEogdi5tnTOTqAalIGssHj3CidoXhwm5aj8jsb30CWr8omyZDe
    jkDq86qUfe0dvo+Tiqd+DYg1GuLDagoHLCuJhajmuPAjU5m/fEyYL3MmKSr1nphnUZy+Uv2n42QJ
    HS+3HI7c/Elgp+xxSRU=
 DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail173.atl61.mcsv.net;
  b=DJAKlTvtTaXjHyzWE2vbHZG445Y17LQ2nqspsqVDCHsCULyrMc932Gv5NORCoLfe9u3EzezZf+x4
    7/SWl1sk5JXTB6B+L3TJbyHRzpy9JYI9ygF/ZBKW1JL7D10DvZNtHZLZk83aD1gm/CvUf4H1BzIv
    L4xpJqbsPu8frmYaM/Q=;
 Received: from (127.0.0.1) by mail173.atl61.mcsv.net id h72n16174ac0 for <[email-masked]>; Thu, 23 Apr 2015 08:17:13 +0000 (envelope-from <bounce-mc.us3_22600075.764833-jgomez=[email-masked]>)
 Subject: =?utf-8?Q?Regala=20m=C3=A1s=20que=20un=20libro?=
 From: =?utf-8?Q?AcerOnline?= <[email-masked]>
 Reply-To: =?utf-8?Q?AcerOnline?= <[email-masked]>
 To: =?utf-8?Q??= <[email-masked]>
 Date: Thu, 23 Apr 2015 08:17:13 +0000
 Message-ID: <[email-masked]>
 X-Mailer: MailChimp Mailer - **CID91c1f99d79d685b8a711**
 X-Campaign: mailchimpae5586b59986b26a25e2b4f5d.91c1f99d79
 X-campaignid: mailchimpae5586b59986b26a25e2b4f5d.91c1f99d79
 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=ae5586b59986b26a25e2b4f5d&id=91c1f99d79&e=d685b8a711
 X-MC-User: ae5586b59986b26a25e2b4f5d
 X-Feedback-ID: 22600075:22600075.764833:us3:mc
 List-ID: ae5586b59986b26a25e2b4f5dmc list <ae5586b59986b26a25e2b4f5d.422745.list-id.mcsv.net>
 X-Accounttype: pd
 List-Unsubscribe: <mailto:[email-masked]?subject=unsubscribe>, <http://aceronline.us3.list-manage.com/unsubscribe?u=ae5586b59986b26a25e2b4f5d&id=d5fadc2a35&e=d685b8a711&c=91c1f99d79>
 Sender: "AcerOnline" <info=[email-masked]>
 x-mcda: FALSE
 Content-Type: multipart/alternative; boundary="_----------=_MCPart_1886660041"
 MIME-Version: 1.0

 This is a multi-part message in MIME format

 --_----------=_MCPart_1886660041
 Content-Type: text/plain; charset="utf-8"; format="fixed"
 Content-Transfer-Encoding: quoted-printable

 http://www.aceronline.es?mc_cid=3D91c1f99d79&mc_eid=3D[UNIQID]
 Port=C3=A1tiles (http://www.aceronline.es/portatiles-acer.html?mc_cid=3D91=
 c1f99d79&mc_eid=3D[UNIQID])  |  Tablets (http://www.aceronline.es/tablets=
 -acer.html?mc_cid=3D91c1f99d79&mc_eid=3D[UNIQID])  |  Smartphones (http:/=
===============================================================END.

Regards,
J.Gomez

---

From: Douglas Otis <[email-masked]>
Date: Sat, 02 May 2015 14:21:46 -0700

> list's time on such a proposal if I were you.  But YMMV, be my guest.
Dear Stephen,

Tend to agree.  Authentication methods alone never exclude
malefactors.  Problems occur when assuming general public
messages MUST maintain alignment between mailfrom and from
while completely ignoring sender and group syntax needed to
handle EIA, or the addition of PGP encryption, or defanging
dangerous links and banned words.  The mistaken assumption
is use of standard conventions identifies untrustworthy or
conversely DMARC identifies trustworthy sources.   Since
DMARC uses either SPF or DKIM and since DKIM can always be
replayed to any number of recipients, controlling abuse
REQUIRES constant monitoring beyond DMARC feedback whether
or not extended by TPA-Label, DKIM-Conditional,
DKIM-Transform. Trust requires constant assessment and close
cooperation between receiving and sending domains.  Email
does not support "Set and forget it" modes of operation when
dealing with public exchanges.  Senders should never assume
restrictive DMARC assertions relieves the need to monitor
and respond to abuse.

The few DMARC domains causing trouble can be handled by
private override lists, but there should be standardized
profiles to help ensure better practices.

One possible profile is described here:
https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-2

This profile better ensures email is less likely disrupted
by errant policy assertions simply by offering "public"
handling.  This avoids causing recipients to be unable to
ascertain authors or the contents of their quarantine
folders while avoiding expensive message disruptions.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 May 2015 23:58:04 -0400

> (or filter depending on which coast you're from) mailing list traffic

You can also  filter, separate, categorized, "folderized" or "sort" 
per se using List-Post.

And for modern List-* supportive MUAs, it triggers adding a third 
possible button for replying:

  [Reply]           Reply-ID, if any, otherwise From:
  [Reply to All]    Reply-Id, From, To, Cc, List-ID
  [Reply to List]   List-ID

Just like "Newsgroup:" also triggers a [Reply to Group] button display 
in NNTP mail readers/writers.

Btw, you are the only one that I have seen use the term "sort" for 
this purpose. I get it, but seems odd. Sort would not be the proper 
idea unless you were sorting all the incoming mail first in order to 
find something, and it would be ordered too when using the term sort. 
  The MUAs have called it "Create/Manage Messages Filters" or RBM 
(Rule Based Messaging) as they were patently called decades ago. They 
did not do any "sorting" per se, but move the mail as it streamed in 
into user created folders or in the case of at least one MUA, it auto 
creates the folders based on either List-ID or List-Post.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 May 2015 07:00:05 -0700

On 4/30/2015 10:03 AM, Kurt Andersen wrote:
> With List-Id becoming a more generic feedback channel,

Kurt, forgive my confusion but I don't understand what it means for
List-ID to be a 'feedback channel'.

List-ID provides some identification.  How does that make it a channel
and specifically a feedback channel?

Thanks.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 May 2015 07:02:57 -0700

On 5/2/2015 9:56 AM, Stephen J. Turnbull wrote:
> Guys, if you want to attack a proposal, please make one first. 

Small process comment:

     It's always best to offer a solution when one offers a criticism.

     But it's not required.

     If something won't work, it won't work.

Although desirable, offering a solution that /will/ work isn't a
pre-requisite to commenting about a proposal's deficiencies.

d/

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 May 2015 18:42:58 -0400

+1

I agree alternatives should not, nor has it even been required, to 
offer "criticism" in reviews. However, in this case, for what its 
worth, I didn't see/read Kurt's comment as criticism so I don't think 
the outburst was warranted.

Kurt might explain what he meant but I believe the 5322.List-ID header 
appears to have less added value and significance for DKIM purposes. 
It is very useful for the MUAs for categorizing mail.  In fact, if we 
were to use a "List-ID" to trigger perhaps some "relaxed" DKIM 
verification method, it can be used as a DKIM policy security hole.

I think the List-ID idea for DKIM/Policy  is where it can possibly 
help in an automated registration scheme or even protocol to help 
initiate the authorization process of MLMs.  Its possible, but not 
everyone will use the List-ID so it can't be completely automated.

I think the key essential difference for the the MLM condition is:

     Author Domain IDentity (ADID) !=  Signer Domain IDentity (SDID)

That should be the trigger that will offer the maximum backend 
compatibility and plug and play solution.  No other triggers are needed.

-- 
HLS

On 5/4/2015 10:02 AM, Dave Crocker wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Franck Martin <[email-masked]>
Date: Mon, 4 May 2015 18:20:42 -0500 (CDT)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> To: "Kurt Andersen" <[email-masked]>
> Cc: [email-masked], "Murray S. Kucherawy" <[email-masked]>, "Franck Martin" <[email-masked]>
> Sent: Saturday, May 2, 2015 9:56:44 AM
> Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
> 
> Kurt Andersen writes:
> 

I did not want to burn your proposal, sorry if it passed like this. I just wanted to make a comment, from personal observations, that non-mailing list related emails have list-id too.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 06 May 2015 01:16:16 +0900

Franck Martin writes:

 > I did not want to burn your proposal, sorry if it passed like
 > this. I just wanted to make a comment, from personal observations,
 > that non-mailing list related emails have list-id too.

I made the same observation from a theoretical point of view, so I
have no problem with you stating those facts.

But the main point that everybody is missing is that we *do not* need
to deal with the "registration problem" in this WG because the
information to register a substantial fraction of mailing lists is
distributed in the related mailflows already, and the mailbox
providers know where to find the users for confirmation of their
intent.  There's no need for new protocols.

I would prefer to focus on getting a signature delegation protocol
specified and hopefully put into practice, discussing mailing list
verification practices when potential users bring them up.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 May 2015 12:50:43 -0400

>verification practices when potential users bring them up.

No.  I believe that entirely assumes away the hard part of the work. The hard part isn't figuring out candidate data. That can trivially be done as you suggest.  The hard part is figuring out the subset of the data that's worthy of special treatment. 

Approximately as soon as list-id enables DMARC bypass, the bad guys will start adding it to everything. List-id is useless in this context. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 10:08:40 -0700

> >intent.  There's no need for new protocols.

Doesn't this presuppose that only good actors use that information channel
properly?

> No.  I believe that entirely assumes away the hard part of the work. The
> hard part isn't figuring out candidate data. That can trivially be done as
> you suggest.  The hard part is figuring out the subset of the data that's
> worthy of special treatment.
>
> Approximately as soon as list-id enables DMARC bypass, the bad guys will
> start adding it to everything. List-id is useless in this context.
>

I think that's right.  I'm guessing that the Gmails of the world have
heuristics that go beyond List-Id for identifying what incoming flows are
legitimate lists and which are not.

On the other hand, for small operators, maybe List-Id is enough of a good
starting point to suggest it, without baking it into a protocol document as
something normative.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Tue, 05 May 2015 10:16:55 -0700

> I did not want to burn your proposal, sorry if it passed like this. I just wanted to make a comment, from personal observations, that non-mailing list related emails have list-id too.
Dear Kurt and Franck,

List-ids on their own offer little value.  Accommodations
for MLMs can leverage list-ids to confirm a subscription
which can be sorted accordingly.

Unlike transactional messaging that often does not involve
non-vetted messages, public interaction often makes use of
friendly displays and simple sorting methodology.  It is
doubtful there is a safe and responsive method to delegate
signing on a public message by public message basis without
causing uncontrollable risk.  No authentication method
prevents abuse, but signature delegation introduces a
greater range of deceptions.

An ability to require specific list-ids/domain offers a few
advantages-

1) origination out of a subscribed and authorized source
2) exceptions that permit invalid author domain signatures
but require an ability to be sorted accordingly
3) allows disabling specific problematic lists without
impacting others

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 May 2015 13:25:43 -0400

> Approximately as soon as list-id enables DMARC bypass, the bad guys will start adding it to everything. List-id is useless in this context.

The main point would be that DSAP protocols can still be completed 
making the registration part out of scope.  It would be part of the 
publishing and adoption, migration section as a short or long prospect.

The same was true with SPF -- you had to wait until domains were 
published and registered.  Btw, What is your SPF payoff? Your average 
daily SPF rejection?

It is up to yahoo and others if they want to put an effort of 
registering domains in order to white list them.  That shouldn't stop 
an issue for most domains and it should not be a barrier to having a 
3rd party authorization protocol.

As a receiver, I am willing to do a DNS call to the ADID/SDID pair 
(when it differs) to see if there is an authorization.  I don't really 
wish to be changing code to read/write double signatures.  This will 
raise the adoption barrier.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 May 2015 13:33:50 -0400

On May 5, 2015 1:25:43 PM EDT, Hector Santos <[email-masked]> wrote:
>> No.  I believe that entirely assumes away the hard part of the work.
>The hard part isn't figuring out candidate data. That can trivially be
>done as you suggest.  The hard part is figuring out the subset of the
>data that's worthy of special treatment.
>>
>> Approximately as soon as list-id enables DMARC bypass, the bad guys
>will start adding it to everything. List-id is useless in this context.
>>
>> Scott K
>

Wrapping a 'somebody else's problem field' around the registration piece of this doesn't make it any more feasible.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 May 2015 13:56:11 -0400

> Wrapping a 'somebody else's problem field' around the registration piece of this doesn't make it any more feasible.

Feasibility?  If we are basing progress solely on that, we wouldn't be 
far along. IETF protocol engineering generally leaves optimization 
considerations for implementations to work out.

The two problems are different.  Its the same SPF had and still has. 
Do you think its fair that the big domains are exerting high SPF 
processing pressure with multiple DNS calls per transaction only to 
result in soft or neutral?   They are not sure. What if they decided 
to switch to a hard fail? Will they get it right?

My proposal is based on the fact that DMARC overhead is already being 
done, thus making it feasible to consider a piggy back design that 
allows for a ATPS lookup.  DMARC offers 3rd party extensions for this 
purpose.  It would be optional.  Will there ever be  high payoff 
results?  Probably not for a long time, but who knows.  Maybe there 
can be an in-band optimizer:

    5322.DKIM-ATPS: The ADID creates ATPS records. Please Check the 
ADID/SDID.

and let people decide if that offers some feasibility in minimizing 
the lookup or if just always does a lookup anyway and crosses its finger.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 11:01:26 -0700

On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman <[email-masked]>
wrote:

> Wrapping a 'somebody else's problem field' around the registration piece
> of this doesn't make it any more feasible.
>

Is it sufficient to say something like this?:

"A participating operator needs to solve the registration problem.
Different operators will have different capabilities, requirements, and
limitations here.  A very simple approach would be <List-Id magic here>;
however, this has the following drawbacks: <List-Id anti-magic here>.
Non-trivial solutions may or may not appear in later documents."

This illustrates the problem and the importance of solving it in some
detail which would give someone "skilled in the art" enough context to come
up with something in his or her particular environment, while not
constraining DMARC to something that is not universally useful.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 May 2015 14:24:19 -0400

On 5/5/2015 2:01 PM, Murray S. Kucherawy wrote:
> On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Wrapping a 'somebody else's problem field' around the registration
>     piece of this doesn't make it any more feasible.
>
>

"Participating Publishers ...."    What has to be known is that 
Receivers are willing to participate by doing a policy check with the 
design presumption there will be records.

This is normal migration, adoption considerations.

> Different operators will have different capabilities, requirements,
> and limitations here.  A very simple approach would be <List-Id magic
> here>; however, this has the following drawbacks: <List-Id anti-magic
> here>.  Non-trivial solutions may or may not appear in later documents."

Of course, it depends on the details of the magic. But yes, its a 
different problem.

> detail which would give someone "skilled in the art" enough context to
> come up with something in his or her particular environment, while not

You don't even have to say "universally useful."  All that does is 
keeps possible implementators away.   It can be very useful to some 
and to them, its universal.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 05 May 2015 11:26:09 -0700

> constraining DMARC to something that is not universally useful.

Dear Murray and Hector,

Almost.  Consider the DDoS concern issue that made ATPS
impractical by requiring special TP DKIM signatures.  This
problem can be solved with standard DKIM signatures in
conjunction with a domain wide semaphore provided by a DMARC
assertion ignored by recipients lacking the TP enhancement. 
Special DKIM signatures are really not necessary and will
introduce more DNS overhead than would be caused by a simple
hash reference.  Faster, smaller message size, and far
simpler signing processes become possible.  As illustrated
in
http://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4
,--

DMARC could make an
assertion of "sam=tpa; and tpa=third-party-authority.example.com;"
when the DMARC domain offers the Specific Advisory Methods "sam="
tag indicating the third-party advisory methods supported.  The
"tpa=" tag can also indicate the domain location where third-
party-authorization hashes have been consolidated with an assumed
prefix of "_smtp._tpa.<tpa-domain>".

'--

This would allow large ESP a simple means to share the
registration profiles that should greatly benefit all of
their recipients.

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 5 May 2015 18:55:43 -0000

>limitations here.

So far so good.

> A very simple approach would be <List-Id magic here>;

Not so good, since there are lists that do't have list-id and spam
that does.

There's a large class of approaches that either require registration,
the various third party signers, or would likely work better with it
like my double signing thing.  But it's clear to me that if there were
an easy way to register lists globally, we would already have done it.

Large providers have a pretty good idea of who's sending them list
mail, e.g. Google notes in in their DMARC reports, so they can use
their own list if they want.  Small providers will have to do other
stuff, but ad hoc approaches like adding lists when users compiain is
probably OK.

So I'd just note when something needs or would be aided by
registration but not waste time trying to invent a way to do it.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 May 2015 15:01:39 -0400

> prefix of "_smtp._tpa.<tpa-domain>".

First, it needs to protect the 1st party.  The "tpa=" tag does offer
a method to allow outsourcing.   As long as it remains a choice of the 
first party, under control of the first party, and it defaults to the 
first party, then it offers something worth while.

     Corollary:  Do not mandate a "Batteries Required" 3rd
                 party trust system.

Second, this would be a DMARC extension, so it would piggy back off 
the DMARC call already being made.   At most, there would be two DNS 
calls.  But there is no dependency on DKIM signer/verifier code change.

Third, a "sam=" tag can be used to support different methods, 
including Levine's in-band method.

I think we will need the "hash=" tag to define how a lookup hash is 
done, if any, default none.   But in my ATPS experience, this was the 
hardest part.  Keep it simple.

I can support a simple spec that is basically a lookup as you 
described above, with a first party priority.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 12:09:47 -0700

> registration but not waste time trying to invent a way to do it.
My taking that run at it showed me that an example is necessary to
illustrate the goal and the general idea of the mechanism, and potential
problems with trivial solutions.  We could try relegating it purely to
prose, but even a concocted example would probably be useful.

So the stuff you're talking about here would go in what I labeled as
<List-Id anti-magic>, and the whole thing should read as "A naive
implementation could do this, but it's easily defeated by X, Y, Z; you have
to do something better that matches your requirements" or something like
that.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 5 May 2015 19:28:17 +0000

What about some variant of the following using a revised version of John Levine's conditional DKIM (@fs=) draft?

Here's the scenario. Joe User is an avid birdwatcher and joins the Birdwatchers in the northeast discussion group, [email-masked]<mailto:[email-masked]>. He sends a message to the group:

From: Joe User <[email-masked]>
To: [email-masked]
Original-To: [email-masked]
Subject: Hi, I'm Joe from the northeast!
DKIM-Signature: v=1; d=yahoo.com;
  h=from:date:subject:to:mime-version:message-id:content-type:original-to;
DKIM-Signature: v=2; d=yahoo.com; l=0;
  h=from:date:to:mime-version:message-id:content-type:original-to;

Birdwatchers' mail server receives the message and replays it out the rest of the world, including Frank whose also into bird watching and his email address is at Hotmail. After some additional formatting, we have the following with changes marked up with a * next to them:

From: Joe User <[email-masked]>
*** To: [email-masked]
Original-To: [email-masked]
*** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast!
DKIM-Signature: v=1; d=yahoo.com;
  h=from:date:subject:to:mime-version:message-id:content-type:original-to;
DKIM-Signature: v=2; d=yahoo.com; l=0;
  h=from:date:to:mime-version:message-id:content-type:original-to;
*** DKIM-Signature: v=1; d=birdwatchers.org;
  h=from:date:to:mime-version:message-id:content-type:original-to;
*** List-Id: "Birdwatchers in the Northeast" <[email-masked]>

At Hotmail:

- This messages passes SPF (birdwatchers.org)
- This message fails the first DKIM-Signature (d=yahoo.com) and passes the second (d=yahoo.com) but DKIM-Signature v=2 cannot be used for DMARC verification. It passes the third DKIM-signature (d=birdwatchers.org).
- It passed SPF and DKIM, but since neither of those domains aligns with Yahoo.com, it fails DMARC.

However, Hotmail does something interesting:

- It sees that the message has a List-ID header so before failing DMARC, it should do a little more work since this may be a forward from a mailing list.
- It sees that the DKIM-Signature v=2 with l=0 is too weak for DKIM alignment. But it sees that it contains an Original-To that was signed.
- The Original-To domain is birdwatchers.org
- The DKIM-signature that passed is d=birdwatchers.org --> which aligns with the domain in the Original-To --> which aligns with the weak signature that was signed by d=yahoo.com --> which aligns with the domain in the header.from (yahoo.com)
- Hotmail then deduces that the forwarding chain is intact and stamps "dmarc=pass-via-chain" in the Authentication-Results header and doesn't fail the message

I haven't thought it through entirely, but:

- This would be an add-on to DMARC and an add-on to DKIM, but not a big one. In fact, the DKIM-Sign v=2 could be v=1. DMARC would know not to align a weak DKIM signature (l=0) with DMARC by itself (indeed, we are basically saying l=0 should not be used for normal DKIM trust relationships). So it's no add on to DMARC.
- Senders have to include an Original-To if they know they are sending to a mailing list but could optionally send it for every message. They also need to send a second weak signature.
- DMARC verifiers need to update their handling.
- List forwarders don't need changes unless they don't add the List-ID. If not, they must if they want to pass DMARC.
- A short expiration time could be put onto the weak DKIM-signature to prevent replay attacks
- No TPA requires publishing in DNS, it's basically done on the fly
- I am not sure if this mitigates sufficiently against attacks
- I am reasonably sure I am missing a bunch of other things

But maybe something like that?

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
Sent: Tuesday, May 5, 2015 11:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

So far so good.

R's,
John

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 12:39:05 -0700

On Tue, May 5, 2015 at 12:28 PM, Terry Zink <[email-masked]>
wrote:

> *** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast![...]
> [...]
> - This would be an add-on to DMARC and an add-on to DKIM, but not a big
> one. In fact, the DKIM-Sign v=2 could be v=1. DMARC would know not to align
> a weak DKIM signature (l=0) with DMARC by itself (indeed, we are basically
> saying l=0 should not be used for normal DKIM trust relationships). So it’s
> no add on to DMARC.
>

You're either saying this change belongs in DKIM (which then ascribes
special meaning to this kind of signature combination, or to "v=2"
signatures, or something), or you're leaving DKIM alone and saying that the
analysis logic appears in DMARC.

What advantage does this have over John's proposal?  It actually looks more
complicated to me, because it spans the divide between DKIM and DMARC.
John's proposal is completely contained within DKIM.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 5 May 2015 20:17:27 +0000

> You're either saying this change belongs in DKIM (which then ascribes special
> meaning to this kind of signature combination, or to "v=2" signatures, or something),
> or you're leaving DKIM alone and saying that the analysis logic appears in DMARC.
I want to rescind my DKIM v=2 and put the analysis logic entirely in DMARC.

> What advantage does this have over John's proposal?  It actually looks more c
> complicated to me, because it spans the divide between DKIM and DMARC.  John's
> proposal is completely contained within DKIM.
John’s proposal changes DKIM but also requires additional changes in DMARC to respect the changes that were made to DKIM when doing alignment (the @fs=domain is more or less the same as the Original-To below). If I rescind my DKIM v=2 to only v=1, then it requires changes to DMARC analysis logic (which John’s would have required anyhow to extract the @fs and compare to the from address); and, requires some configuration changes to senders in DKIM but no code change (unless adding a second signature requires a code change).

-- Terry

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Tuesday, May 5, 2015 12:39 PM
To: Terry Zink
Cc: John Levine; [email-masked]
Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

On Tue, May 5, 2015 at 12:28 PM, Terry Zink <[email-masked]<mailto:[email-masked]>> wrote:
From: Joe User <[email-masked]<mailto:[email-masked]>>
*** To: [email-masked]<mailto:[email-masked]>
Original-To: [email-masked]<mailto:[email-masked]>
*** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast![...]
DKIM-Signature: v=1; d=yahoo.com<http://yahoo.com>;
  h=from:date:subject:to:mime-version:message-id:content-type:original-to;
DKIM-Signature: v=2; d=yahoo.com<http://yahoo.com>; l=0;
  h=from:date:to:mime-version:message-id:content-type:original-to;
*** DKIM-Signature: v=1; d=birdwatchers.org<http://birdwatchers.org>;
  h=from:date:to:mime-version:message-id:content-type:original-to;
*** List-Id: "Birdwatchers in the Northeast" <[email-masked]<mailto:[email-masked]>>

[...]

- This would be an add-on to DMARC and an add-on to DKIM, but not a big one. In fact, the DKIM-Sign v=2 could be v=1. DMARC would know not to align a weak DKIM signature (l=0) with DMARC by itself (indeed, we are basically saying l=0 should not be used for normal DKIM trust relationships). So it’s no add on to DMARC.

You're either saying this change belongs in DKIM (which then ascribes special meaning to this kind of signature combination, or to "v=2" signatures, or something), or you're leaving DKIM alone and saying that the analysis logic appears in DMARC.
What advantage does this have over John's proposal?  It actually looks more complicated to me, because it spans the divide between DKIM and DMARC.  John's proposal is completely contained within DKIM.
-MSK

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2015 16:24:19 -0400

> John’s proposal changes DKIM but also requires additional changes in 
> DMARC to respect the changes that were made to DKIM when doing alignment 
> (the @fs=domain is more or less the same as the Original-To below). ...

It's not supposed to.  The decision about whether a DKIM signature that 
depends on a chained signature is valid is supposed to happen entirely 
within the updated DKIM module.  DMARC just uses that result.  I assume 
the DKIM module is able to look at all of the DKIM signatures on a message 
and report back which ones are valid.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Terry Zink <[email-masked]>
Date: Tue, 5 May 2015 20:35:16 +0000

Hmm, okay. I need to think through what I wrote a little more, then. I think I misunderstood somewhat your proposal.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John R Levine
Sent: Tuesday, May 5, 2015 1:24 PM
To: Terry Zink
Cc: [email-masked]
Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 14:27:23 -0700

On Tue, May 5, 2015 at 1:17 PM, Terry Zink <[email-masked]>
wrote:

> John's
> John’s proposal changes DKIM but also requires additional changes in DMARC
> to respect the changes that were made to DKIM when doing alignment (the
> @fs=domain is more or less the same as the Original-To below). If I rescind
> my DKIM v=2 to only v=1, then it requires changes to DMARC analysis logic
> (which John’s would have required anyhow to extract the @fs and compare to
> the from address); and, requires some configuration changes to senders in
> DKIM but no code change (unless adding a second signature requires a code
> change).
>
>
I interpreted John's proposal to mean a DKIM verifier would not pass a
signature with "@fs=" unless it was also accompanied by a signature from
the "fs" domain.  Thus, the modified result logic is completely within the
DKIM module, which DMARC then consumes.  It's a much cleaner separation of
function that way.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 May 2015 14:28:01 -0700

On Tue, May 5, 2015 at 1:24 PM, John R Levine <[email-masked]> wrote:

>> @fs=domain is more or less the same as the Original-To below). ...
>>
>
> within the updated DKIM module.  DMARC just uses that result.  I assume the
> DKIM module is able to look at all of the DKIM signatures on a message and
> report back which ones are valid.
>

Other chatter on this list suggests that not all DKIM verifier
implementations work that way, unfortunately.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2015 17:42:46 -0400

> DKIM module, which DMARC then consumes.  It's a much cleaner separation of

Yes, exactly.  The idea was also that the new @ (or ! or whatever) 
modifier allows people to add new mandatory tags in the future that DKIM 
will understand but upper layer protocols don't have to.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2015 17:44:37 -0400

> implementations work that way, unfortunately.

I suppose I should take another look at the modules for which I have 
source code and see what they do.  Given that a DKIM verifier needs to 
have the entire message in hand to do the verification at all, it seems 
odd not to find all the signatures and do them all together.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Tue, 05 May 2015 15:24:23 -0700

On 5/5/15 1:24 PM, John R Levine wrote:
>> John’s proposal changes DKIM but also requires additional
>> changes in DMARC to respect the changes that were made to
>> DKIM when doing alignment (the @fs=domain is more or less
>> the same as the Original-To below). ...
>
> It's not supposed to.  The decision about whether a DKIM
> signature that depends on a chained signature is valid is
> supposed to happen entirely within the updated DKIM
> module.  DMARC just uses that result.  I assume the DKIM
> module is able to look at all of the DKIM signatures on a
> message and report back which ones are valid.
Dear John,

Your version of DKIM delegation is cleaner but there is
something that could be even cleaner.  For example,
TPA-Label could be made simpler by requiring a DKIMv2 like
element to indicate which header fields in a delegated
signature added by the third-party signature are not to
change.  Conversely, TPA-Label could reference a compressed
selection of headers that represent a predefined element
indicating which header fields are not to change between the
first and third-party signatures and eliminate even the need
for a DKIMv2 signature.  This could offer a similar expiry
scheme in the same manner, but I doubt such would be needed.
The first party DKIM signature could even include a hash
representing the content of the requisite headers, if that
seems important.

No special DKIM signature. No complex TPA registration which
upset Hector among others. This would have less overhead
without any mandated sequence or special DKIM signatures.

DMARC domain would need to track which third-party services
are being used.  They could simply amend the list as needed
and delay sending to any new domains until registered. This
effort could be delegated to a different entity able to
process outgoing logs and DMARC feedback.  Once in place,
DMARC induced disruption should evaporate while allowing
safe use of Sender header fields to retain SMTP compatibility.

We have seen too many botnets using various polymorphic
schemes able to leverage any window of time to amplify any
malicious message that might be allowed within any expiry. 
Expiry does not seem to offer much protection.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 May 2015 19:55:52 -0400

> and to them, its universal.

It depends on the type of mechanism we're discussing registration for.  If 
it's something receivers can do on their own with no cooperation from 
originators or mediators, then I agree.  A scheme that doesn't require 
cooperation with other actors in the architecture can be 'good enough' even if 
it's only useful to a segment of the user based.

OTOH, if there is a scheme that requires multiple actors in the architecture 
to cooperate, then (as I described in my utility analysis), it has to be 
pretty universally usable or it won't get sufficient deployment to be 
operationally useful.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 May 2015 23:00:43 -0400

> pretty universally usable or it won't get sufficient deployment to be

We are talking about DNS publication of records and domains having to 
roll up their sleeves and collect the data they need, if they want to, 
making a registration process available to DKIM resigners.

I see it as a separation problem.  The same one, nearly all the 
DNS-based protocols had/have -- Publishing DNS records requirement in 
order to be useful. If we had used this high bar to have a 
registration/publishing readiness or assurance first before you get 
started, as you ideally suggest, most of these protocols would not 
have been done.

You need to have your methods in place first and the minimum code 
changes among all actors is doing a simple DNS lookup as it was 
originally conceived.  That is not hard to compare with the 
alternatives which has a higher implementation cost and requires much 
greater code change.

Just like SPF, once enough domains published records, it became 
somewhat useful and only really more useful when rejection policies 
were set.  This is when a payoff was realized -- with a rejection 
policy. That took a mighty long time and yet, it is still a highly 
wasteful protocol. Neverteless, it didn't stop anyone from using it 
and domains with larger network of senders are still trying to figure 
them all out.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 May 2015 23:24:13 -0400

On Tuesday, May 05, 2015 11:00:43 PM Hector Santos wrote:
> > cooperation with other actors in the architecture can be 'good enough'
> > even if it's only useful to a segment of the user based.
> > 
> > OTOH, if there is a scheme that requires multiple actors in the
> > architecture to cooperate, then (as I described in my utility analysis),
> > it has to be pretty universally usable or it won't get sufficient
> > deployment to be operationally useful.
> 

No.  It's fundamentally different.

For SPF, the managers of an ADMD need to determine their authorized outbound 
email architecture.  That's in the hands of the administrators.  For these 
email list registration proposals it's the mailing list proclivities of every 
single user.  

Mars and Jupiter are "the same" in that they are both planets.  Trying to land 
on one is much more feasible than the other despite that sameness.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 06 May 2015 17:23:29 +0900

Scott Kitterman writes:

 > Approximately as soon as list-id enables DMARC bypass,

It never will.  (BTW, it's List-Post that's relevant.)  It's the
subscriber's action of posting to the list that enables the bypass.
That means that a successful attack of the kind that triggered the
April Fiasco requires an iterated phish: first you have to phish *me*
to post to your list, then you need to modify my post to phish
*Murray*.

If you have an alternative threat model in mind, please explain it.

 > the bad guys will start adding it to everything.

They already have, according to Franck.  That doesn't matter, though,
except as it requires more space in the "apparent lists" database.
Again, that's an implementation issue.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 06 May 2015 17:25:19 +0900

> Non-trivial solutions may or may not appear in later documents."

+1 (in fact, that's exactly what I had in mind).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 06 May 2015 17:38:08 +0900

John Levine writes:

 > Not so good, since there are lists that do't have list-id

Too bad for those lists.  What matters is that an awful lot of lists
do have list-id, and even more have list-post (which is the header
that matters here).  If the idea can convince p=reject-using Author
Domains, it's a big improvement for a lot of lists.

 > and spam that does.

Don't register lists that pass spam.  If spam that looks like it comes
from a list is getting through to your users, you have real problems
anyway.  What else is new?  I don't see an exploit here that isn't
already available to the mal-actors, and I don't see how it increases
risk substantially since it requires an iterated phish to succeed.

I guess the main risk would be if it gives the spammers a new way to
conceal the fact that their mailboxes at Author Domains are being used
as phishing vehicles via lists based at Spammer Domains.  But AIUI
that's the whole issue with TPA from the Author Domain standpoint.  Is
there a *new* issue here?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 May 2015 07:28:25 -0400

> there a *new* issue here?

TPA requires cooperation from originators and receivers, so there's no "new" 
issue.  Any make a list approach that needs both originators and receivers to 
participate needs to work for both large/small originators/receivers and I 
don't think this does.  That's not "new", but it is a problem.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 May 2015 07:56:24 -0400

> email list registration proposals it's the mailing list proclivities of every

It is fundamentally the same problem both DMARC and SPF has and I 
might even suggest, it may be even worst for SPF.

With SPF, users also have "proclivities" to roam around and send mail 
from unknown, "unregistered" machines.  I wouldn't say "every single 
user"  have the same behavior of being list members but most people do 
travel, and may use different IP devices with POP3/IMAP/SMTP.

With SPF, you still have almost all the very large "public service" 
domains such hotmail.com, yahoo.com, aol.com, msn.com, etc, who have 
not yet figured out their "SPF network" in order to be very restrictive.

If any of these domains, all of a sudden, turned on the -ALL rejection 
switch, oh my, we will see a tremendous amount of complaining as well.

For the domains that have locked it down with the hard fail, -ALL 
policy, they have made a very strong public DNS statement about 
limiting who can send mail on their behalf, just like Yahoo.com did 
with DMARC who is now telling the world via their SPF and DMARC policies:

     I don't know from where my yahoo.com are sending mail from,
     but I want to tell you, they all must be signed exclusively
     by yahoo.com

Yes, these are very much the same problem and I don't believe its 
right to be demoting technically sound protocols for the same 
"registration' problem that SPF still has with a long term prospect 
for collecting the network of machines in order to be able to publish 
restrictive policies.

We have two basic technical proposals.

The first one, the DNS CALL method, I view, as the absolutely 
baseline, proof of concept method. It will work, we know it.  Its 
already in practice. Just put the data there and it will work if you 
add the logic to your policy check. This follows RFC5585 DKIM Service 
Overview guidelines.

The 2nd one, has the same 3rd party signer authorization purpose, but 
has more work with required changed DKIM code. It uses an in-band 
double signature method.  It is theoretically less secure, but the 
theory here is that the signer will have a basic idea of the list 
domains to passively register via the message -- a unknown 
registration problem, perhaps a little less because it seemingly 
bypasses getting the DNS administrator and DNS network department 
involved.

The proper engineering compromising solution SHOULD be to offer both.

The idea of having a SAM or Signature Authorization Method or as Doug 
calls it "Specific Advisory Method" tag in DMARC, is a sound technical 
IETF way of resolving this problem that is agnostic to all parties.

   sam=tpa      use a third party DNS lookup method
   sam=levine   use levine's double signature idea

Personally, I would use the DNS method only because its cheaper to get 
to this planet, but if we really think the levine bypass will work as 
well, add it too.

I am just saying lets not lump everyone into the same DNS 
publishing/registration problem the hotmail.com, yahoo.com, aol.com, 
msn.com domains have.  Others will not.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 6 May 2015 13:44:54 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Stephen J.
> Turnbull
> Sent: Wednesday, May 06, 2015 4:23 AM
> To: Scott Kitterman
> Cc: [email-masked]
> It never will.  (BTW, it's List-Post that's relevant.)  It's the subscriber's action
> of posting to the list that enables the bypass.
> That means that a successful attack of the kind that triggered the April Fiasco
> requires an iterated phish: first you have to phish *me* to post to your list,
> then you need to modify my post to phish *Murray*.
> 

One that comes to mind immediately is compromise existing  list(s) (MLM) used by target audience and then modify posts as desired. It may be that the modification would be for only one or a few recipients. 

 I'm sure there are other mechanisms if a little thought is put into it.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 May 2015 11:13:37 -0700

>  I'm sure there are other mechanisms if a little thought is put into it.
Dear Mike,

Any mail sent from a DMARC domain where content is not
vetted can serve to phish anyone.  Remember, DKIM does not
constrain the number of replays or who are the eventual
recipients.  A phishing risk primarily relates to visual
appearances.

As such, typical appearances gives most mailing-lists that
are not DMARC compatible high marks by tagging the Subject
header field and adding headers or footers.

The real problem in using double signature schemes is expiry
will be long enough to support significantly large campaigns
that can't be stopped even after being detected unless DKIM
signatures are pulled.  Then of course, this creates nasty
DNS handling issues and potentially high levels of
collateral damage.

At least with TPA-Label, the DMARC domain remains in control
using fairly static TPA-Label zones.  The TPA-Label zone can
be separate from the zones used for everything else by the
DMARC domain which can act as a natural source for domain
reputation managed directly or indirectly by the sending
domain.  You'd be amazed how little resources this strategy
requires.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 May 2015 14:51:36 -0400

> DNS handling issues and potentially high levels of

I think you are overstating this. Remember, there are DDoS and load 
controls already in place.  DKIM will not exert any more pressure on 
DNS that already exist.   We are also very comfortable with the 
resilience of DNS software, advanced caching methods, and higher, 
lower cost, powered machines allowing us to scale up, rather than 
scale out.

The real problem with double signatures is that is more additional 
coding work is required and there are too many design assumption ifs 
making it inherently more complex and higher barrier to adoption 
compared to the baseline, simpler DNS call method.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 May 2015 13:45:57 -0700

On 5/6/15 11:51 AM, Hector Santos wrote:
> I think you are overstating this. Remember, there are DDoS
> and load controls already in place.  DKIM will not exert
> any more pressure on DNS that already exist.   We are also
> very comfortable with the resilience of DNS software,
> advanced caching methods, and higher, lower cost, powered
> machines allowing us to scale up, rather than scale out.
>
> The real problem with double signatures is that is more
> additional coding work is required and there are too many
> design assumption ifs making it inherently more complex
> and higher barrier to adoption compared to the baseline,
> simpler DNS call method.

Dear Hector,

Defending against DDoS is very difficult, but that was not
the concern.  Collateral damage would be of legitimate
messages inadvertently blocked when removing a common DKIM
signature.  There is also the challenge of managing a
double-signature re-signing process where it must be assumed
not all destinations receive a signature delegation.  Even
this double signing process may prove problematic when it
goes beyond SQL query rates.  There is also another concern
regarding any phishing campaign permitted by effectively
signing unknown content.  Only by removing DKIM signatures
from DNS would a DMARC domain be able to squelch a phishing
attack it inadvertently authorized.  TPA-Label allows
authorization removal to be based on the destination domain
and even a specific list-id.  TPA-Label would not impact any
existing DKIM signing process since authorization by
destination is managed by TPA-Label zones.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 07 May 2015 14:53:06 +0900

Scott Kitterman writes:

 > TPA requires cooperation from originators and receivers, so there's
 > no "new" issue.  Any make a list approach that needs both
 > originators and receivers to participate needs to work for both
 > large/small originators/receivers and I don't think this does.

"Sez you", but I don't see a rationale for "not work" that actually
addresses the intended use case.

In fact, what's required for making a list is Mediators (mailing
lists) that use the List-Post field.  A very large proportion of those
that allow open (or subscriber) posting do provide that already, and
at least for Mailman lists it's trivial to turn them on.  So only the
Author Domain (and perhaps its users) need participate to make the
list.

To use the list, the Author Domain needs to produce "delegation
signatures", and recipients need to process those signatures.
Implementation is hardly high cost.  Large domains can generally
afford the cost of revising their custom MTAs.  Many small domains
will be using Exim, Sendmail, or Postfix, and the latter two implement
the milter protocol so a software upgrade isn't necessary, and Exim
can be configured to call out to another program, too, so it might
need a separate implementation, but it would be do-able without
upgrading the MTA.  A gradual rollout therefore is quite feasible.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 07 May 2015 15:46:02 +0900

MH Michael Hammer (5304) writes:

 > One that comes to mind immediately is compromise existing list(s)
 > (MLM) used by target audience and then modify posts as desired. It
 > may be that the modification would be for only one or a few
 > recipients.

This has nothing to do with the registration issue.  It's about the
delegation protocols themselves.

That said, sure -- that's an obvious threat for the delegation
protocols, and it applies to other registration schemes, including
"manual" ones like Otis's tpa-labels, too.  But is it worth the
spammer's while?

First, note that we're assuming the spammers really want to send
"from" p=reject Author Domains.  Otherwise, why bother with suborning
the mailing lists?  If you can send apparently-from a p=none domain,
delegation simply doesn't matter, because even DMARC itself doesn't
come into play.  I suppose one reason is that they have contact lists
from the Author Domains in question.  Are these still effective?

Next, there is a small number of lists (60,000 or so).[1]  What is
the probability that you get a "large" intersection of contact lists
with subscriber lists?  Spammers think in terms of "shots" of
*millions*; they need to be able to put out 20 recipients per list
even if they compromise *all* of those lists, just to make their first
million.  Of course, maybe they just want to broadcast to the whole
list "from" a p=reject domain address, but that makes the campaign all
the more obvious.

Is all that really worth it to a spammer, given that such a campaign
would be noticed quickly, and delegation authority withdrawn from the
Author Domains' MTAs?

It all comes down to how p=reject Author Domains perceive the risk of
abuse vs. the benefit to their mailbox users of being able to post to
mailing lists without having their posts from-munged or wrapped.  I
think it's worth laying out the threat models we can think of for
them, but in the end they decide.

 >  I'm sure there are other mechanisms if a little thought is put

Of course.  As long as email as we know it exists, there will be (and
most won't involve Mediators at all!)

But the real question is can we lock things down enough to make
spamming and phishing unprofitable?

Footnotes: 
[1]  I suspect that the ones that contain large numbers of p=reject
posters are already under attack for this purpose, presumably
unsuccessfully.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 07:48:54 -0400

> upgrading the MTA.  A gradual rollout therefore is quite feasible.

I agree with all that, but I think it's irrelevant.

I publish p=none because I don't want to have problems participating in 
mailing lists.  I've published SPF -all since 2004 and have no trouble with 
some small cost associated with email authentication, but DMARC is different.

I took a quick look at the last week's worth of data for my domain and mail 
sent through ietf.org.  Each mail I send to an IETF list turns into about 25 
messages reported in DMARC feedback data.  They are all DMARC fail due either 
to lack of alignment or failed DKIM signatures.  Roughly 80% of those reports 
are from Google, Yahoo!, and Microsoft.

I don't see any evidence that any large operators such as this are willing to 
sign up for an approach like this, but let's imagine everyone else does 
because it's "easy".  Then instead of 100% of my IETF list mail failing DMARC, 
80% fails.

Is 20% success sufficient for me to switch to p=reject?  I guarantee you it is 
not.  At the end of the day, without the large providers on board, any 
solution that requires change at both the sender and the receiver needs the 
large providers on board or it's useless.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 08:18:57 -0400

> signatures", and recipients need to process those signatures.

How about the MLM receiver, will it filter the fraud?  Will it remove 
the restrictive domains that do not want any 3rd party resigners? 
Will you respect and honor the exclusive, restrictive policies?

> Implementation is hardly high cost.

"Sez you"

> Large domains can generally afford the cost of revising their
> custom MTAs.

That doesn't mean will they alter their code especially when don't 
have to address the resigner issue.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 7 May 2015 11:29:01 -0400

> On May 6, 2015, at 4:45 PM, Douglas Otis <[email-masked]> wrote:
> 
> 
> signature.

What do you mean by remove?  You mean destroy, invalidate existing signatures?

Keep in mind this MAY be desirable, in fact the DKIM STD76 theory is that resigners can occur blindly anywhere with the mail path.  You don't have destroy the original integrity during resign,  yet that transaction may be illegal (per policy) with the fact it has ben resigned.

> There is also the challenge of managing a
> goes beyond SQL query rates.  

SQL? <g>. Some folks are more optimized using ISAM/BTREE databases! 

> There is also another concern

Doug,  we know a positive result of a DNS lookup will work.  I believe you wish to add more complex semantics on the parsing of the lookup results,  I believe that's ok. But we need a basic yes/no query.   Maybe it can be sold if we offer more bang for the buck on each call but overall, it needs to be very simple.  

--
Hector Santos
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 May 2015 15:12:16 -0700

On 5/7/15 8:29 AM, Hector Santos wrote:
>> Defending against DDoS is very difficult, but that was
not the
>> concern.  Collateral damage would be of legitimate messages
>> inadvertently blocked when removing a common DKIM signature.
>
> What do you mean by remove?  You mean destroy, invalidate
existing
> signatures?

Removing signature information from DNS prevents an
associated signature to validate as a feckless means to
respond to signature delegation chain abuse.

> Keep in mind this MAY be desirable, in fact the DKIM STD76 theory is
> that resigners can occur blindly anywhere with the mail path.  You
> don't have destroy the original integrity during resign, 
yet that
> transaction may be illegal (per policy) with the fact it
has been
> resigned.

The concern relates to "delegating" with a DKIM signature
fragment, where, when valid, authorizes signatures of a
third-party.  Even a "short" expiry likely covers several
days or delivery may become fragile. It seems any delivery
period would permit a sizable phishing campaign well beyond
the control of a DMARC domain.  TPA-Label provides a method
to react to abuse while also minimizing collateral damage to
other message streams that utilized the same DNS resources
for their DKIM signatures.  Of course TPA-Label could impose
a similar list of no-change headers as found in a DKIM
signature delegation.  By leveraging a DKIM process, perhaps
you might see that as simpler and offering more bang for the
buck.

>> There is also the challenge of managing a double-signature
>> re-signing process where it must be assumed not all
destinations
>> receive a signature delegation.  Even this double signing
process
>> may prove problematic when it goes beyond SQL query rates.
>

Any interim per message special signing process is likely to
encounter scaling issues especially when third-parties are
handling tens of thousands of first party domains.  Again,
the TPA-Label approach does not introduce new signatures nor
alter DKIM signature processing. It simply offers low
frequency exceptions based on an asserted relationship
between the From and third-party domain that can be
instantly withdrawn by the From domain upon the detection of
abuse.

>> There is also another concern regarding any phishing campaign
>> permitted by effectively signing unknown content.  Only
by removing
>> DKIM signatures from DNS would a DMARC domain be able to
squelch a
>> phishing attack it inadvertently authorized.  TPA-Label
allows
>> authorization removal to be based on the destination
domain and
>> even a specific list-id.  TPA-Label would not impact any
existing
>> DKIM signing process since authorization by destination
is managed
>> by TPA-Label zones.
>
> Doug, we know a positive result of a DNS lookup will work. I
> believe you wish to add more complex semantics on the
parsing of
> the lookup results, I believe that's ok. But we need a
basic yes/no
> query. Maybe it can be sold if we offer more bang for the
buck on
> each call but overall, it needs to be very simple.

TPA-Label is simpler because it does not require third-party
processes to be interspersed between each step of message
handling.  It involves only sender assertions and recipient
exceptions.  Instances requiring a reaction respond to abuse
which TPA-Label can handle both promptly and with minimal
collateral disruption.

BTW, SPF -all was seldom used since it offered >1% false
positive rates and with DMARC, it is even best considered
~all to allow DKIM a chance to rescue messages from
rejection or spam folder placement.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 08 May 2015 07:59:06 +0900

> large providers on board or it's useless.

Which is where I started, but then I was told mentioning names isn't
allowed.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 08 May 2015 08:30:32 +0900

Hector Santos writes:

 > How about the MLM receiver, will it filter the fraud?

Why wouldn't it?  All do (at least, anybody who hopes to deliver to
the large providers does).

 > Will it remove the restrictive domains that do not want any 3rd
 > party resigners?

No.  Such domains simply don't participate in delegation protocols.
If, furthermore, they want to restrict their users from posting, they
should do so.  I suppose domains participating in the DMARC protocol
have the information needed to detect violations by their users.  MLs
don't have that information.

In any case, AFAICT, the p=reject domains that originate 99% of list
posts covered by p=reject are not restrictive in that sense -- they do
permit their users to post, and are pleased when their users' posts
are distributed by mailing lists.

 > Will you respect and honor the exclusive, restrictive policies?

If you mean rejecting when p=reject and From alignment fails at
receipt, yes.

If you mean guessing what the Author Domain intends on resent mail
where behavior is not specified by protocol, that's up to the ML
admin.  I expect almost all will engage in mitigation rather than
preemptively reject.  Again, it's the Author Domain's responsibility to
set policy for its users, and DMARC participating Author Domains do
have the information needed to enforce such policy, I suppose.  The ML
does not.

 > > Implementation is hardly high cost.

Sure, but I also explained what I think the required resources are.
If you think that's costly, well, "YMMV" always applies to such
opinions.

 > have to address the resigner issue.

t also doesn't mean they won't.

But if there is no protocol for resigning, we can be sure they won't.

Steve

---

From: Terry Zink <[email-masked]>
Date: Fri, 8 May 2015 00:15:55 +0000

> Roughly 80% of those reports are from Google, Yahoo!, and Microsoft.
>

And from Murray:

> There's still that pesky registration problem to address.

Checking DNS for third party authorization may be workaround for this problem at a large provider (Microsoft) but publishing them on behalf of Microsoft would be a tough (probably impossible) sell. If I own my own domain, I can keep track of mailing lists for a few dozen users. But something like outlook.com has millions of years. The registration problem means that either we have to review hundreds or thousands of additions per day (or a bootstrap of tens of thousands) or automate it. But if we automate it, that has its own problems:

- What's the threat model? How do we prevent malicious sign ups?
- The outlook.com sign-up is self-serve; this means that anyone can sign-up for outlook.com and create their own mailing lists and subscribe to it, and then outlook.com would need to automatically add that to its DNS zone. In other words, a complete outsider can register something in the zone that is maintained by Microsoft. This can be abused (a spammer could blow up the zone by doing this tens or millions of times per day using a botnet).
- When do we remove things from DNS?

That's a big risk. I can't speak for the company, but I think we'd rather live with the DMARC p=reject inconvenience than allow a regular user to publish anything to its DNS zone.

-- Terry

---

From: Terry Zink <[email-masked]>
Date: Fri, 8 May 2015 00:17:21 +0000

> has millions of years

Er, millions of users.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Thursday, May 7, 2015 5:16 PM
To: Scott Kitterman; [email-masked]
Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

-- Terry

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 May 2015 21:03:16 -0700

On 5/7/15 5:15 PM, Terry Zink wrote:
> Checking DNS for third party authorization may be workaround for this problem at a large provider (Microsoft) but publishing them on behalf of Microsoft would be a tough (probably impossible) sell. If I own my own domain, I can keep track of mailing lists for a few dozen users. But something like outlook.com has millions of [users]. The registration problem means that either we have to review hundreds or thousands of additions per day (or a bootstrap of tens of thousands) or automate it. But if we automate it, that has its own problems:
>
Dear Terry,

Many third-party services now munge who authored a message
to sidestep inappropriate DMARC restrictive policies.  When
a DMARC domain can't conclude which third-party services
employed by their users aren't causing any phishing threats
when they have the benefit of DMARC feedback, outgoing logs,
and a sizable spam trap infrastructure, their lack of effort
creates a dangerous situation. 

DMARC now means people have less ability to communicate
effectively using third-party services.  Some receiving ESPs
mitigate some of their complaints by changing "reject" to
"quarantine".  Looking into a spam folder is likely to
reveal rather nasty malware looking like messages unfairly
rejected due to inappropriate DMARC assertions.

There are some choices that should help make the situation
better.

1) define reasonable fallback profiles for ESPs who
miss-apply restrictive DMARC policy to permit acceptance
based on a validated Sender header field clearly shown to users.

2) define a replacement From header field. The example I
gave included a field to track current resources when
conveyed over a channel that normally handles IM as well as
having a group friendly display to play the role of Subject
Tag.

3) We have had experience providing almost exactly what
would be needed to support a TPA-Label lists.  We tracked
behaviors of all known mailing-lists, differentiated those
from bulk senders, news feeds on behalf of  friends, etc. 
While you may have millions of users, the number of
third-party services in use is much much less.  I am
convinced doing a good job at simply applying the
information known by the DMARC domain would allow all
headers to be safely used by email while at the same time
making mail safer.  If you are interested, perhaps we could
get together to demonstrate how the feedback can be
automated and managed.  Doing this while at the same time
guarding access to user accounts should attract happy and
even paying customers.

I am not a fan of ATPS.  IMHO nothing justifies a special
DKIM signature, changes to Authentication headers or
optional hashes for labels.  How in the heck would a
third-party keep track of which hash is needed?  The reasons
claimed for using special DKIM signatures can be replaced by
simple DMARC assertions to indicate which conventions are
adopted.  There would not be any increased DDoS risk nor a
need to have everyone change how DKIM is used.  But of
course, people want to leave their 'd' mark:^)

Regards,
Douglas Otis