Subject: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

From: Dave Crocker <[email-masked]>
Date: Fri, 15 May 2015 13:28:44 -0700

G'day.

In looking for ways to make a DMARC-style function succeed when the
message transits an intermediary, the current approach has mostly been
proposing one or another wholesale solution.  This creates a complex
space for discussion and tends towards some version of deadly embrace.

It might be helpful to consider /basic types/ of changes that are
reasonable/unreasonable for intermediaries, distinct from how they might
fit into an entire solution.

Reasonable vs. unreasonable pertain to at least two axes:

     1. Amount of work

     2. Policy/Principle

Some choices entail too much work or run afoul of basic operational
policies.  Others might entail some work, but not too much, and might
not be considered as significant violations of established policies.

Here be dragons, of course, but let's try to have the discussion anyhow.

Obviously, there will not be unanimity among all intermediaries, for any
proposal.  So the question really is about plausible rough consensus
among a 'substantial' amount of the community.

The first question is:  what are the 'types' of changes that have been
or might be proposed?  This should turn into some sort of taxonomy,
eventually, but for now an undisciplined core dump(*) of choices would
be best.

Examples:

   Modifying the rfc5322.From display-name

   Modifying the rfc5322.From address

   Modifying the footer of the message body (first body-part.)

   Modifying the rfc5322.Subject preface

   Performing DMARC validation upon receipt

   Performing DKIM/SPF validation upon receipt

   DKIM-signing all outbound mail.

   Registering the intermediary with all potential sites posting to it

   Registering the intermediary with all potential sites receiving from
   it

Your turn...

d/

(*) it occurs to me that the term might now be archaic, since 'core'
hasn't been used in quite a long time.  if so, i guess 'memory dump'
would be the term?

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 18:41:56 -0400

Dave,

You should give DMARC+ATPSrev4 a shot. It works great.  No change to 
any DKIM engine is required as the ATPS-RFC6541 version requires.  It 
was relatively simple to migrate from ADSP+ATPSrev4 to DMARC+ATPSrev4. 
Take the same existing code and swap with it with DMARC.   We need to 
keep in mind that ADSP was made historic and replaced with DMARC 
referenced as the "Super ADSP" version.  So it should of been 
documented with migration and implementation semantics.  There are 
still ADSP processors and there are still ADSP published domains, for 
example, paypal.com.   But I don't wish to make two calls. ADSP needs 
to be deprecated if we are going to use DMARC. Since DMARC is selected 
to replaced ADSP, we should make ATPSrev4 piggy back off DMARC now.

Once the mechanics are in place, then we can adequately begin to 
explore the adoption and its barriers.

I believe we will see either a short or even long term 
migration/adoption as it was with SPF.  Not everyone could use SPF in 
the same way not all domain will be able to use DMARC and/or ATPSrev4.

Thanks

-- 
HLS

---

From: Terry Zink <[email-masked]>
Date: Sat, 16 May 2015 00:09:29 +0000

Hector,

> You should give DMARC+ATPSrev4 a shot. It works great.

My perception of your +1 to your solution is this: "I run my own mail server and moderate my own DNS zone. I have a couple of users on my domain. Everything works so easy."

Yet you then admit:

> not all domains will be able to use DMARC and/or ATPSrev4.

The "not all domains" who won't use this will be large senders and receivers who account for the majority of phishing targets and email receivers. And if you haven't solved it for the majority of phishing targets and potential victims, how can you call this a solution? At best, it's having done something interesting and a self-pat-on-the-back, but most of the problem is not solved. And if most of the problem is not solved nor will be, why pursue it?

How do you get around this? Who do you expect to implement it?

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Friday, May 15, 2015 3:42 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

Dave,

Thanks

-- 
HLS

> hasn't been used in quite a long time.  if so, i guess 'memory dump'

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 20:59:40 -0400

> On May 15, 2015, at 8:09 PM, Terry Zink <[email-masked]> wrote:
> 
> Hector,
> 

I suppose you never heard of Wildcat!?   While mail is only a small part of our integrated hosting products, a huge investment was made to add DKIM+ADSP+ATPSrev4 for our product line.   ADSP was an IETF proposed standard.[*]  It supports a several hundred customers in the field, including MLMs, ESPs, and no so much anymore ISPs. We abandoned our PPP server long ago, but there might be a few still using our RADIUS server.

Our WINServer.com is a support site for our customers.   Yes, we all use the same stuff. So whatever we do, they benefit.  We have a AutoUpdate Plan (AUP) that people paid monthly, quarterly and yearly.  One AUP and customers instantly get updates.  We have to make sure it works out of the box, especially if new stuff is enabled.

[*] DMARC is not a proposed standard.

> How do you get around this? Who do you expect to implement it?

As with most things, it's all optional and the reason why it's optional is because not all can use or benefit from the technology. There are plenty of IETF protocols that are not useful to all and  rarely can't be enforced.  It still applied and used by many anyway.

The only problem here is a registration and I don't buy you say that it's problem for Microsoft.com or anyone else.   This may not be understood but it doesn't say good things for the IETF if it says to the world -- don't bother with future DNS applications any more. No one will publish records.    

At the end of the day, there will be domains that won't be able to use the technology and more than likely hotmail.com won't be able to get their SPF nor their ATPSrev4 network in order. But Microsoft.com and millions of other domains can, and millions more won't need too.

It's a feature, an option.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 May 2015 18:42:46 -0700

> How do you get around this? Who do you expect to implement it?
Dear Terry,

I can't speak for Hector nor would I include ATPS, but a
very small group of us managed this type of feedback largely
operated automatically to deal with mailing-lists, dial-ups,
open-proxies, etc.  Each category triggered different
testing and investigative criteria.  The collected dataset
then applied against inbound email seen by about 70% of the
entire world's email users.  This service was initially free
and pre-built into the various mail programs.  This approach
scales to very high levels while causing very low overhead. 
In contrast,  SPF and reverse look ups represent orders of
magnitude greater overhead.  We handled various European
schools such as Ja.net and even several of the largest ESPs,
some of whom are participating on this list but may not be
aware of our prior involvement.

Beyond just DMARC feedback, protection will require feedback
augmented with mail-traps that are separately available as a
service.  With DMARC forcing all messages to be authorized
in some manner, the type of gaming that can be involved
becomes much easier to exclude.  There is no silver bullet,
but once this type of feedback is instantiated, the abuse
seen by recipients should be greatly reduced with far less
ending up in spam folders. The best part is this can retain
full SMTP compatibility.   As some of the larger DMARC
domains start offering third-party specific feedback, the
value of such authoritative data will be high and should
spur greater adoption.

Regards,
Douglas Otis

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 16 May 2015 08:11:39 -1000

> > On May 15, 2015, at 8:09 PM, Terry Zink <[email-masked]>

With all due respect to the amazing abilities of this list to bikeshed,
could we try to return this particular thread to the question(s) raised by
Dave? To wit:

> fit into an entire solution.

--Kurt Andersen

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 May 2015 15:05:20 -0400

Dave,

In the 2006 DSAP I-D, I wrote down and implemented what I felt were 
reasonable integration changes for our list server package (MLS):

    https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DKIM signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

When it, DKIM+ADSP+ATPSrev4, was finally implemented, very little 
change was done to the MLS itself as long as its entry points did all 
the ADSP (and now DMARC) checking.

It really hasn't deviated other than we are replacing ADSP with DMARC, 
with the same issues, same needs, long worked out.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 May 2015 17:16:56 -0400

>    Registering the intermediary with all potential sites receiving from

Performing prosepective DMARC validation on receipt to determine if mail would 
be subject to p=reject processing on the distant end if reransmited.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 May 2015 12:55:46 -0400

> be subject to p=reject processing on the distant end if reransmited.

Right, controlling the entry points and that can include the 
subscription process.

Take a look at this subscription site for an example of how it works. 
I just updated it for DMARC. Try to subscribe using a restrictive 
domain, like a yahoo.com account:

   http://www.winserver.com/public/code/html-subscribe?list=list-dkim

Note: This is just controlling the manual subscription process.

Lets keep in mind that you can distribute to restrictive domains, its 
the submission that is mostly problematic so there are many 
implementation notes that can be created.  For example, that the MLM 
can automatically make the subscriber a Read Only Member.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 18 May 2015 03:48:58 +0900

Scott Kitterman writes:

 > Performing prosepective DMARC validation on receipt to determine if
 > mail would be subject to p=reject processing on the distant end if
 > reransmited.

I assume you mean "... and prospectively reject"?  (GNU Mailman at
least already provides options to munge From or wrap the message,
conditional on the result of such a test.)

For completeness it should be listed, but practically speaking, for
tens of thousands of lists it just ain't gonna happen, sorry.

The Author Domains that *want* "POLICY" control already have a local
policy in place prohibiting their users from posting to mailing lists
and the like, and are a very small problem because indirect messages
from them are very few.

It's the p=reject abusers that are the problem, but *they* *want*
mailing lists to distribute their users' posts, despite what "POLICY"
advocates claim is implied by publishing p=reject.  Those users *want*
to post, and they blame the *list*, not their mailbox providers, if
anything goes wrong or if their posts are treated differently from
users at other providers.  List owners by and large are not RFC
zealots, quite the reverse, and quickly cave in to the importunate
posters.

Bottom line: The only people who want this policy are some of us in
this working group.  Nobody[1] actually involved does.  Even my
colleagues at GNU Mailman who are sympathetic to the idea of
prospectively doing what the policy requests have found that in
practice it's socially untenable on lists they administer.

Footnotes: 
[1]  Well, I do, but my lists are special cases.  My public lists have
less than 0.5% p=reject subscribers and less than 0.1% posts from
them, so I can tell them where to go, and my university lists are
covered by Japanese Ministry of Education policy deprecating use of
Yahoo! mailboxes (without reference to p=reject and including domains
that publish p=none!)

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 17 May 2015 16:15:04 -0400

>Yahoo! mailboxes (without reference to p=reject and including domains

Dave asked for a comprehensive list, not just a list of ideas that are of general utility. It does solve the problem of others getting bounced off the list due to their ADMD honoring the p=reject, but as you saw wouldn't be acceptable in many cases. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 17 May 2015 21:26:54 -0700

>    Performing DKIM/SPF validation upon receipt

There already exist several implementations of each of these, so I would
say that they are currently deployed rather widely, making our cost
near-zero.  Plus, any DMARC operator already has at least one of them going.

Let's say that's close to zero cost as well.

One thing absent from your list is conditional signatures, which is John's
idea, and is a special case of both of these.  I've implemented it now in
libopendkim as a compile-time experimental feature, and it took me about
four hours including testing.  I just have to add it to the plugin that
uses the library, and it'll be available for others to play with.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 18 May 2015 11:38:51 +0900

Scott Kitterman writes:
 > >For completeness it should be listed,

 > Dave asked for a comprehensive list,

An acknowledgment of that is the first thing I wrote after asking the
qualifying question, as you see.

 > as you saw wouldn't be acceptable in many cases. 

The argument supports a stronger conclusion than that IMHO.  Had there
been a wiki page for this list I wouldn't have posted here, but I'm
new and don't know the procedures for starting a page, and others had
posted to the list -- I just wanted the argument, and the stronger
conclusion, on the record in case I'm not around when the wiki page or
BCP or whatever does get initialized.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 18 May 2015 19:58:03 +0200

On 05/15/2015 10:28 PM, Dave Crocker wrote:
> or might be proposed?

Please define 'changes'. Do you mean: changes which solve the 'p=reject' 
problem for mail that is sent via an intermediary? Or just 'any' changes 
that might help us a fraction to come closer to a solution.
> This should turn into some sort of taxonomy,

+ add an Authentication-Results header.

>     DKIM-signing all outbound mail.

+ include Authentication-Results in the DKIM-signature of the intermediary.

>     Registering the intermediary with all potential sites receiving from

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 May 2015 11:49:23 -0700

On 5/17/15 7:38 PM, Stephen J. Turnbull wrote:
>>>> Performing prosepective DMARC validation on receipt to
>>>> determine if mail would be subject to p=reject
processing on
>>>> the distant end if reransmited.
>>>
>>> I assume you mean "... and prospectively reject"?  (GNU
Mailman
>>> at least already provides options to munge From or wrap the
>>> message, conditional on the result of such a test.)
>>>
> An acknowledgment of that is the first thing I wrote after
asking
> the qualifying question, as you see.
>
> The argument supports a stronger conclusion than that
IMHO.  Had
> there been a wiki page for this list I wouldn't have
posted here, but
> I'm new and don't know the procedures for starting a page,
and others
> had posted to the list -- I just wanted the argument, and the
> stronger conclusion, on the record in case I'm not around
when the
> wiki page or BCP or whatever does get initialized.

Dear Stephen,

Wiki is fine, but traditionally anything somewhat involved
should be published in the form of an Internet Draft. 
Reasonable tools are available.

https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4

Describes fairly easy approaches that require increasing
cooperation from larger providers.

1) Conditionally permit Sender header field alignment

This could be defined as a "public" policy that indicates as
result of use of public mailing lists and general email use,
the domain needs to allow alignment with the Sender header
field.  By having handling defined in such a case, it would
allow recipients a safer way to override otherwise
disruptive policies causing message being munged or placed
into spam folders.

2) Define a replacement Author header

This would better ensure email interchange rather than
placing author roles into various ad hoc locations.

3) Third-Party Authorization

Perhaps the effect made by option 1 or 2 may pressure
providers into offering information that ONLY they have on
behalf of their recipients.  Such information would allow
more effective and safer handling to deal of third-party
sources where legitimate messages are likely disrupted with
the effect of preventing open discussions with known authors.

The Selection of which message are to receive a message
siglet to authorize a third party domain could be
accomplished using various DKIM siglets, but will require
greater handling overhead and will be far less responsive
when abuse is subsequently detected.   Once the issue of
overhead and responding to abuse are carefully considered,
the general approach outline in
https://tools.ietf.org/html/draft-otis-tpa-label-07 might be
reconsidered.

TPA-Label could even become a hybrid of
https://tools.ietf.org/html/draft-levine-dkim-conditional-01
where initial signatures are confirmed by the
https://tools.ietf.org/html/rfc6376 by using forensics base
on the bh= and z= tag with an additional tag that indicates
predefined sets of headers that must remain unchanged as
well as a list of domains that may reintroduce signed
messages. When an intermediary is authorized, an expanded
authentication results header might prove simpler than using
forensics.  Either way, a hybrid approach would need less
specified within TPA-Label resource records and still be
able to retract specific authorizations that have gone bad. 
The hybrid approach would also help facilitate which
outbound messages should receive the message siglets and
which domains are authorized to re-sign on behalf of the
DMARC domain.

Various encapsulation scheme seem fairly risky since they
allow unseen content to reconstruct messages that otherwise
fail validation and will generally make email more confusing.

Both encapsulation and DKIM siglets will allow wide-open
abuse (abuse beyond the control of the DMARC domain).

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 00:36:34 +0000

> I've implemented it now in libopendkim as a compile-time experimental feature,
> and it took me about four hours including testing.  I just have to add it to the plugin
> that uses the library, and it'll be available for others to play with.

Can you give an example of what the stamped headers will look like?

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Sunday, May 17, 2015 9:27 PM
To: Dave Crocker
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

On Fri, May 15, 2015 at 1:28 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:
   Performing DKIM/SPF validation upon receipt

There already exist several implementations of each of these, so I would say that they are currently deployed rather widely, making our cost near-zero.  Plus, any DMARC operator already has at least one of them going.
   DKIM-signing all outbound mail.

Let's say that's close to zero cost as well.
One thing absent from your list is conditional signatures, which is John's idea, and is a special case of both of these.  I've implemented it now in libopendkim as a compile-time experimental feature, and it took me about four hours including testing.  I just have to add it to the plugin that uses the library, and it'll be available for others to play with.
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 May 2015 18:18:16 -0700

> Can you give an example of what the stamped headers will look like?

Ideally on receipt by a list subscriber, the message would have the
following DKIM signatures:

DKIM-Signature: v=1; d=authordomain.example; s=selector; ...
DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example;
l=0; ...
DKIM-Signature: v=1; d=mlm.example; s=foobar; ...

Things of note:

1) I changed "@fs" to "!cd" versus what John specified.  I prefer "!"
because we're calling that a "mandatory tag", and "cd" stands for
"conditional domain" rather than "forward signature".  Mostly personal
preference, but I'd argue they're more correct (for some value thereof);
I'll change them to wherever consensus lands if we decide we want to adopt
this proposal.

2) I understand there's unresolved debate about updating "v=".  I'll
conform to that too when we make a decision.

3) The choice to do a weak signature using "l=0" was merely exemplary.
There are other choices, like which header fields to sign or use of
"l=<original-length>", that can result in something weaker without being
that wide open.

4) Similarly, I didn't set an expiration on the !cd signature, but should.

5) I've actually listed the signatures above in the opposite order I'd
expect to see them on receipt.

6) The theory is that even if the author signature fails, the conditional
author signature would be more likely to pass but is not valid without the
MLM signature.  libopendkim would report this to the caller as valid in the
crytpo sense, but also note that the condition was not satisfied, so
there's an error code associated with it.

7) Ultimately the caller sees all three signatures and their respective
results.  If the original author signature survived, it's available to
influence message disposition as well as the others.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 May 2015 20:42:44 -0700

> I'll change them to wherever consensus lands if we decide we want to adopt
Dear Murray,

Termnology:
 DKIM Siglet is a highly constrained DKIM signature omitting
elements likely altered by a mediator.

Have you given any thought about how inclusion of a siglet
containing !cd=random.example.com is regimented? 
Regimentation can use ram based DNS in a fashion that
benefits MTAs adding the siglet and those deciding whether
to add the siglet by using unique labels to facilitate
retraction of undesired authorization.  SHA-1 received its
share of Intel's attention.
https://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1 
This paper gives a better overview than the code added to
the TPA-Label draft and illustrates a much faster approach. 
Faster than using any sort of disk access where a publisher
handles collisions. This also provides consistent label
sizes, minimal cache consumption and look up overhead.
> "l=<original-length>", that can result in something weaker without being
Once again, the siglet regimentation can also serve the
function of retracting authorizations when needed.  Without
this ability, there is little to discourage rampant abuse.
> 4) Similarly, I didn't set an expiration on the !cd signature, but should.
No matter how short an expiry is set, botnets will still be
able to leverage anything that gets signed beyond the DMARC
domain's control.  A few episodes of a botnet leveraging
this weakness seems more than likely to justify abandoning
the approach putting the effort back to where it started.
> there's an error code associated with it.
The author signature has an error code?  Yikes.
> influence message disposition as well as the others.
If the original Author signature survives, the DKIM siglet
should be ignored.  If there is no DKIM siglet error, and
the !CD signature (DKIM siglet authorized signature) is
valid, what is to be assumed by the error you noted?  What
am I missing?

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 05:56:44 +0000

Thanks, this is useful.

What would the Authentication-Results header look like? Presumably 3 results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC? Show one result or two? Or maybe something like dmarc=conditionalpass?

-- Terry

________________________________
From: Murray S. Kucherawy <[email-masked]>
Sent: Monday, May 18, 2015 6:18 PM
To: Terry Zink
Cc: Dave Crocker; [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

Ideally on receipt by a list subscriber, the message would have the following DKIM signatures:

Things of note:

1) I changed "@fs" to "!cd" versus what John specified.  I prefer "!" because we're calling that a "mandatory tag", and "cd" stands for "conditional domain" rather than "forward signature".  Mostly personal preference, but I'd argue they're more correct (for some value thereof); I'll change them to wherever consensus lands if we decide we want to adopt this proposal.

2) I understand there's unresolved debate about updating "v=".  I'll conform to that too when we make a decision.

3) The choice to do a weak signature using "l=0" was merely exemplary.  There are other choices, like which header fields to sign or use of "l=<original-length>", that can result in something weaker without being that wide open.

5) I've actually listed the signatures above in the opposite order I'd expect to see them on receipt.

6) The theory is that even if the author signature fails, the conditional author signature would be more likely to pass but is not valid without the MLM signature.  libopendkim would report this to the caller as valid in the crytpo sense, but also note that the condition was not satisfied, so there's an error code associated with it.

7) Ultimately the caller sees all three signatures and their respective results.  If the original author signature survived, it's available to influence message disposition as well as the others.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 May 2015 23:05:18 -0700

On Mon, May 18, 2015 at 10:56 PM, Terry Zink <[email-masked]>
wrote:

>  Thanks, this is useful.
>
> What would the Authentication-Results header look like? Presumably 3
> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC?
> Show one result or two? Or maybe something like dmarc=conditionalpass?
>
Three DKIM results, one DMARC "pass" result.  The idea is that DKIM returns
a "pass" for an aligned conditional signature, which satisfies the DKIM
algorithm, so long as there's also a passing signature from the "cd" domain.

Is there any use in making a distinction to your acceptance/routing of
messages to know it was based on a conditional signature versus an original
author signature?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 May 2015 23:09:51 -0700

> that might help us a fraction to come closer to a solution.

I meant things pretty generally, for this stage of the discussion.  So I
think 'any' changes that might help us a fraction.

Basically, we need to develop some guidance for anyone suggesting an
overall set of improvements.  They need to have a way of assessing the
likelihood that particular changes at the intermediary are or are not
even worth discussing.

Whether a particular proposal will entail enough benefit overall and
small enough disruption or effort at the intermediary is a different matter.

By way of example:  Getting intermediaries to pay attention to dkim and
spf validation is probably an easier step.  However getting them all to
use exactly the same wonderful MLM software that mailbox providers
consider the very best for anti-spam, is probably in the realm of
impossible.  (And given the weaknesses of monocultures, it's also a
terrible idea...)

d/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 19 May 2015 07:47:23 -0400

>messages to know it was based on a conditional signature versus an

I would think you'd have to. There's a replay risk that's unique to this type of signature, so I think treating them the same would be a naive approach. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 06:31:18 -0700

On Tue, May 19, 2015 at 4:47 AM, Scott Kitterman <[email-masked]>
wrote:

> I would think you'd have to. There's a replay risk that's unique to this
> type of signature, so I think treating them the same would be a naive
> approach.
>

But is that something that an agent downstream of a verifier needs to know?

A-R for SPF doesn't differentiate between "-all" and "~all", for example,
nor does it relate key sizes or header field selection from DKIM.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 16:19:39 +0000

>> I would think you'd have to. There's a replay risk that's unique to this type of
>> signature, so I think treating them the same would be a naive approach.

> A-R for SPF doesn't differentiate between "-all" and "~all", for example, nor
> does it relate key sizes or header field selection from DKIM.
It’s useful for debugging afterwards. Someone, somewhere, will send me a sample message that passed DMARC when it shouldn’t have (but in reality passed because of a conditional DKIM) and it’s useful to have this in the results.

A-R for SPF doesn’t matter for ~all and –all because the IP is found within the SPF record. DKIM for key size doesn’t matter because a weak key is ignored. I think conditional DMARC does matter because there’s still a small time window where the original message/author is vulnerable to a replay attack, and a conditional DMARC pass is almost, but not quite as strong as a regular DMARC pass.

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 19, 2015 6:31 AM
To: Scott Kitterman
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

But is that something that an agent downstream of a verifier needs to know?
A-R for SPF doesn't differentiate between "-all" and "~all", for example, nor does it relate key sizes or header field selection from DKIM.
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 10:56:09 -0700

On Tue, May 19, 2015 at 9:19 AM, Terry Zink <[email-masked]>
wrote:

> It’s useful for debugging afterwards. Someone, somewhere, will send me a
> sample message that passed DMARC when it shouldn’t have (but in reality
> passed because of a conditional DKIM) and it’s useful to have this in the
> results.
>

Sure, but can it just be in a comment if you find that useful, or is it
necessary to make that fact something a consumer of the field can parse out?

The idea behind A-R all along has been to be able to say "method X
passed/failed/whatever for this message, and the things it authenticated
are A and B".  I've always found the details of how it came to that
conclusion to be of only secondary interest because:

a) They might no longer be true at the time an MUA processes that header
field; this is supposed to reflect what the ingress MTA saw.

b) The goal is specifically not to allow MUAs or downstream agents to
repeat the authentications done at the ingress MTA, otherwise why bother
having the border MTA do it?  There's also a DDoS possibility if every MUA
or downstream agent repeats checks.

c) Having to keep all the MUAs current on message authentication techniques
is a much bigger burden than just updating ingress MTAs, so that model is
observed.

See RFC7001, Appendix D, for details.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 18:24:35 +0000

> Sure, but can it just be in a comment if you find that useful, or is it necessary to
> make that fact something a consumer of the field can parse out?
Putting it into a comment is fine, maybe something like “dmarc=pass action=none header.from=<domain.com> conditional.to=<mailinglist.net>”. I think it’s permissible to add additional fields like that into A-R, isn’t it?

> I've always found the details of how it came to that conclusion to be of only secondary interest

I agree with the reasons you outline, but when debugging and troubleshooting potentially tens, hundreds, or thousands of messages per day, it’s no longer secondary. It’s also easier to collect statistics on how many messages are conditionally passing DMARC and what mailing list or forwarder it is attached to.

-- Terry

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Tuesday, May 19, 2015 10:56 AM
To: Terry Zink
Cc: Scott Kitterman; [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

Sure, but can it just be in a comment if you find that useful, or is it necessary to make that fact something a consumer of the field can parse out?
The idea behind A-R all along has been to be able to say "method X passed/failed/whatever for this message, and the things it authenticated are A and B".  I've always found the details of how it came to that conclusion to be of only secondary interest because:
a) They might no longer be true at the time an MUA processes that header field; this is supposed to reflect what the ingress MTA saw.
b) The goal is specifically not to allow MUAs or downstream agents to repeat the authentications done at the ingress MTA, otherwise why bother having the border MTA do it?  There's also a DDoS possibility if every MUA or downstream agent repeats checks.
c) Having to keep all the MUAs current on message authentication techniques is a much bigger burden than just updating ingress MTAs, so that model is observed.
See RFC7001, Appendix D, for details.
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 11:39:20 -0700

On Tue, May 19, 2015 at 11:24 AM, Terry Zink <[email-masked]>
wrote:

> Putting it into a comment is fine, maybe something like “dmarc=pass
> action=none header.from=<domain.com> conditional.to=<mailinglist.net>”. I
> think it’s permissible to add additional fields like that into A-R, isn’t
> it?
>

More like:

dmarc=pass header.from=<domain> (action=<foo>, cd=<domain2>)

> I agree with the reasons you outline, but when debugging and
> troubleshooting potentially tens, hundreds, or thousands of messages per
> day, it’s no longer secondary. It’s also easier to collect statistics on
> how many messages are conditionally passing DMARC and what mailing list or
> forwarder it is attached to.
>

You can create whatever structure you want in the comment (between
parentheses).

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 19:00:55 +0000

I think we’re making progress here. So, a message would look like this:

From: [email-masked]
Some questions:

1.       This should be resistant to a replay attack 12 hours in the future because the “t=<now+30 seconds>” is part of the DKIM signature for v=2, and if a phisher copy/pastes it and changes “v=2” to “v=1”, the “t= “ part will be long past. Right?

2.       This will be susceptible to a replay attack for 30 seconds after initially sending it out, but only to the mailing list. Right?

3.       Verifiers need to know (enforce?) that a DKIM signature of “v=2 !cd=<blah>” is not enough to verify a real signature without the corresponding “v=1 d=<blah>” additional DKIM signature. In other words “v=2 !cd=<blah>” is useless unless paired with something else. Right?

4.       How should reputation engines accrue this message? To authordomain.example (the one in the header.from)? Or to mlm.example, the one in the smtp.mailfrom and DKIM d= domain that contained the strong signature?

5.       Verifiers will need to check at least 3 DKIM signatures. Is there a limit on the amount of signatures they should check? Presumably we wouldn’t want a verifier to check 30 signatures.

6.       What is the proposed t= time limit? Is 30 seconds enough? Too long? Too little?

-- Terry

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Tuesday, May 19, 2015 11:39 AM
To: Terry Zink
Cc: Scott Kitterman; [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

> make that fact something a consumer of the field can parse out?
Putting it into a comment is fine, maybe something like “dmarc=pass action=none header.from=<domain.com<http://domain.com>> conditional.to<http://conditional.to>=<mailinglist.net<http://mailinglist.net>>”. I think it’s permissible to add additional fields like that into A-R, isn’t it?

More like:

You can create whatever structure you want in the comment (between parentheses).
-MSK

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 May 2015 12:11:33 -0700

> I would think you'd have to. There's a replay risk that's unique to this type of signature, so I think treating them the same would be a naive approach. 
Agreed.

These messages are likely be distributed to many subscribers
where each message must contain two linked signatures, the
siglet authorizing some third-party domain and a full
signature of the third-party domain..   A reasonable expiry
is required or delivery becomes unreliable.  What will be
considered a reasonable delivery window?  It seems most MTAs
will retry over a period of several days.

Email should not be treated like IM unless considering a
gateway to a federated IM system.  The IM-From header could
introduce both an alternative From header field andl act at
the IM gateway.  The mail transport would ignore this pseudo
sub-domain which could also assist in tracking abusive
sources.  In which case these addresses often indicate the
current instance of a on-network client denoted as a pseudo
sub-domain of the email-address.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 May 2015 15:15:13 -0400

On 5/19/2015 2:39 PM, Murray S. Kucherawy wrote:>

> Terry Zink
>     Putting it into a comment is fine, maybe something like
>     additional fields like that into A-R, isn’t it?
>
> More like:
>

IMO, this makes it a DMARC extension.

Is draft-levine-dkim-conditional a standard track DMARC extension?

Isn't this more of a DKIM extension?

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 13:01:57 -0700

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

> Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx)
> smtp.mailfrom=mlm.example;
>     dkim=fail (invalid body hash) header.d=authordomain.example
>     dkim=pass (signature was verified) header.d=authordomain.example;
>
>     dkim=pass (signature was verified) header.d=mlm.example;
>     dmarc=pass header.from=authordomain.example (action=none
> cd=mlm.example)
>
> l=0; t=<now+30 seconds>
> 1.       This should be resistant to a replay attack 12 hours in the
> future because the “t=<now+30 seconds>” is part of the DKIM signature for
> v=2, and if a phisher copy/pastes it and changes “v=2” to “v=1”, the “t= “
> part will be long past. Right?
>

"t=" is the timestamp at which the signature is generated, while "x=" is
the expiration timestamp. So, you'd do "x=<t+lifetime>" where "lifetime" is
the number of seconds you want the signature to be valid.

If a phisher changes the "v=2" to "v=1", the signature is rendered invalid
because that changes the part that's hashed. That attack won't work.

> 2.       This will be susceptible to a replay attack for 30 seconds after
> initially sending it out, but only to the mailing list. Right?
>

It will be replayable for whatever the difference is between "t=" and "x=",
by anyone that can generate a valid signature for the "!cd" domain.

> 3.       Verifiers need to know (enforce?) that a DKIM signature of “v=2
> !cd=<blah>” is not enough to verify a real signature without the
> corresponding “v=1 d=<blah>” additional DKIM signature. In other words “v=2
> !cd=<blah>” is useless unless paired with something else. Right?
>

The idea behind changing "v=" is to cause verifiers that know about "v=2"
to be the only ones that understand what "!cd" means, namely that the
signature is not valid unless accompanied by a valid signature from the
"!cd" domain.  A verifier that doesn't know about "v=2" will simply ignore
that signature entirely, so the condition cannot possibly be satisfied.

4.       How should reputation engines accrue this message? To
> authordomain.example (the one in the header.from)? Or to mlm.example, the
> one in the smtp.mailfrom and DKIM d= domain that contained the strong
> signature?
>

That's a good question, but one outside of John's proposal.  I suppose you
could accrue reputation on them severally, or jointly, or perhaps in some
combinations.  I don't know off the top of my head which would be best.

> 5.       Verifiers will need to check at least 3 DKIM signatures. Is
> there a limit on the amount of signatures they should check? Presumably we
> wouldn’t want a verifier to check 30 signatures.
>

It would be unusual to check more than three or perhaps five, I would
think.  It might be useful to collect information on how many we're seeing
in the wild.  Certainly a message bearing 20 or 30 might reasonably be
regarded as a possible attack because a lot of DNS and crypto has to be
done.

> 6.       What is the proposed t= time limit? Is 30 seconds enough? Too
I would guess too little, but at this point that's strictly a guess.  You
need to leave enough time for possible network or other transmission
problems between the signer and the intermediary you're trying to
accommodate.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 19 May 2015 20:38:50 +0000

Yeah, sorry, I confused the t= with x= in the DKIM signature.

-- Terry

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Tuesday, May 19, 2015 1:02 PM
To: Terry Zink
Cc: Scott Kitterman; [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

On Tue, May 19, 2015 at 12:00 PM, Terry Zink <[email-masked]<mailto:[email-masked]>> wrote:
I think we’re making progress here. So, a message would look like this:

From: [email-masked]<mailto:[email-masked]>
Some questions:

"t=" is the timestamp at which the signature is generated, while "x=" is the expiration timestamp. So, you'd do "x=<t+lifetime>" where "lifetime" is the number of seconds you want the signature to be valid.
If a phisher changes the "v=2" to "v=1", the signature is rendered invalid because that changes the part that's hashed. That attack won't work.

It will be replayable for whatever the difference is between "t=" and "x=", by anyone that can generate a valid signature for the "!cd" domain.

The idea behind changing "v=" is to cause verifiers that know about "v=2" to be the only ones that understand what "!cd" means, namely that the signature is not valid unless accompanied by a valid signature from the "!cd" domain.  A verifier that doesn't know about "v=2" will simply ignore that signature entirely, so the condition cannot possibly be satisfied.

That's a good question, but one outside of John's proposal.  I suppose you could accrue reputation on them severally, or jointly, or perhaps in some combinations.  I don't know off the top of my head which would be best.

It would be unusual to check more than three or perhaps five, I would think.  It might be useful to collect information on how many we're seeing in the wild.  Certainly a message bearing 20 or 30 might reasonably be regarded as a possible attack because a lot of DNS and crypto has to be done.

6.       What is the proposed t= time limit? Is 30 seconds enough? Too long? Too little?
I would guess too little, but at this point that's strictly a guess.  You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate.
-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 19 May 2015 22:52:26 +0200

On 05/19/2015 10:01 PM, Murray S. Kucherawy wrote:
> On Tue, May 19, 2015 at 12:00 PM, Terry Zink 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     DKIM-Signature: v=2; d=authordomain.example; s=selector;
>     !cd=mlm.example; l=0; t=<now+30 seconds>
>
>     1.This should be resistant to a replay attack 12 hours in the
>     future because the “t=<now+30 seconds>” is part of the DKIM
>     signature for v=2, and if a phisher copy/pastes it and changes
>     “v=2” to “v=1”, the “t= “ part will be long past. Right?
>
>
> "t=" is the timestamp at which the signature is generated, while "x=" 
> is the expiration timestamp. So, you'd do "x=<t+lifetime>" where 
> "lifetime" is the number of seconds you want the signature to be valid.

Do we have information about the percentage of implementations (c.q. of 
the installed base of implementations) that honour the t= and x= tags? 
Is that near 100%, 50%, less?

/rolf

---

From: Steven M Jones <[email-masked]>
Date: Tue, 19 May 2015 13:58:20 -0700

On 05/19/2015 13:01, Murray S. Kucherawy wrote:
>     6.What is the proposed t= time limit? Is 30 seconds enough? Too
>     long? Too little?
>
> I would guess too little, but at this point that's strictly a guess.  
> You need to leave enough time for possible network or other 
> transmission problems between the signer and the intermediary you're 
> trying to accommodate.

I expect you'll ultimately have to leave that up to the signer, no? 
Traditional practice would set it sometime between hours and days. But 
when somebody gets around to trying to exploit this window, sites with 
quick (re-)delivery to most of their recipients will probably want to 
cut the length of that exposure down...

--S.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 19 May 2015 23:42:46 +0200

> I expect you'll ultimately have to leave that up to the signer, no? 

Yep. And with the 'receiver' deciding whether to honour the requested 
expiration.

> Traditional practice would set it sometime between hours and days. 

Agreed.

> But when somebody gets around to trying to exploit this window, sites 
> with quick (re-)delivery to most of their recipients will probably 
> want to cut the length of that exposure down...

which effectively kills the SMTP retry strategy concept [1] and hence 
the store-and-forward character of Internet mail, as we know it since 
the late 70's. Please note that SMTP itself has per command timeouts [2] 
which make short t= limits in the order of sub-minutes or some minutes 
unrealistic for some parts of the Internet and for delivery to some 
organizations which now and then have outages of more than a few minutes 
(no monitoring, no staff etc.). Also, note that large mailing lists may 
take some time to expand the address list and deliver the mail to all 
recipients... So when an expiration time is chosen it has to match the 
real world of mail delivery, which is far better than 20 years ago, but 
still isn't perfect...

/rolf

[1] https://tools.ietf.org/html/rfc5321#section-4.5.4.1
[2] https://tools.ietf.org/html/rfc5321#section-4.5.3.2

---

From: "John Levine" <[email-masked]>
Date: 19 May 2015 22:14:56 -0000

>> Show one result or two? Or maybe something like dmarc=conditionalpass? ...

>messages to know it was based on a conditional signature versus an original

I don't see how this would work.  A bad guy can sign a fake A-R header
as easily as a good guy can sign a real one.  How is the recipient
supposed to tell the difference?

If you say you only use the A-R if you trust the intermediary, who
needs the A-R?  You already trust them to send something reasonable.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 15:16:02 -0700

On Tue, May 19, 2015 at 1:58 PM, Steven M Jones <[email-masked]> wrote:

> You need to leave enough time for possible network or other transmission
> Traditional practice would set it sometime between hours and days. But when
> somebody gets around to trying to exploit this window, sites with quick
> (re-)delivery to most of their recipients will probably want to cut the
> length of that exposure down...
>

Yes, absolutely this is at the discretion of the signer and not something
to be fixed in a protocol document except perhaps to enumerate the
tradeoffs between a short expiration and a long one.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 15:28:39 -0700

On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <
[email-masked]> wrote:

>
> But when somebody gets around to trying to exploit this window, sites with
> quick (re-)delivery to most of their recipients will probably want to cut
> the length of that exposure down...
>
>
> which effectively kills the SMTP retry strategy concept [1] and hence the
> store-and-forward character of Internet mail, as we know it since the late
> 70's. Please note that SMTP itself has per command timeouts [2] which make
> short t= limits in the order of sub-minutes or some minutes unrealistic for
> some parts of the Internet and for delivery to some organizations which now
> and then have outages of more than a few minutes (no monitoring, no staff
> etc.). Also, note that large mailing lists may take some time to expand the
> address list and deliver the mail to all recipients... So when an
> expiration time is chosen it has to match the real world of mail delivery,
> which is far better than 20 years ago, but still isn't perfect...
>

To your first point: SMTP itself isn't being altered by these proposals in
any way that I can see.  We're not changing the parts of SMTP you
referenced.  For one thing, if a DMARC rejection is undertaken by a
receiver, that action is final; there's no retry going to happen.  For
another, we're not influencing which host is being selected or what the
retry interval might be, or how long a queued message should be held before
ultimately being returned as undeliverable.  If DMARC recommended 4yz SMTP
replies when failures happen, that might be different, but that's not the
case here.  All of this can be thought of as happening in a layer above
SMTP, not as part of it.

To your second point: Those timeouts recommended by SMTP should at least be
referenced by any advice a conditional signatures draft might provide in
terms of selecting an expiration time.  Such a section would also be wise
to talk about header field selection and the like.  More generally, any
advice we can provide about what to consider when selecting the
construction of the conditional signature would be wise to include.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 May 2015 15:56:31 -0700

On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> with quick (re-)delivery to most of their recipients will probably want to
> To your second point: Those timeouts recommended by SMTP should at least
> be referenced by any advice a conditional signatures draft might provide in

We also appear to be OK with imposing delivery timeouts that extend beyond
the basic timeout set described in RFC5321, given what it says in RFC2852
(from 2000).

-MSK

---

From: "John Levine" <[email-masked]>
Date: 19 May 2015 23:40:21 -0000

>signature, so I think treating them the same would be a naive approach. 

Remember that DMARC doesn't tell you that a message is good.  The most
it can say is "not so awful that you should automatically reject it."
A sensible implementation will still run the mail through spam
filters like any other mail.

The risk is that the second signer might be malicious, but that's nothing
new, any signer can be malicious.  So do the usual filtering, use the
second signer's reputation.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 May 2015 17:14:23 -0700

On 5/19/15 3:56 PM, Murray S. Kucherawy wrote:
> On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy
> <[email-masked]> wrote:
>>> But when somebody gets around to trying to exploit this
window,
>>> sites with quick (re-)delivery to most of their
recipients will
>>> probably want to cut the length of that exposure down...
>>>
>>> which effectively kills the SMTP retry strategy concept
[1] and
>>> hence the store-and-forward character of Internet mail,
as we
>>> know it since the late 70's. Please note that SMTP
itself has per
>>> command timeouts [2] which make short t= limits in the
order of
>>> sub-minutes or some minutes unrealistic for some parts
of the
>>> Internet and for delivery to some organizations which
now and
>>> then have outages of more than a few minutes (no
monitoring, no
>>> staff etc.). Also, note that large mailing lists may
take some
>>> time to expand the address list and deliver the mail to all
>>> recipients... So when an expiration time is chosen it has to
>>> match the real world of mail delivery, which is far
better than
>>> 20 years ago, but still isn't perfect...
>>>
>> On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy
>> <[email-masked]> wrote:
>>
>> To your first point: SMTP itself isn't being altered by these
>> proposals in any way that I can see.  We're not changing
the parts
>> of SMTP you referenced.  For one thing, if a DMARC
rejection is
>> undertaken by a receiver, that action is final; there's
no retry
>> going to happen.  For another, we're not influencing
which host is
>> being selected or what the retry interval might be, or
how long a
>> queued message should be held before ultimately being
returned as
>> undeliverable.  If DMARC recommended 4yz SMTP replies
when failures
>> happen, that might be different, but that's not the case
here.  All
>> of this can be thought of as happening in a layer above
SMTP, not
>> as part of it.
>>
>> To your second point: Those timeouts recommended by SMTP
should at
>> least be referenced by any advice a conditional
signatures draft
>> might provide in terms of selecting an expiration time. 
Such a
>> section would also be wise to talk about header field
selection and
>> the like.  More generally, any advice we can provide
about what to
>> consider when selecting the construction of the conditional
>> signature would be wise to include.
>
> We also appear to be OK with imposing delivery timeouts
that extend
> beyond the basic timeout set described in RFC5321, given
what it says
> in RFC2852 (from 2000).

Murray,

Rolf has a valid point.  You are advocating email is to
radically change into an instant messaging scheme.

Are you now suggesting any properly functioning mediator
must process ALL its messages as they arrive rather than
permitting moderator approvals or any realistic post
processing overhead?

Such issues often confronts small servers to produce
somewhat erratic handling delays.

"Conditional" authorization expiry is wholly unrelated to
protocol timeouts.  A message being queued does not normally
obtain a fresh set of signatures.  If you are going to
justify short expiry using RFC5321, why ignore Section
4.5.4.1 and Section 7.1?

It is fairly common for a system to shutdown while being
patched whenever an active exploit is noticed.  Undelivered
messages are then queued and retried later.  Unreasonably
short expiry will once again make DMARC a primary cause for
message disruption whenever DMARC asserts inappropriate
handling requests.

How can delivery integrity be re-established?

What can extend a delivery window?

What can mitigate an exploited DKIM "conditional" authorization?

Is it reasonable to impose ever shorter "conditional"
authorization windows while holding mailing-lists
increasingly responsible for messages they distribute?

How will a mailing-list be affected by a malicious message
originating from a DMARC domain?

Since a DMARC domain will need to regiment inclusion of
"conditional" DKIM signatures, what prevents forthright
publication of this information to fully supplant use of
"conditional" DKIM signatures?

Isn't this a case of when a hammer is your only tool,
everything looks like a nail?

A stand-alone regimentation DNS server should prove more
effective and less disruptive than the proposed use of
conditional DKIM siglets.

After all, an attempt to use DKIM to signal a regimentation
scheme is likely the primary cause for a lack of adoption.

Why allow a few disruptive domains to prevent others from
adopting a workable solution?

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 19 May 2015 22:13:22 -0400

> second signer's reputation.

The challenge here is that the second signer may not have anything to do with 
the message.  Since, except for From, only invisible parts of the message are 
signed, the signature could be applied to almost any email.  Using the 
reputation of the second signer's domain is not substantially different than 
using the reputation of an unauthenticated identity.  I don't see how that 
helps.

If this is the path we go down, there's got to be something in the second 
signature that says it's means enough to override the DMARC fail/p=reject 
determination.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 May 2015 03:25:28 -0000

>using the reputation of an unauthenticated identity.  I don't see how that 

The second signer has at least enough to do with the message that it
has a real message in hand with permission to re-sign.

Remember the problem that got us here in the first place: AOL and
Yahoo had security failures that let crooks steal zillions of address
books, who then used botnets to send spam to AOL and Yahoo users that
appeared to be from other AOL and Yahoo users that they knew.  The
actual source of the mail had nothing to do with AOL or Yahoo, or any
system that had ever gotten mail from AOL or Yahoo.

The double signing hack limits the opportunity for trouble to mail
systems that have a recent real message in hand.  While I can
certainly imagine spammy scenarios, it's hard to imagine ones that
wouldn't be fairly easy to detect and shut down.  If nothing else, if
the original sender gets spam reports about double signed mail (there
are FBLs that key on DKIM signature) it can tell who's screwing
around and stop putting conditional signatures on mail to them.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 19 May 2015 23:34:07 -0400

On Wednesday, May 20, 2015 03:25:28 AM John Levine wrote:
> >The challenge here is that the second signer may not have anything to do
> >with the message.  Since, except for From, only invisible parts of the
> >message are signed, the signature could be applied to almost any email. 
> >Using the reputation of the second signer's domain is not substantially
> >different than using the reputation of an unauthenticated identity.  I
> >don't see how that helps.
> 

Right.  We need to be very careful about the security considerations with this 
so that operators don't inadvertently re-enable the scenario that Yahoo! and 
AOL set p=reject to mitigate.

It occurs to me that such FBL checks could be even be done prospectively, i.e. 
do a bad domain check and only add the domain as an fs= domain if it's not 
"bad".  That would allow the damage to be preempted for future mails once a 
domain makes the list.

This would get easier if DMARC feedback included some kind of spam verdict, 
but I doubt receivers would be willing to expose that.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 May 2015 22:17:55 -0700

> around and stop putting conditional signatures on mail to them.
Dear John,

I receive similar levels of spoofed friends who once had
accounts with Yahoo and AOL.  The phishing now tends to
depend on the look and feel of the Display name rather than
having an exact domain.  In these cases DMARC offers little
to no value. 

Mediators could apply a policy suitable for blocking input
failing an initial hop from the DMARC domain.  Any
subsequent policy would then need to carve out exceptions
for mediator domains that their DMARC feedback should
clearly identify.  Once a two stage policy scheme is
facilitated that only the DMARC domain can monitor via their
feedback, then only the DMARC domain would be able to spoof
one of their own users.  If someone cheated, the exceptions
to permit these mediators could be immediately retracted.  
The daisy-chain alternative you proposed provides a DMARC
domain less ability to stop bad actors and causes far
greater change to email infrastructure for little benefit.

A similar regimentation scheme will be needed.  I still
think this should be published as Sha-1 hash labels, but
that optimization seems to make people think it is too
complex.  People need to think of it like a box of
chocolates, you never know what you are going to get. 
Whatever the answer, it is authoritatively delicious. :^)

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 20 May 2015 18:59:20 +0900

> should be published in the form of an Internet Draft. 

Understood.  But this was Dave's idea, and he pretty clearly intends
to take care of coordination of collection and editing.

---

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

Dave Crocker writes:

 > However getting them all to use exactly the same wonderful MLM
 > software that mailbox providers consider the very best for
 > anti-spam, is probably in the realm of impossible.

Especially since 3 of the biggest mailbox providers are surely going
to promote their own in-house services.  (At least, I would if I were
them, at least to my own mailbox users.)

 > (And given the weaknesses of monocultures, it's also a terrible
 > idea...)

+1 to that!

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 20 May 2015 19:14:37 +0900

> elements likely altered by a mediator.

Please, no.  I agree that "weak signature" is inaccurate, but really
we have a "full-coverage" signature (whatever terminology you like)
signing pretty all originator header fields plus authentication fields
plus the whole body, versus anything less than that (especially but
not restricted to allowing additions to the body).  I suspect that
that is the "security-relevant" distinction, but that some originators
will be willing to take more risks than others (eg, using or avoiding
an l=<actual length> spec).  "Siglet" is way too constrained in your
definition; if we push for that, I think we'll have real trouble
convincing some of the managements.  Let's not embed that in the
terminology, but rather let the originators decide what's "strong" or
"full" enough for them.

It's possible that with Murray's signature-per-MIME-part technique we
could get finer distinctions, but that really requires support from
MUAs that I expect Emacs/Gnus will have a Day 0 implementation for,
while GMail and Outlook may never implement.  Ie, don't hold your
breath.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 20 May 2015 19:35:51 +0900

> radically change into an instant messaging scheme.

No, this change is only necessary if the Author Domain is *already*
advocating that email has to radically change into a direct-mail-only
scheme.  I consider "direct mail only" to be by far the more radical
restriction in today's environment.  Heck, even in the late 80s it was
possible to have a lover's quarrel (not to forget certain post-
quarrel activities) in realtime over BitNET.

 > permitting moderator approvals or any realistic post

No, they can still reject or munge or omit changes that invalidate
signatures, etc, if they detect that the message is unlikely (or
impossible) to deliver within the window.  This protocol gives *more*
choice to the Mediator than DMARC currently allows.

Remember, we've *already* backpedaled (temporarily) from "all 3rd
party mail" to "actively mediated mail".  If we can get half of that
list traffic past DMARC p=reject, a large share of my constituency
will be a lot happier.

 > message disruption whenever DMARC asserts inappropriate

Yup.  HMS DMARC Disruption has sailed.  The only real option is to
torpedo her, but I think that target is out of range now.

 > adopting a workable solution?

Because they not only brought the bat and ball, but their Daddy owns
the sandlot?  Specifically, at least for the Mom & Pop MLs you've
mentioned as being a concern, a lot of their posters are from those
domains, and they don't want to upset them any more than they already
are.

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 May 2015 07:53:16 -0400

With two sigs, all I can see is that the first leg of the transport is 
stronger

    PATH: MTA ----> MLM  strong 1st party v1 signature
    PATH: MLM o---> MTA  weak 1st party v2 signature

If this hack essentially weakens a DKIM signed message so that it can 
survive the transport, the MLM changes and the final destination. then 
why not just do create this weakness with just one original v1 
signature using the i= (AUID) to pass the resigner information?

  From: [email-masked]
  DKIM-Signature:
     v=1
     d=author.example
     s=signer.selector
     i=[email-masked]
     l= <-- weak sizing
     h= <-- weak header binding list

Just as you expect the v2 signature to survive, and also not get 
stripped, why can't that happen with the weak v1 author domain signature?

The resigner domain can be passed via the AUID i= tag.

The final receiver will now see weak first party signature and the 
OPTIONAL stronger resigner signature.

Since this is a DMARC extension, the trigger tag can be used such as 
"dualsig=y" on the DMARC record to enable the logic. But that wouldn't 
be needed as long as the first party sig is survivable which is all we 
are doing with the v2 sig.

Unless I missing something, using this simpler method offer 
compatibility with the non-signing MLM as well.

The only benefit using 2 sigs I see is the stronger first leg 
transport to the MLM and as long as the MLM domain is known, it 
doesn't matter at the point why you send this guy as long as its 
survivable for the distribution.   The final receiver can use the i= 
tag of the original weak signature to get the permission to 
"authorize" the potential resigner.

-- 
HLS

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 20 May 2015 14:56:10 +0200 (CEST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "<[email-masked]>" <[email-masked]>
> Cc: "Steven M Jones" <[email-masked]>, [email-masked]
> Sent: Wednesday, May 20, 2015 12:56:31 AM

> On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy <
> [email-masked] > wrote:

> > [email-masked] > wrote:
> 

> > > the store-and-forward character of Internet mail, as we know it
> > > since the late 70's. Please note that SMTP itself has per command
> > > timeouts [2] which make short t= limits in the order of
> > > sub-minutes
> > > or some minutes unrealistic for some parts of the Internet and
> > > for
> > > delivery to some organizations which now and then have outages of
> > > more than a few minutes (no monitoring, no staff etc.). Also,
> > > note
> > > that large mailing lists may take some time to expand the address
> > > list and deliver the mail to all recipients... So when an
> > > expiration
> > > time is chosen it has to match the real world of mail delivery,

> > proposals in any way that I can see. We're not changing the parts
> > of
> > SMTP you referenced.
> 

No, I understand and that's not what I said. 

> > For one thing, if a DMARC rejection is undertaken by a receiver,
> > that
> > action is final; there's no retry going to happen.
> 

Correct. But DMARC rejection is only the final part of the chain (at least, when we talk about the transfer of messages from one ADMD boundary, via an intermediary ADMD or directly, to a receiver ADMD). If you write out all the actions that are required to get a mail from A to B, then you'll get an impressive list of situations where something can go wrong and which in turn can delay the delivery of the message to the receiving ADMD. 

> > For another, we're not influencing which host is being selected or
> > what the retry interval might be, or how long a queued message
> > should be held before ultimately being returned as undeliverable.
> 

Correct, but we must take into account that there are retry intervals being used by MTA's along the line between author domain and receiver domain. 

> > If DMARC recommended 4yz SMTP replies when failures happen, that
> > might be different, but that's not the case here. All of this can
> > be
> > thought of as happening in a layer above SMTP, not as part of it.
> 

> > To your second point: Those timeouts recommended by SMTP should at
> > least be referenced by any advice a conditional signatures draft
> > might provide in terms of selecting an expiration time. Such a
> > section would also be wise to talk about header field selection and
> > the like. More generally, any advice we can provide about what to

> We also appear to be OK with imposing delivery timeouts that extend
> beyond the basic timeout set described in RFC5321, given what it
> says in RFC2852 (from 2000).

I'm afraid you missed my point (or better said: obviously I didn't make myself clear :-)). What I want to say is: we have an existing Internet mail infrastructure where delivery times can range from seconds to many hours. With 'delivery time' I mean the time between the author domain DKIM signs the message and the time that the verifier domain checks the DKIM signature (not just between author domain and intermediary domain nor just between intermediary domain and verifier domain). Maybe we should call this 'message transfer time', not delivery time. If we try to solve the 'Mediator problem' by assuming that we can set very short expiration times on the signatures (to prevent replay) we seem to forget that this may lead to the rejection of a non-negligible amount of legitimate mail due to the nature of the Internet mail ecosystem as it is today. 

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 20 May 2015 15:20:43 +0200 (CEST)

[...]

> message disruption whenever DMARC asserts inappropriate

Doug rephrased my concern about short expiry times quite well. Of course author domains are free to choose what expiry they want, but the question is: is it OK to design a(n extension to a) protocol which don't take the existing status quo of Internet mail into account?

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 20 May 2015 10:10:25 -0400

On May 20, 2015 9:20:43 AM EDT, "Rolf E. Sonneveld" <[email-masked]> wrote:
>Doug rephrased my concern about short expiry times quite well. Of
>course author domains are free to choose what expiry they want, but the
>question is: is it OK to design a(n extension to a) protocol which
>don't take the existing status quo of Internet mail into account?

If it weren't, DMARC wouldn't exist. We probably won't repair all the breakage. The question is how much is enough. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 May 2015 11:25:23 -0400

How can you see lower cost for  hotmail.com, aol.com and yahoo.com and such domains to begin to weaken their signed mail streams with v2 signature resigner authorization signatures?   That pesky registration problem again.   What if the resigner domain decides to change its resigner domain?    How that's the feedback get back to the originating domain? 

I believe the dual sig idea is good to be part of a more comprehensive solution, not total and nor exclusive,  but more.  It is less secure not matter how we look at it, so it is prudent, the more secured, more baseline,  DNS query solution be also part of the IE* recommendations. This is especially the case when  proposed as a Standard Track protocol.

Let's remember there are two parts of this; verification by two receivers we are mostly concern about, and the original signer and its exposed public policy  intentions and expectations.

We got working code and a practical solution for those with DNS management.  I have ATPS running code both the rev4 and RFC version in a wide network of operators.  I have enterprise beta testers what also use openDKIM/openDMARC in an integrated SMTP environment where our package serves as an AVS frontend relay for them.  So we can do ATPS testing and I plan to recommend and illustrate source code change to support ATPSRev4.   It's about support options.

Adding two signatures will take signer engine code change. Once I see p=reject domains add support for v2,  I will explore changing code again to support for V2 signatures too. Or at least, explore adding verification code since that is already in a change flux.

> On May 18, 2015, at 12:26 AM, Murray S. Kucherawy <[email-masked]> wrote:
>

---

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

> scheme.  

This is off-topic, but I read yesterday that Microsoft is coming out with a product called "Flow" that treats email like instant messaging. You contact anyone on your list with an email address and send them a message. The backend is email/SMTP but the front-end is like instant message. So, the distinction between instant messaging and email is blurring even now.

http://www.cnet.com/news/microsoft-may-be-building-a-lightweight-email-app-called-flow/

Anyhow, now back to the discussion at hand.

-- Terry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 May 2015 10:09:51 -0700

On Wed, May 20, 2015 at 6:20 AM, Rolf E. Sonneveld <
[email-masked]> wrote:

> Doug rephrased my concern about short expiry times quite well. Of course
> author domains are free to choose what expiry they want, but the question
> is: is it OK to design a(n extension to a) protocol which don't take the
> existing status quo of Internet mail into account?
>

I don't think it's at all the case that we're not taking the existing
status quo into account.  In fact I'm explicitly saying the opposite:
Operators need to select expiration times that balance the expected flow of
email (with its typical and atypical patterns) with the security concerns
of a signature that has a risk of abuse, and we would do well to remind
them of this, either explicitly or by reference.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Wed, 20 May 2015 17:32:06 +0000

> stripped, why can't that happen with the weak v1 author domain signature?

A weak single signature makes it more vulnerable to a replay attack. With two signatures, the MTA --> MLM is protected (which is important) and the MLM --> MTA is also protected although there is a time window of vulnerability. However, if the first leg is protected then it's smaller risk if the second leg is less protected.

Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Wednesday, May 20, 2015 4:53 AM
To: [email-masked]
Subject: [dmarc-ietf] Weaker single author signature

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 May 2015 12:15:22 -0700

Dear Terry,

Various conditional DKIM signatures signal a time limited
trust with some indicated third-party domains where delivery
failure results in either Quarantine or Reject!!!

What has changed to suggest a new found willingness to
regiment issuance of short-term unreliable and vulnerable
messaging?  Who would really want to handle support after
deploying this type of scheme?  What level of psychic
capability will be required of the support staff?

This situation is caused by DMARC's refusal to allow proper
request profiles for domains that handle NORMAL email.  
Email compatibility demands recognition of Sender header
field's role!  Whether or not AOL or Yahoo decides to
implement a "public" profile as described in section 4 of
https://tools.ietf.org/html/draft-otis-dmarc-escape , a
fairly practical override could be implemented to allow
other domains a sane way to deal with resulting delivery
disruptions.  The short-term delivery scheme you are
suggesting only makes the situation worse.

A sane and compatible method to handle email will actually
improve email security without expecting disruptive domains
to reform their behavior.  This could ensure any source
where the From contains an address within a DMARC domain can
be verified.  These domains can base acceptance on feedback
to curb spoofing attempts.  Of course, they should find a
way to share this feedback with various reputation services
(which is the norm).  They should at least share this
information with themselves.

By having the Sender header field present, MUAs are able to
make this apparent to recipients and reduce someone's need
to search for often legitimate messages in spam folders. 
Poking around in the spam folder is always perilous. 
Without a defined "public" profile, the typical override is
to change "reject" to "quarantine" where users are then told
where they might find their missing messages.  Any domain
not happy with a "public" profile could also override this
with "quarantine" as well.  A properly implemented "public"
profile better enables improved and non-disruptive inbox
defenses.

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Wed, 20 May 2015 19:56:15 +0000

> the message.  

Not sure I follow this comment. The first signer says that there will be a second signer, and the second signer must be the one the first signer said.

Sounds like the second signer has (almost) everything to do with the message?

> "bad".  

Yes, a first-signer could choose to only add an fs= (or !cd= ) if they trust the second signer and know it's a mailing list. A receiver could choose not to honor the fs= (or !cd= ) if it thinks the second signer doesn't do a good job of filtering mail at its entry point, or sends a lot of bad mail in general.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Tuesday, May 19, 2015 7:13 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

Scott K

---

From: Terry Zink <[email-masked]>
Date: Wed, 20 May 2015 20:12:13 +0000

Hi, Doug,

> to search for often legitimate messages in spam folders.

I'm not sure why you keep bringing up the Sender: field in the MUA as a suitable example. As has been pointed out elsewhere, most mail clients (Hotmail, Gmail, iOS, Android, even Windows Phone!) don't show it. It's not that they are unaware of its existence, but rather that its presence confuses recipients. There's no magic wand to wave where users will understand it, nor MUA's will bother to expose it, and that's why many people on this list - myself included - don't think it will work.

The only mail client off the top of my head that shows it is Outlook, and I see it used a lot when an administrator sends it on behalf of an executive's email inbox. That is, "<admin> on behalf of <CEO>." Here it makes sense. But I think outside of a corporate environment, it's confusing.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, May 20, 2015 12:15 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Weaker single author signature

Dear Terry,

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 May 2015 19:23:01 -0700

Dear Terry,

As re-enforced by Section 7.1 of RFC5321, unless S/MIME or
OPEN PGP is used, mobile and desktop environments offer poor
visibility of a message's originating domain.  The level of
security should quickly improve as DANE becomes more
prevalent.  With increased resolutions, mobile devices also
offer capable web interfaces.  Don't deprecate currently
defined identifiers clearly declaring source agents.  Assume
a solution will be found within a very competitive MUA
environment.  Avoid solutions that attempt to make poorly
considered alterations to email's fundamental transport.

Any message from a DMARC domain asserting a "public" policy
request permits a non-disruptive verification of source
identifiers as defined by Section 4 of
draft-otis-dmarc-escape .  Only when verification is not
obtained should a message be placed into a spam folder. 
This should limit spam folder placements to unverified
domains, or domains having either bad or unknown
reputations.  This is far better than treating recipients as
being unable to obtain an effective MUA or to use a browser. 

Accurately ascertaining the source to exclude malicious
actors is important since just the Display name can easily
deceive recipients in cases where user accounts have been
compromised. A Display name exploit offers an effective
means to side-step DMARC's efforts, especially when
man-in-the-middle schemes make true source recognition
impossible.

Depending on weird DKIM hacks will only serve to ossify
security improvements.  Use of short-lived "conditional"
DKIM authorization signatures that must also coincide with a
stronger third-party domain has a likelihood of showing
recipients "conditional" authorization signatures where an
entire message body may change.  When DKIM is used in this
fashion, it can not ensure against messages being carried
by  botnets to any number of recipients containing any type
of content.  Botnets will not have any trouble making full
use of any reasonable expiry established at the first hop.

While the source header display is not normally the default
except for Outlook, the following MUAs offer informed
recipients information necessary to detect likely fraud. 
They can also provide safer services that make use of a
mobile devices' support of S/MIME or depend on the mobile
browser or depend on proper vetting of "public" DMARC handling.

MUAs offering informed recipients information necessary to
detect likely fraud--

Mozilla Thunderbird
Outlook 2007
Outlook 2007 Web Access
Outlook 2000/XP/2003
Outlook Express 6
OS X Mail.app v2 and v3
Entourage 2008
Eudora (Based on Thunderbird)
Eudora (Original)
Evolution
The Bat!
KDE Kmail
Pine
Pegasus Mail
XtraMail
Claris Emailer
Juno
Novell Groupwise

Webmail
Gmail
Yahoo! Mail Classic
Yahoo! Mail (New)
Windows Live Hotmail (in "Full Version" mode)
AOL
Yandex

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 May 2015 08:23:43 -0400

> Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time.

Several points.

First, you are assuming the MLM will do CSP (Check Signing Practices). 
  A good bit of the long time conflict and dilemma has to do with the 
fact there are legacy MLM operations that can not adapt and/or will 
militantly refuse to adapt.  So one question might be; will this weak 
v2 idea encourage them or "mandate" them to do the CSP?

    The MLM MUST|SHOULD|MAY do the CSP prior to resigning.
    The MLM MUST|SHOULD|MAY deny restrictive submissions.
    The MLM MUST|SHOULD|MAY resign a V2 message.

You have to consider all scenarios when the domain, i.e. Hotmail.com, 
is going to begin to double v1/v2 sign all its outgoing messages to 
avoid registration design requirements.  Overall, you will have a 
population of different types of MLMs.

To address the extra time window exploit on the first leg, you can 
always send out a Double V1/V1 pair, first leg strong, second leg weak.

The main point is that its possible to do same thing with no signer 
engine code change using a weak v1 signature.  You can pass the 
resigner domain via the i= tag (AUID) which was one of its intended 
ideas, among many.   This would have a lower cost of adoption and 
adaptation because its compatible with V1 STD operations and 
configurations that may be already exist using a "i=signer@author" 
syntax or allow for it as our system does:

######################################################################
# Wildcat! DKIM (wcDKIM)
# (c) copyright 2011 Santronics Software, Inc.
# version: 3.10
# ...
# ....
# IDENTITY (i=)
#
# The optional i= tag allows you to add any valid formatted "email 
address"
# (but it doesn't have to exist).  It must be the same domain as the 
signer
# or a sub-domain of the signer.  Some macros are available:
#
#   {AUTHOR}           replace the Author (From:) address
#   {AUTHOR.DOMAIN}    replace the Author (From:) address domain
#   {SIGNER}           replace the signer domain
#
#   example: i= {AUTHOR}.{SIGNER}

That wasn't just my idea. That was a WG consideration and I believe it 
may be documented somewhere.   No code change. I believe the AUID is 
already a registered tag for A-R.

At some point we need to leverage what we already have done and stop 
reinventing stuff, with more patch work and hacks that at some point 
the benefits of incremental adaptation diminishes.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 May 2015 08:24:32 -0700

On Wed, May 20, 2015 at 10:32 AM, Terry Zink <[email-masked]>
wrote:

> A weak single signature makes it more vulnerable to a replay attack. With
> two signatures, the MTA --> MLM is protected (which is important) and the
> MLM --> MTA is also protected although there is a time window of
> vulnerability. However, if the first leg is protected then it's smaller
> risk if the second leg is less protected.
>

Right.  The trick is deciding under what circumstances to add both a v1 and
v2 signature.

You could do it always, which smaller operators would probably do.  It's
terribly simple, and that covers your bases for interacting with MLMs a
priori, but exposes you to a temporary risk when any of your users sends a
message to any domain containing a bad actor.

You could do it only if some local secret sauce determines that the
intended recipient is an MLM.  But that amounts to either use of heuristics
(which can be gamed or come up with the wrong answer) or some kind of local
registration process (which doesn't scale).  The temporary risk is still
there, but the threat surface is reduced because you inherently know a
little something about the recipient domain.

You could do it only for domains your users have declared contain MLMs with
which they want to interact, but there again is the registration problem.
There's also again the smaller threat surface, but this time you're also
inherently trusting your users to make true declarations, and also to
declare when the MLM is no longer of interest.  That seems rather a burden.

You could do it for all domains until they misbehave and then stop adding
v2 signatures for them, but that can be gamed ad infinitum (domains can be
trivially created and discarded).

All of those options for any at-scale operator seem uncomfortable to me.
The most obvious advantages to me of this method over ATPS, TPA, and that
family of proposals are that (1) there's no additional DNS check required
because the third party endorsement is contained within the message; and
(2) it's quite a bit easier to implement than the others, at least for my
project.

Then again, if the at-scale operators that are home to most of the problem
(we meet again, Mr. Pareto) are comfortable with using whatever homegrown
heuristics they use now with the commensurate risks of v2 signatures, then
this approach appears to me to be quite viable.

Note that in fact the MLM doesn't have to check anything, or know any of
this is even going on.  Neither does its MTA even need to know what a v2
signature is; it simply re-signs the message and sends it along to the list
subscribers.  The whole point here is to make sure the MLMs know as little
as possible so that all of them can be silently accommodated.

> > around and stop putting conditional signatures on mail to them.

True, the damage is limited to the lifetime of the last v2 signature the
author domain added.  I'm being cautious above because I'm sure author
domains would prefer to be proactive about such threats rather than
reactive to them.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 21 May 2015 17:10:42 -0000

>> wouldn't be fairly easy to detect and shut down. ...

>domains would prefer to be proactive about such threats rather than

These days the big mail systems' spam filtering is so fluid that the
difference is pretty blurry.  I gather that gmail has per-user filter
rules and can update them after each message.

It is my impression that the problem that persuaded Yahoo to do the
DMARC thing was crooks mailing into Yahoo with fake Yahoo return
addresses so their own users were complaining.  Should crooks use
double signing to do that, I'd think it'd be pretty easy to detect and
to mitigate.  If they're seeing a lot of spam button reports about a
particular re-signer, stop putting conditional signatures on mail sent
to them.

It sure would be nice to get some feedback from large mail systems and
hear whether our guesses about them are correct.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 21 May 2015 17:24:44 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Thursday, May 21, 2015 1:11 PM
> To: [email-masked]
> Cc: [email-masked]
> >True, the damage is limited to the lifetime of the last v2 signature
> >the author domain added.  I'm being cautious above because I'm sure
> >author domains would prefer to be proactive about such threats rather
> >than reactive to them.
> 
> These days the big mail systems' spam filtering is so fluid that the difference
> is pretty blurry.  I gather that gmail has per-user filter rules and can update
> them after each message.
> 
> It is my impression that the problem that persuaded Yahoo to do the DMARC
> thing was crooks mailing into Yahoo with fake Yahoo return addresses so
> their own users were complaining.  Should crooks use double signing to do
> that, I'd think it'd be pretty easy to detect and to mitigate.  If they're seeing a
> lot of spam button reports about a particular re-signer, stop putting
> conditional signatures on mail sent to them.
> 

My understanding is that the bad guys were stealing Yahoo address book information and then mailing from OUTSIDE Yahoo to the recipients (not Yahoo) claiming to be from the Yahoo user that they stole the address book info from - thus the p=reject shutting the problem down almost immediately for many recipients.

> It sure would be nice to get some feedback from large mail systems and hear
> whether our guesses about them are correct.
> 
> R's,
> John
>

---

From: Terry Zink <[email-masked]>
Date: Thu, 21 May 2015 17:27:04 +0000

> You could do it only if some local secret sauce determines that the intended
> recipient is an MLM... Then again, if the at-scale operators that are home to
> most of the problem (we meet again, Mr. Pareto) are comfortable with using
> whatever homegrown heuristics they use now with the commensurate risks
> of v2 signatures, then this approach appears to me to be quite viable.

> These days the big mail systems' spam filtering is so fluid that the difference is pretty
> blurry.  It sure would be nice to get some feedback from large mail systems and

> hear whether our guesses about them are correct.

The way I envision this working at a large mail provider – of which I happen to have some insight into, that of Hotmail (and associated consumer brands) and Office 365 which hosts small, medium, and large businesses – what we would do is come up with a list of MLM domains and figure out its reputation – does it send mostly good email or mostly bad email? If mostly good, then if a sender sends a message to them, we’d affix a DKIM v2 signature.

On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or* simply suppress the DMARC check and apply all of our other antispam filtering, and update the MLM’s reputation accordingly. The affixing of the DKIM v2 is more for interoperability for when our users send to MLMs which in turn are relayed to other providers. If a MLM starts generating too many spam complaints then we’d stop applying DKIM v2 signatures and maybe start reapplying DMARC to it.

Not sure how other big mailers would do it, but I would think it would be similar (especially Gmail).

-- Terry

---

From: "John R Levine" <[email-masked]>
Date: 21 May 2015 13:37:57 -0400

> My understanding is that the bad guys were stealing Yahoo address book 
> information and then mailing from OUTSIDE Yahoo to the recipients (not 
> Yahoo) claiming to be from the Yahoo user that they stole the address 
> book info from - thus the p=reject shutting the problem down almost 
> immediately for many recipients.

The bad guys used stolen address books to mail to lots of places including 
into Yahoo, with fake Yahoo return addresses of people the recipients 
knew.  The complaints that mattered were from Yahoo users about mail sent 
to their Yahoo addresses.  (If get spam with a fake Yahoo return address 
sent to my Hotmail address, I'll hit the spam button, Hotmail will 
decrease the reputation of the sending IP, and that's about it.)

We can leave for the advanced seminar the question of why if that were the 
problem, Yahoo didn't do something less disruptive.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 May 2015 10:56:26 -0700

> similar (especially Gmail).
At Facebook there are no longer any email-enabled mailbox services, so it's
not among the more interesting of the big cases except for the scale it
handles.  In terms of email it's just a forwarding service now.  So
inbound, it would check v=1 and v=2 and DMARC, and then hand the whole
package off to internal analysis machinery for a verdict.  If the message
survives, it's relayed; then, outbound, it would sign with v=1 and be done
because it's unlikely anything past that is an MLM.

Gmail, AOL, and Yahoo would be interesting to hear about.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 May 2015 11:13:12 -0700

On Thu, May 21, 2015 at 10:56 AM, Murray S. Kucherawy <[email-masked]>
wrote:

>
> At Facebook there are no longer any email-enabled mailbox services, so
> it's not among the more interesting of the big cases except for the scale
> it handles.  In terms of email it's just a forwarding service now.  So

Also, the vast majority of FB's outbound traffic is notifications, not
stuff that's user-generated, so v=1 outbound there is again all that's
probably needed.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 May 2015 13:27:31 -0700

Dear Murray,
See comments inline:

On 5/21/15 8:24 AM, Murray S. Kucherawy wrote:
> On Wed, May 20, 2015 at 10:32 AM, Terry Zink 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     A weak single signature makes it more
>     vulnerable to a replay attack. With two
>     signatures, the MTA --> MLM is protected
>     (which is important) and the MLM --> MTA is
>     also protected although there is a time
>     window of vulnerability. However, if the
>     first leg is protected then it's smaller
> Right.  The trick is deciding under what 
> circumstances to add both a v1 and v2 signature.
DKIM v1 v2 is not suitable for use with DMARC 
because it fails to offer those handling these 
messages protection.  Any v1 + v2 seen by any 
number of recipients can lead to any number of 
subsequent authorized messages for any large 
number of recipients from any large number of 
sources.  This DKIM scheme remains ineffective at 
offering protection with respect to MiTM threats.  
This issue is significant for the likely use case 
of mailing-lists!  A major premise of this effort 
is that recipients ONLY pay attention to the From 
which this scheme preserves unchanged.  As Hector 
mentioned, this scheme is unable to authorize any 
service not using DKIM, however the TPA-Label 
scheme overcomes this significant limitation with 
respect to NORMAL email. In fact, it can avoid 
reliance on DKIM altogether when necessary.
> You could do it always, which smaller operators 
> would probably do.  It's terribly simple, and 
> that covers your bases for interacting with MLMs 
> a priori, but exposes you to a temporary risk 
> when any of your users sends a message to any 
> domain containing a bad actor.
Unlike the TPA-Label scheme, v1 v2 DKIM signatures 
offer operators of any size NO help at identifying 
bad actors exploiting the DKIM v1 v2 scheme.  In 
addition, risks are not limited to just where a 
message has been sent as it offers NO MiTM 
protection, nor can it. This is one of the reasons 
TPA-Label was not limited to just using DKIM.  Any 
expectation that this scheme works will certainly 
lead to unfair justifications for blocking 
mailing-lists.
> You could do it only if some local secret sauce 
> determines that the intended recipient is an 
> MLM.  But that amounts to either use of 
> heuristics (which can be gamed or come up with 
> the wrong answer) or some kind of local 
> registration process (which doesn't scale).  The 
> temporary risk is still there, but the threat 
> surface is reduced because you inherently know a 
Any large ESP should be fully capable of 
characterizing the entirety of their own outbound 
email traffic.  Especially when DMARC offers them 
feedback clearly indicating any undesired 
results.  The larger the scale, the more accurate 
characterization becomes. It is infinitely more 
problematic for their recipients however, but DKIM 
v1 v2 fails to share essential information.
> You could do it only for domains your users have 
> declared contain MLMs with which they want to 
> interact, but there again is the registration 
> problem.  There's also again the smaller threat 
> surface, but this time you're also inherently 
> trusting your users to make true declarations, 
> and also to declare when the MLM is no longer of 
> interest.  That seems rather a burden.
If too much of a burden for the DMARC domains, 
then consider how much greater this is for 
recipients who lack necessary feedback and sender 
relationships to ascertain the provenance of a 
third-party message.  That said, we did alright 
protecting MLMs at a very large scale in an era 
before there was SPF or DKIM.
> You could do it for all domains until they 
> misbehave and then stop adding v2 signatures for 
> them, but that can be gamed ad infinitum 
> (domains can be trivially created and discarded).
When a DKIM v1 v2 message is abused, how would you 
determine who is actually responsible? (Hint.  
DKIM v1 v2 can't make this determination.)
> seem uncomfortable to me.
At scale may mean regimenting hundreds of outbound 
servers.  At these levels SQL won't work well.
> The most obvious advantages to me of this method 
> over ATPS, TPA, and that family of proposals are 
> that (1) there's no additional DNS check 
> required because the third party endorsement is 
> contained within the message; and (2) it's quite 
> a bit easier to implement than the others, at 
> least for my project.
No additional DNS checks???  DKIM depends heavily 
upon accessing DNS.  Requiring recipients to 
process three rather than just one DKIM represents 
a significant increased DNS overhead.  Imagine the 
mess when some domains then attempt to retract 
their DKIM keys.
> Then again, if the at-scale operators that are 
> home to most of the problem (we meet again, Mr. 
> Pareto) are comfortable with using whatever 
> homegrown heuristics they use now with the 
> commensurate risks of v2 signatures, then this 
> approach appears to me to be quite viable.
Hardly.  Pareto's was attempting to model a small 
percentage of actors controlling a large 
proportion of commerce.

Of course v1, v2 DKIM reinforces such efforts by 
breaking the backs of smaller operators.
> Note that in fact the MLM doesn't have to check 
> anything, or know any of this is even going on.  
> Neither does its MTA even need to know what a v2 
> signature is; it simply re-signs the message and 
> sends it along to the list subscribers.  The 
> whole point here is to make sure the MLMs know 
> as little as possible so that all of them can be 
> silently accommodated.
Not impacting third-party service providers is a 
great goal, but not protecting them from likely 
backlash is diabolical.
> True, the damage is limited to the lifetime of 
> the last v2 signature the author domain added.  
> I'm being cautious above because I'm sure author 
> domains would prefer to be proactive about such 
> threats rather than reactive to them.
Large ESPs are openly belligerent when imposing 
restrictive DMARC policy against normal users. 
Perhaps they see mailing-list as competitors for 
their precious user's eyeballs.

Deal with abuse by identifying and blocking its 
source.  DKIM can't reliably do this when dealing 
with mailing lists.  A "public" DMARC profile can 
easily dissipate harm by providing a safe less 
disruptive override by simply requiring source 
verification when carrying a message that contains 
their domain.  If needed, a DMARC domain can 
become proactive at helping recipients identify 
good/bad actors by offering TPA-Label.

The problem involved with multiple parties passing 
messages around does not end with just 
mailing-lists.  Equally problematic are issues 
related to link distributors (ad servers).  Again, 
abuse is best prevented in the most direct manner 
possible by blocking sources that originate 
malicious content.  Often, risks are hidden by 
being combined with various active components 
within the infrastructure like browser plugins or 
web based services. TPA-Label can help establish a 
type of informal federation scheme to better 
manage abuse abatement.

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 21 May 2015 21:00:38 -0000

>On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or*
>simply suppress the DMARC check and apply all of our other antispam filtering,
>and update the MLM’s reputation accordingly.

Well, gee, you can do that now.  We hope you do, since that will also
enable list mail from people with addresses at Yahoo and AOL.

With double signing, you have the ability to distinguish between plain
old spammers, and spammers who are screwing around with forwarded
mail.  I think that's a useful difference, since it is my impression
that the set of malicious mutating forwarders is pretty small because
it's a lot of hassle and not a lot of reward.

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 22 May 2015 11:50:51 +0900

> it's a lot of hassle and not a lot of reward.

Unless you have the user's address book to hand, and can thus target
your shot with a significantly higher percentage of "successes" than
random spamming.  That's a significant marketing advantage if you're a
contract spammer (rather than spamming for your own account), I would
suppose.

---

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

> (2) it's quite a bit easier to implement than the others, at least for my

It allows per-message, per-remailer authorization, which cannot scale
for a DNS based protocol; they have to restrict themselves to
authorizing remailing by whole domains for a period of time.

This means that to successfully phish a recipient, attackers have to
first phish the apparent sender.  This is a *huge* reduction in attack
surface compared to that available to the address book spammers
pre-p=reject.  Or, of course, they can suborn a popular Mediator (or
try to instigate one themselves).  This is still a significant
reduction in attack surface, and can be responded to surgically by
denying that Mediator v2 signatures.  If that turns into whack-a-mole
as you fear (and I admit that's a legitimate worry), *then* they have
the option of turning off all v2 signatures, or cranking the
relibility threshold way up.

This possibility of flexible response seems to me to be an important
advantage of the resigning method a priori.  Of course it can only be
proven in use.

 > domains would prefer to be proactive about such threats rather than

I'm sure they'd also like to be proactive about providing reliable
delivery from their users to whomever the user wants to send to, which
they currently have no way to do (except to reverse course on
p=reject, which apparently isn't going to happen).  That is, AFAICS,
these signatures currently are only useful to p=reject ADMDs.

---

From: Hector Santos <[email-masked]>
Date: Fri, 22 May 2015 08:54:04 -0400

On 5/21/2015 5:00 PM, John Levine wrote:
> mail.

That doesn't stop it from happening and targeting users that don't 
have the ability, capability installed, hasn't updated, etc, to do the 
"intelligence" you expect.   At the end of the day, this is a weaker 
DKIM derivative which promotes the usage of weak V1 for those who 
can't change yet and now even weaker new DKIM V2 messages.  You can be 
justify/rationalize it anyway you like, inevitably, DKIM could now be 
leveraged and exploited.  Its weaker.  It certainly put more work on 
verifiers for what you believe is a narrow problem.

That said, overall, I am satisfy that we finally got traction on a 
DKIM Policy framework for a 3rd party Resigner Authorization Protocol 
or RAP. This is another RAP song, not as secured using DNS query 
method with strong signatures, but nonetheless, a method to finally 
get this long time project completed.

The registration issue is still required if any entity wishes to 
minimize the potential exploits.

I don't plan to abandon the ATPSrev4 more secured method.  What I plan 
do to is use the ATPS DNS records as a way to signal a double sign. 
If the there a ATPS record for domain mlm.example at the domain 
author.example zone, and the mail is targeted to mlm.example then I 
will create a v2 signature preparing for the mlm.example signature. 
One registration for ATPS and V2 methods.

Learning how to add "registration" automatically is still in progress. 
  I doubt a manual process will be skipped, but that can be done via 
SMTP reply codes or by bounces returned back to the list bounce 
manager.  It can be done via an existing "too many bounces" 
notification logic preparing to unsubscribe if the user doesn't 
respond in time where it can do a restrictive domain check and report 
this to the user.

Thanks

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 22 May 2015 15:14:17 -0000

>contract spammer (rather than spamming for your own account), I would

For this to work, you somehow need to persuade the real system to send
you a signed message from the address you're planning to abuse.  That
seems like an implausible amount of work.  If you can get the real system
to send you a message to re-sign, why not just have it send the spam?

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 23 May 2015 02:04:01 +0900

John Levine writes:

 > seems like an implausible amount of work.

I agree it sounds like a lot of work.  But I don't see why you would
bother attacking the resigning system at all, if you're not trying to
exploit acquaintanceship relations.  Just send apparently from a
sibling domain.

 > If you can get the real system to send you a message to re-sign,
 > why not just have it send the spam?

Because you can't get the real system to send spam, but you can get a
user with a mailbox on that system to get it to send you a message to
resign.

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2015 13:16:59 -0400

> exploit acquaintanceship relations.  Just send apparently from a

That's just what they do, or they send from random addresses, expecting 
(usually correctly) that the recipient will only see the From: comment and 
not the bogus address.  A couple of the people on my church's mailing list 
got their AOL or Yahoo address book stolen, and the list software catches 
spam like that all the time, since if course it looks at the address.

> user with a mailbox on that system to get it to send you a message to

Right, and now you can do one teensy spam run until the weak signature 
expires, or the re-sending system's reputation drops to the point where 
nobody accepts its mail, or adaptive systems like Google's recognize the 
person's address as a reliable spam sign.  If you can't use a spamming 
system to send a million messages a day and expect a fair number of them 
to be delivered, it's not interesting.  Like I keep saying, while you can 
imagine hypothetical spam scenarios, it's hard to think of one that would 
be effective enough to be worth the effort, particularly compared to just 
using a fake address with the person's name as the From comment.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 23 May 2015 12:25:19 +0900

John R Levine writes:

 > If you can't use a spamming system to send a million messages a day
 > and expect a fair number of them to be delivered, it's not
 > interesting.  Like I keep saying, while you can imagine
 > hypothetical spam scenarios, it's hard to think of one that would
 > be effective enough to be worth the effort, particularly compared
 > to just using a fake address with the person's name as the From
 > comment.

I hope you don't mind if I say, "Hey! that's *my* line ... too."  We
can share it. :-)

But others don't agree, apparently.  I think in that context it's
worth spelling things out.  Since the detractors have made no move
whatsoever to explain their threat models[1], I guess it's on us to do
so and debunk them.

Steve

Footnotes: 
[1]  Except for "what if the spammers suborn an existing mailing
list?", but it seems to me that the possibility of resigning doesn't
really make that much more attractive than it would be in the first
place.