Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal

From: Wei Chuang <[email-masked]>
Date: Tue, 1 Jul 2014 07:27:16 -0700

Before this thread is done, let me mention a modification to this concept
to see what your opinion might be (or anyone else reading this):

You've mentioned earlier that mailing lists frequently strip content that
will preclude deployment of this concept.  This could be mitigated as
follows:

Though at the risk of making this proposal more complicated, there is a way
of dealing with this.  The proposal could say to extend the DKIM to support
the signing only certain stable MIME parts such as: Content-Type:
text/plain that are unlikely to get stripped (or other base alternate
part).  This also signs the MIME multipart metadata to detect stripping,
and as before the headers.  Diffs are only made of the signed parts.  The
upside is this still provides forwarding trust chaining, and allows the
recipient to reconstruct the text forwarding versions.  This  text
typically should get at the meaning of sender, and can then be verified
against the alternate formats such as HTML not signed.  The downside non
text formatting such as HTML will become a Spam / Phishing attack vector.
 Also this will requires an extension to DKIM to allow these restricted
body MIME part signings.

Thanks,
-Wei

On Mon, Jun 30, 2014 at 11:52 AM, John R Levine <[email-masked]> wrote:

> Forced on list managers, but not on MUA authors.  If we can get MUA
>>> authors to change the way they display list mail, we could do something
>>> much simpler like the message wrapping that's an option in recent
>>> versions
>>> of Mailman.
>>>
>>
>> With message wrapping, my understanding is it wraps the original message
>> in
>> a MIME part.  If that's the case, then that's pretty much the storage (or
>> more) of doing the diff.
>>
>
> There's a major practical difference: the message wrap hack is essentially
> a single message digest. List managers already have code to build digests,
> and MUAs can display them, if not always very beautifully.  Lists do not
> have code to save the original message, then later use some diff'ing
> algorithm to create new message parts that no MUA knows how to display.
>
>
>  I just don't seem them (us, really) implementing something as complex as
>>> your proposal, particularly if it turns out that it needs a lot of
>>> tweaking
>>> to avoid false positives.
>>>
>>
>> Actually this proposal is supposed to resolve the tweaking that is needed
>> today with DMARC.  What tweaking do see you will be required?
>>
>
> Incoming mail filters will have to look at the diffs and apply some yet to
> be invented heuristics to analyse the them and decide whether the before
> and after versions are "too different".  I have no idea what a satisfactory
> definition of "too different" is, and would be surprised if anyone else
> did.  There isn't even a generally accepted version of diff syntax --
> programs like the freeware "patch" have extensive heuristics to try to
> decode all of the various diff formats they have to deal with.
>
> Anyway, the two of us have been arguing in a vacuum.  Let's see what other
> people thing.
>
>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>

---

From: "John R Levine" <[email-masked]>
Date: 1 Jul 2014 12:29:34 -0400

> and as before the headers.  Diffs are only made of the signed parts.

When we were working on DKIM, we spent a lot of time looking at more 
complex canonicalizations that would exclude some parts of the message, 
and pretty much gave up.  The issue isn't just picking what parts to 
include, but which excluded parts an attacker might add that would be 
rendered by MUAs.

I still think it is very unlikely that small mail systems would ever 
implement something this complex.  If the impediment to using double 
signing by forwarders is figuring out who the forwarders are, that could 
be handled by DNSWLs.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jul 2014 11:58:02 -0700

I posted a draft that captures an idea originally proposed by Ned Freed:

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/

It's a canonicalization that hashes each piece of the MIME structure
individually, as a tree.  This allows for easy detection of modifications
of an individual part, or of a subtree.  It's also able to withstand
encoding changes so long as the encoded content itself isn't changed.

In an ideal world, Mediators like lists that want to add content would do
so by adding a new text/plain part, and MUAs would render them properly.
With this canonicalization, DKIM verifiers could identify any added content
easily, determine whether it's safe, and then decide whether to consider
the signature valid based on that.  But I realize how much cooperation is
needed to meet that ideal.

-MSK

On Tue, Jul 1, 2014 at 9:29 AM, John R Levine <[email-masked]> wrote:

> complex canonicalizations that would exclude some parts of the message, and
> pretty much gave up.  The issue isn't just picking what parts to include,
> but which excluded parts an attacker might add that would be rendered by
> MUAs.
>
> signing by forwarders is figuring out who the forwarders are, that could be
> handled by DNSWLs.
>
>
> Regards,
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 Jul 2014 15:46:09 -0700 (PDT)

> I posted a draft that captures an idea originally proposed by Ned Freed:

I think Merkle got there first on the whole tree thing, but whatever.

> encoding changes so long as the encoded content itself isn't changed.

Surviving encoding changes was the original motivation for doing this,
albeit in the context of multipart/signed, not DKIM.

				Ned

---

From: Wei Chuang <[email-masked]>
Date: Wed, 2 Jul 2014 11:03:20 -0700

Preliminaries: I think the main difference is that OP proposal tries to
recover the earlier content, but if one doesn't need that as with the
canonicalization approach it can be quite compact and less invasive for the
implementor.

That said: In section 5 of the canonicalization draft it refers to
explicitly two DKIM signatures one for the original author and the other
for the MLM.  Could more than one MLM signers be allowed?  Also perhaps
DKIM signature headers should have a field to assist in describing its
purpose such as original author signature vs resigner?

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2014 15:18:19 -0400

> purpose such as original author signature vs resigner?

Any MTA that handles a message can add DKIM signatures on the way through. 
It is normal to add more than one signature; my lists add one for the list 
domain and one for lists.iecc.com, the domain of the MTA that handles all 
the list mail.  A specific design decision in DKIM (albeit one that a lot 
of people seem to have trouble with) is that the signature d= need have no 
connection to anything else in the message. You can add all of the extra 
informative tags you want, although in practice informative tags don't 
seem to be very useful other than for debugging.

The original plan was that the list would sign its outgoing mail, and 
recipients would recognize the list and its good reputation to deliver the 
mail.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2014 17:25:28 -0400

> albeit in the context of multipart/signed, not DKIM.

I believe that it lets you sign each MIME part separately, but that's only 
one step toward something that survives mailing lists.  There's still the 
problem of looking at the incoming message and deciding whether it's still 
similar enough to the message that was signed.

I'm fairly confident that for any rule you can invent that would allow the 
normal mailing list changes, I can construct egregious spam that it would 
permit.  There's a huge variation in what lists do, and a lot of what they 
do, e.g., adding text to the front of the body, is not very different from 
what a malicious faux list would do.

Basically, this plan needs a second layer of semantics to decide what's 
"the same".  The double signing approach needs a second layer to say which 
forwarders are credible.  I don't see any reason to think this second 
layer would be more tractable, and the underlying mechanisms are much more 
complicated.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2014 14:43:20 -0700

On Jul 2, 2014, at 2:25 PM, John R Levine <[email-masked]> wrote:

> I believe that it lets you sign each MIME part separately, but that's only one step toward something that survives mailing lists.  There's still the problem of looking at the incoming message and deciding whether it's still similar enough to the message that was signed.
> 
> I'm fairly confident that for any rule you can invent that would allow the normal mailing list changes, I can construct egregious spam that it would permit.  There's a huge variation in what lists do, and a lot of what they do, e.g., adding text to the front of the body, is not very different from what a malicious faux list would do.
> 
> Basically, this plan needs a second layer of semantics to decide what's "the same".  The double signing approach needs a second layer to say which forwarders are credible.  I don't see any reason to think this second layer would be more tractable, and the underlying mechanisms are much more complicated.

Dear John,

Agreed.

A single DNS transaction is possible with TPA-Label.  This scheme offers a solution using smaller DNS resources than other proposed schemes even while solving back-office service issues that make use of the Sender header without modifying any DKIM operation.  

Regards,
Douglas Otis

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 02 Jul 2014 23:53:32 +0200

On 07/02/2014 11:25 PM, John R Levine wrote:
> I believe that it lets you sign each MIME part separately, but that's 
> only one step toward something that survives mailing lists.  There's 
> still the problem of looking at the incoming message and deciding 
> whether it's still similar enough to the message that was signed.
>
> I'm fairly confident that for any rule you can invent that would allow 
> the normal mailing list changes, I can construct egregious spam that 
> it would permit.  There's a huge variation in what lists do, and a lot 
> of what they do, e.g., adding text to the front of the body, is not 
> very different from what a malicious faux list would do.
>
> Basically, this plan needs a second layer of semantics to decide 
> what's "the same".  The double signing approach needs a second layer 
> to say which forwarders are credible.  I don't see any reason to think 
> this second layer would be more tractable, and the underlying 
> mechanisms are much more complicated.

In the past that second layer has been called 'reputation' and I'm 
pretty sure that most mailing lists, adding their own DKIM signature, 
will have no problem in surviving a reputation check. The problem here 
is the 'on/off' or 'black vs white' nature of DMARC's p=reject. 
Reputation is seldom black/white, most of the time it's somewhere in 
between.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jul 2014 15:05:25 -0700

On Wed, Jul 2, 2014 at 2:53 PM, Rolf E. Sonneveld <
[email-masked]> wrote:

>
> In the past that second layer has been called 'reputation' and I'm pretty
> sure that most mailing lists, adding their own DKIM signature, will have no
> problem in surviving a reputation check. The problem here is the 'on/off'
> or 'black vs white' nature of DMARC's p=reject. Reputation is seldom
> black/white, most of the time it's somewhere in between.
>

I believe that's consistent with the notion that things like DKIM, SPF, and
DMARC are often merely inputs to a larger evaluation engine, which also
takes things like reputation into account.  It's precisely why the DMARC
spec calls out the ability for policy exceptions, at the discretion of the
receiver.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2014 18:47:27 -0400

>> problem in surviving a reputation check. ...

> spec calls out the ability for policy exceptions, at the discretion of the

Originally I thought that list reputation would be stable enough that 
recipients should just deliver the fripping mail.  Then someone at Gmail 
told me that they've seen spear phishing through forwarders.  That's the 
threat that double signing or even O-A-R addresses.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2014 15:50:28 -0700

On Jul 2, 2014, at 3:47 PM, John R Levine <[email-masked]> wrote:

> Originally I thought that list reputation would be stable enough that recipients should just deliver the fripping mail.  Then someone at Gmail told me that they've seen spear phishing through forwarders.  That's the threat that double signing or even O-A-R addresses.

Dear John,

Agreed.  That is why the option to include O-A-R in TPA-Label was added to permit a safer level of remediation when needed.

Regards,
Douglas Otis

---

From: Wei Chuang <[email-masked]>
Date: Thu, 3 Jul 2014 07:26:22 -0700

On Wed, Jul 2, 2014 at 12:18 PM, John R Levine <[email-masked]> wrote:

> connection to anything else in the message.

I think this is a really nice feature of RFC6376 DKIM to have the SDID
domain not tied to RFC5322.FROM, and one I intended to use in the remainder
of my proposal.

> You can add all of the extra informative tags you want, although in
> practice informative tags don't seem to be very useful other than for
> debugging.
>

Recipients can only act on them if the tag is standardized.  In the context
of my proposal but perhaps useful in others, is the notion to identify the
original sender signature and find whether the mail is in the original form
to determine the original senders intent.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 7 Jul 2014 11:20:19 -0700

I'm sorry I missed the significance of the MIME tree hashing in
draft-kucherawy-dkim-list-canon with respect to the DKIM diff proposal.  A
common place action that mailing lists do, is to strip a MIME part e.g.
text/html.  MIME tree hashing is particular good at recognizing that a part
has been removed leaving other parts unchanged.  If the removed part is
within a MIME multipart/alternative, then the change is acceptable as the
information can be found in another part, and the message can pass.  Using
the MIME tree hashing means that the diff for the removed part won't be
needed as the tree hash will indicate this and protect the unchanged
sections.  However if a part is added, a diff should still be required in
this proposal for spam analysis by the final recipient. (I wonder if it
would be helpful if mailing-lists publish the static content they intent to
add to messages via some DNS record...)

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 7 Jul 2014 15:01:50 -0400

> However if a part is added, a diff should still be required in

Assuming the list signs its outgoing mail, there's no question that the 
modified message came from the list, so I don't see what that would add.

Once again, this very complicated approach will only be useful if you can 
mechanically describe the how to tell modified messages that are "too 
different" from messages that are not.  Please give us some hints about 
how that would work.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Mon, 7 Jul 2014 15:21:24 -0400

It has been historical acceptable for a backend to strip a multi-part alternative type .i.e. text/html, with the design presumption, the plain text context expresses the same meaning and interpretation. It would be the same idea of just having different readers display fonts.  For security reasons and also backward compatibility, the operator had control on the local mail storage policy including in what format it will be saved for its end users.   It was not just security but there with storage limits, boundaries too.

In fact, I don't think it is a given user right that "wysiwyg" was ever a guarantee.   Perhaps today, we have more confidence in the security aspect of MUAs. The controls are in place to protect users from client side scripting exploits, so we keep with raw "as is" RFC5322 storage.  For example, in our package, after many years of only operator control, the user can now choose how the backend hosting server should save direct private mail.  Of course, it is probably common for MUAs to have a text vs simple HTML vs raw HTML display options. This is also based on the idea that all modes provide the user with equivalent context reading.

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

> On Jul 7, 2014, at 2:20 PM, Wei Chuang <[email-masked]> wrote:
> 
> I'm sorry I missed the significance of the MIME tree hashing in draft-kucherawy-dkim-list-canon with respect to the DKIM diff proposal.  A common place action that mailing lists do, is to strip a MIME part e.g. text/html.  MIME tree hashing is particular good at recognizing that a part has been removed leaving other parts unchanged.  If the removed part is within a MIME multipart/alternative, then the change is acceptable as the information can be found in another part, and the message can pass.  Using the MIME tree hashing means that the diff for the removed part won't be needed as the tree hash will indicate this and protect the unchanged sections.  However if a part is added, a diff should still be required in this proposal for spam analysis by the final recipient. (I wonder if it would be helpful if mailing-lists publish the static content they intent to add to messages via some DNS record...) 
> 
> -Wei
> 
>

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 14:09:01 -0700

Sorry for the delay in replying to this.  I also wanted to address a
concern Hector had with regards to motivating the technique so the response
adds that too.

On Mon, Jul 7, 2014 at 12:01 PM, John R Levine <[email-masked]> wrote:

> different" from messages that are not.

There's an example below, plus more details on the integration.  While
writing it up, I realized there's another alternative approach, so wrote a
brief description as well.

-Wei

> Please give us some hints about how that would work.

> Please consider the environment before reading this e-mail.

This write up does three things:

1) Provide motivation for DKIM Forwarding Provenance proposal while
providing some refinements

2) Reducing diff overhead due to content stripping with via incorporating
draft-kucherawy-dkim-list-canon-00

3) Alternatively reducing diff overhead via forwarder policy proposal

1). The case for enhancing DKIM with DKIM Forwarding Provenance

Recall that the earlier proposal is to provide diffs of before and

after a forwarder modifies the message, for all forwarders, such that

one can recursively apply the reverse patch to recover the original

message for spam analysis.  The sender and each forwarder DKIM signs

the message such that the final recipient can verify the authenticity

of each version all the way back to the original sender.

A minimal implementation of this technique would use DKIM to sign

important header fields such as: from, to, cc, date, subject,

dkim-signature (implicitly) leaving aside other headers and the body.

The From header is useful for looking up the sender's policy

(e.g. DMARC and other similar proposals such as dkim-ssp).  An

important aspect of those policies is to describe what to do about

messages that fail verification.  The From header is also important in

establishing the reputation of the original sender for Spam filtering.

The To/Cc header is important in interpreting the original

destination, and the user's authorization of the message

travelling along some path. (Note that the Bcc case is handled later).

Our approach contrasts to others that asks the sender to designate

pre-authorized forwarders/mailing-lists either through DNS

(otis-tpa-labels), or by secondary signing with an authorized delegate

specified via header (levine-dkim-conditional).  The relationships in

those proposals must be predefined with the originating sender at

sending time.  The Date header can be useful in preventing replay

attacks.  An adversary may take a DKIM signed message and resend it,

however a recipient could use the Date header written by the original

sender to check if the message has likely been resent by outside of

the normal mail delivery period where that period might be defined

implicitly by the recipient or explicitly by the sender via some

policy described later.  Protecting the Subject header is important

for UX of the recipient.  Again the key is tracking these header

fields all the way back to the original sender.

Using DKIM signing to protect additional header fields can provide

further security benefits.  We propose two new optional header fields:

1) trace-path: 2) orig-security-policy:

The Trace-path header describes the forwarders immediate destination

domain, can be used to trace the delivery path in a secure way due to

DKIM signing as well enforce a strict alignment between different

authentication methods.  To trace an edge in the path i.e. from some

sender to its immediate destination, the trace-path destination domain

should match the destination's dkim-signature "d=" domain.  One can

repeat this from the originating sender to the final recipient to find

the delivery path.  When this header is employed, then the recipient

must verify the consistency of the immediate senders trace-path header

i.e. matching the current domain to the trace-path header domain.  The

recipient must also apply a sender consistency check using SPF to

verify the sender to prevent spoofing, and may want to verify that the

DKIM domain matches the SPF return path domain.  The trace-path

headers must be signed by DKIM.  This path information is useful to

reduce replay attacks by explicitly exposing each delivery path

forwarder and allowing spam filters to eliminate messages from abusive

forwarders.  Exposing the destination domain but not the destination

user also provides intent information in the Bcc case while protecting

privacy of the Bcc user.

The orig-security-policy header is used to describe any override of to

the existing security policy e.g. from the DMARC DNS record.  Such a

policy could describe what to do upon error e.g. DMARC's policy none,

quarantine, or reject.  Allowing a per message override can help

mitigate deployment issues if the sender knows that the recipient has

lower capabilities than the desired security profile, and knows that a

particular email message can tolerate a lower security profile.  It

can also describe whether to tolerate DKIM differences due to content

stripping such as attachment removal or alternate part stripping, and

whether to tolerate missing trace-path headers as they might not be

supported by some forwarders.

This proposal does not preclude DKIM signing of other headers nor

preclude the body part.  Whether to sign other parts depends on the

tolerance desired by the original sender of various types of allowed

modifications, and the desired security profile.  This is discussed in

detail later.

By being able to walk through each forwarding versioning via applying

patch, the recipient can identify what was added by each forwarder.

The can also allow senders to add and remove headers knowing that they

are preserved for the recipient which can be useful if having multiple

instances of one header type problematic.  For example, if the from

header is modified, it would be ambiguous to keep multiple copies.

Another example is resent-from header where RFC4407 suggests that only

one should be allowed per message, yet RFC5322 suggests any additions

should be retained.  Diff versioning could reconcile that.  Another

use is tolerating small changes caused by implementation differences

such as adding whitespaces, as the diff can be used to obtained the

DKIM aligned version.

One issue with diffs is that mailing lists and forwarder may strip

content such as alternative representations or attachments to reduce

the message size or to reduce compatibility support needed.  In the

base diff algorithm, this will result in very large diffs which

defeats the purpose desired by the forwarder.  In the next two

sections, we discuss two approaches for tolerating these changes

efficiently.

2). Incorporating draft-kucherawy-dkim-list-canon-00

(http://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00)

This proposal creates a new representation for DKIM that specifies a

mime tree, where each node has a hash of its content.  Because now

each mime part is explicit it can better tolerate removals of mime

parts.

When incorporating this approach, we still insist on the ability to

obtain earlier message versions whose signing is still DKIM

verifiable.  This might be accomplished by having multiple signatures

that simulate the removal of certain parts likely to be stripped by

mailing lists such as alternative parts or attachments.  The various

scenarios are described to the recipients as multiple DKIM headers

with different "lh=" fields.  When a section is stripped with a

supporting scenario, no difference will be taken for that part.  The

recipient that wants to reconstruct the original message will search

through the dkim-signatures to find the matching header for the

remaining parts.

The following example of RFC5322 messages illustrates the basic

originating senders message with draft-kucherawy-dkim-list-canon-00.

The originating sender formats a message with basic text and HTML, and

has the message signed with the two alternative

draft-kucherawy-dkim-list-canon-00 signatures: one for the complete

message and one with the HTML stripped:

  DKIM-Signature: d=mymail.com
lh=<hash1>:text/plain:0,<hash2>:multipart/mixed:2,<hash3>:text/html:0

  DKIM-Signature: d=mymail.com
lh=<hash1>:text/plain:0,<hash2>:multipart/mixed:1

  From: [email-masked]

  To: [email-masked]

  Subject: I'm testing how DKIM forwarding history versioning works.

  Content-Type: multipart/mixed;

  boundary="AAA123"

  --AAA123

  Content-Type: multipart/alternative;

  boundary="ALT321"

  --ALT321

  Content-Type: text/plain; charset=US-ASCII

  Content-Transfer-Encoding: 7bit

  This example illustrates how using diff and patch can obtain the message
versions.

  -Sender

  --ALT321

  Content-Type: text/html; charset=US-ASCII

  Content-Transfer-Encoding: 7bit

  <div dir="ltr">This example illustrates how using diff and patch

  can obtain the message versions.

  <div>-Sender</div></div>

  --ALT321--

  --AAA123

  Content-Type: multipart/dkim-forwarding-history;

  boundary="DFH456"

  --DFH456--

  --AAA123--

So when this sent to a mailing list at yourgroup it strips the html

part.  It notes the alternative signature, and finds no difference for

the stripped HTML part, but does so for the modified subject line.

The mailing list message claims ownership of the message by signing

with DKIM of the modified message.

  DKIM-Signature: d=yourgroup.com
lh=<hash1>:text/plain:0,<hash2>:multipart/mixed:1

  From: [email-masked]

  To: [email-masked]

  Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.

  Content-Type: multipart/mixed;

  boundary="AAA123"

  --AAA123

  Content-Type: multipart/alternative;

  boundary="ALT321"

  --ALT321

  Content-Type: text/plain; charset=US-ASCII

  Content-Transfer-Encoding: 7bit

  This example illustrates how using diff and patch can obtain the message
versions.

  -Sender

  --ALT321--

  --AAA123

  Content-Type: multipart/dkim-forwarding-history;

  boundary="DFH456"

  --DFH456

  Content-Type: text/plain; charset=US-ASCII

  Content-Transfer-Encoding: 7bit

  Content-Disposition: attachment;

  filename="message-14July2014_1301.patch"

  *** mymail.txt          2014-07-14 12:54:01.827650000 -0700

  --- yourgroup.txt       2014-07-14 12:55:00.529772000 -0700

  ***************

  *** 1,2 ****

  - DKIM-Signature: d=mymail.com
lh=<hash1>:text/plain:0,<hash2>:multipart/mixed:2,<hash3>:text/html:0

  - DKIM-Signature: d=mymail.com
lh=<hash1>:text/plain:0,<hash2>:multipart/mixed:1

  --- 0 ----

  ***************

  *** 5 ****

  ! Subject: I'm testing how DKIM forwarding history versioning works.

  --- 3 ----

  ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.

  --DFH456--

  --AAA123--

3). Forwarder Policy Proposal

An alternative approach to supporting forwarder content policies is to

have the forwarder advertise its content and security capabilities via

a DNS TXT record.  It is then up to the originating sender to send a

message compatible with that profile.  The originating sender MUA can

lookup the profile via DNS and alternatively let the user know what

the forwarder's the content policy who can then choose to

accept/reject such a policy, or the MUA can automatically match the

profile for the user.  For example the profile might say that the

forwarder will strip attachments and HTML formatting, and the sender

MUA will then match the profile by stripping the attachment and HTML.

This DKIM signed message incorporates the compatible profile.  Other

content policies might describe supported transfer-encodings and

charsets, while security policies might include whether trace-path

header is supported.

This approach has the advantage in that it pushes more responsibility

to the sender from the forwarder/mailing-list.  As often the sender is

the motivated party to maintain a certain secure profile, this may be

a good division of labor.  Also such profiles may provide better user

experience overall as the sender is immediately aware of the

intermediary capabilities, and can mitigate as necessary.

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2014 17:31:03 -0400

Thanks, but as far as I can tell it still doesnn't address the key 

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 15:31:27 -0700

On Mon, Jul 14, 2014 at 2:31 PM, John R Levine <[email-masked]> wrote:

> Thanks, but as far as I can tell it still doesnn't address the key concern:

Which I had thought was complexity.  The " 3) Alternatively reducing diff
overhead via forwarder policy proposal" would help in that regards.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2014 18:35:38 -0400

> Which I had thought was complexity.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 16:13:20 -0700

>>>> different" from messages that are not.

It is assumed that we take approach " 3) Alternatively reducing diff
overhead via forwarder policy proposal", where the originating sender must
make a compatible message with the mailing list i.e. remove attachments or
strip content as necessary.

The final recipient can then verify the received message using the existing
DKIM signature verification.  To obtain the version seen at the input to
the mailing list or other intermediary, the recipient applies a reverse
patch of the contents of multiplepart/dkim-forwarding-history.  These
patches are ordered from the earliest and to most recent with respect to
the final recipient, and applied in reverse order.  At each step, the
recipient can check for DKIM signature verification.  Different is defined
as failing signature verification.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2014 19:30:21 -0400

> strip content as necessary.

Here's some concrete questions:

* If the forwarder adds text to the end of the body, should the recipient 
accept the message?

* If the forwarder adds a new body part at the top containing text, should 
the recipient accept the message?

* If the forwarder adds a new body part at the top and another body part, 
should the recipient accept the message?

* If the forwarder removes parts containing PNG images and replaces them 
with JPEG images, should the recipient accept the message?

etc.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 16:41:14 -0700

> with JPEG images, should the recipient accept the message?

Determination of the legitimacy of the changes is for the recipient's spam
filters.

-Wei

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Jul 2014 16:43:55 -0700

> with JPEG images, should the recipient accept the message?

During the original development of DKIM, we included a "z=" tag that
allowed the signer to include a copy of the signed header fields as they
were at the time of signing.  We also decided at the time that considering
the message valid if using the original header fields (versus the received
ones) passed was not a good idea; the value of "z=" was purely diagnostic.
The intent was that the message is meant to validate as it arrives, or not
at all.  I don't know if that logic still holds given today's realities,
but that's where we are with the standard.

Assuming for the moment that we've got a more lenient stance now, it would
seem that we're talking about enabling a verifier to tell downstream agents
(in this case, MUAs) which parts of a multipart were covered by a valid
signature and which weren't.  It follows that we're assuming those agents
want to do something with that information, such as highlighting the parts
of the rendered multipart that might be unsafe.  One could do the same
thing with the list-canon draft I submitted earlier.

So the answer to all of the above might be to show the protected parts in a
way that distinguishes them from the unprotected parts.

Yes, I realize we're wandering into MUA space, to which the IETF is
traditionally allergic, but I also recognize that Gmail lives in both
spaces and might have something interesting to suggest here, especially in
the "running code" sense.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2014 19:45:47 -0400

> Determination of the legitimacy of the changes is for the recipient's spam

That's my point: I don't see any way to do that and be able to distinguish 
innocent text added by a real mailing list from malicious text added by a 
fake mailing list without body filtering the message.

If you're just going to scan for keywords and do body filtering anyway, 
what's the point of all of the change history?

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Jul 2014 17:04:08 -0700

On Mon, Jul 14, 2014 at 4:43 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> So the answer to all of the above might be to show the protected parts in
> a way that distinguishes them from the unprotected parts.
>

Also: We went to some pain to make it clear in the movement to Draft
Standard that the primary output of DKIM signature verification is simply a
domain name.  In a protocol sense, which bits of the message were covered
by that signature is not part of what's communicated to whatever gets the
message next.  Being able to tell an MUA (or whatever) that only particular
header fields or body parts were covered by a valid signature is a
substantial shift in design.  If we decide to go down this road, that will
need to be addressed as well, and I'm not sure a canonicalization
definition is enough to do so.

-MSK

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 17:05:10 -0700

On Mon, Jul 14, 2014 at 4:43 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> * If the forwarder adds a new body part at the top containing text,
> signature and which weren't.
>

Or to have multiple DKIM signatures signing for different likely header and
body part profiles so that there isn't an unprotected part, and have the
downstream pick one that applies.

It follows that we're assuming those agents want to do something with that
> information, such as highlighting the parts of the rendered multipart that
> might be unsafe.  One could do the same thing with the list-canon draft I
> submitted earlier.
>

Agreed.

-Wei

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Jul 2014 17:16:13 -0700

On Jul 14, 2014, at 4:13 PM, Wei Chuang <[email-masked]> wrote:

> It is assumed that we take approach " 3) Alternatively reducing diff overhead via forwarder policy proposal", where the originating sender must make a compatible message with the mailing list i.e. remove attachments or strip content as necessary.
> 
> The final recipient can then verify the received message using the existing DKIM signature verification.  To obtain the version seen at the input to the mailing list or other intermediary, the recipient applies a reverse patch of the contents of multiplepart/dkim-forwarding-history.  These patches are ordered from the earliest and to most recent with respect to the final recipient, and applied in reverse order.  At each step, the recipient can check for DKIM signature verification.  Different is defined as failing signature verification.

Dear Wei,

Firstly, this creates a significant burden for both recipients and third-party services who may not considered these additional complexities beneficial. 

Secondly, the resulting message will not offer additional protections unless recipients are able to examine resulting versions which is likely to result in greater confusion. 

Thirdly, this approach is unable to handle back-office services that are making valid use of the Sender header field.

Regards,
Douglas Otis

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 19:19:13 -0700

On Mon, Jul 14, 2014 at 5:16 PM, Douglas Otis <[email-masked]> wrote:

> The final recipient can then verify the received message using the
> existing DKIM signature verification.  To obtain the version seen at the
> input to the mailing list or other intermediary, the recipient applies a
> reverse patch of the contents of multiplepart/dkim-forwarding-history.
>  These patches are ordered from the earliest and to most recent with
> respect to the final recipient, and applied in reverse order.  At each
> step, the recipient can check for DKIM signature verification.  Different
> is defined as failing signature verification.
>
>
> Dear Wei,
>
> Firstly, this creates a significant burden for both recipients and
> third-party services who may not considered these additional complexities
> beneficial.
>

Indeed- many of these authentication methods add burden for all parties.
But I think we all agree that Spam and Phishing are becoming more
problematic, and that some sort of authentication method can mitigate this.
 We are just making a proposal that attempts to provide strong
authentication that tries to minimize this burden. (Yes I know you and
others disagree about the burden)

>
> Secondly, the resulting message will not offer additional protections
> unless recipients are able to examine resulting versions which is likely to
> result in greater confusion.
>

If such recipients are not aware of the proposed provenance method, they
can still apply RFC6376 DKIM verification.

> Thirdly, this approach is unable to handle back-office services that are
> making valid use of the Sender header field.
>
>
I'm sorry I didn't follow this example.  Can you expand this point?

thanks,
-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 19:35:34 -0700

> what's the point of all of the change history?

It matter who writes what.  The originating sender has different rights to
the message than say the forwarder.  Say the keywords "Viagra pills" are
found to be well correlated with spam.  If the mailing list appends this in
the footer is this message spam? However if a known originating sender who
in the past has a good reputation sends "Viagra pills" in the message, is
that spam?  I would say the former is likely spam, while the former is not.
 Even if the mailing list has a good reputation, it should be suspect.

thanks
-Wei

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2014 23:18:57 -0400

> Even if the mailing list has a good reputation, it should be suspect.

That's completely backwards.

I've been running mailing lists for at least 20 years, and in practice the 
reputation of the list is much, much more stable than the reputation of 
the individual subscribers when deciding what to deliver.

The chance that a list has suddenly turned rogue is much lower than the 
chance that a subscriber's account was compromised.  That's why you 
occasionally see spam from my 100% clean opt-in church mailing list: some 
member's mail account got hacked, nothing happened to the list.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 20:20:17 -0700

thanks
-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 23:04:48 -0700

> That's completely backwards.

It's likely I do have that backwards as I'm not on the spam-team side of
things here.

> reputation of the list is much, much more stable than the reputation of the
> individual subscribers when deciding what to deliver.
>

But I think you're helping me prove my other point which is knowing who it
is doing the update matters.  Your policy could very well be better than
what I suggested, which is all to the better for your service.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 14 Jul 2014 23:21:12 -0700

On Mon, Jul 14, 2014 at 5:04 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> Assuming for the moment that we've got a more lenient stance now, it
>> would seem that we're talking about enabling a verifier to tell downstream
>> agents (in this case, MUAs) which parts of a multipart were covered by a
>> valid signature and which weren't.  It follows that we're assuming those
>> agents want to do something with that information, such as highlighting the
>> parts of the rendered multipart that might be unsafe.  One could do the
>> same thing with the list-canon draft I submitted earlier.
>>
> message next.

I might be confused here, but there is the "h=" field.  Now I agree, the
reason for why an arbitrary header is mentioned in "h=" (besides from and
dkim-signature) is not described by RFC6376 AFAIK.

>   Being able to tell an MUA (or whatever) that only particular header
> fields or body parts were covered by a valid signature is a substantial
> shift in design.  If we decide to go down this road, that will need to be
> addressed as well, and I'm not sure a canonicalization definition is enough
> to do so.
>

Agreed.  In particular one worry is that not signing certain sections but
including it in the message is a vulnerability that could be exploited.
 More so since the recipient assumes that the message has been
authenticated via DKIM.

-Wei

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Jul 2014 09:41:35 -0700

> dkim-signature) is not described by RFC6376 AFAIK.

Section 5.4 of RFC 6376 talks about selecting which fields to sign.
However, since we defined DKIM as returning nothing more than the value of
"d=" to whoever asked for verification, we should assume that current
implementations aren't capable of exposing the "h=" value (or any other) to
the caller.  That's what I meant by a possibly serious design shift here.

It may well be the case that most or all current implementations do offer
that capability.  That would be wonderful, but if we're going to begin
relying on that generally, we should probably update the standard.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2014 20:17:51 -0000

I put an item on my blog that tries to characterize various mail
forwarding scenarios into eight categories.  I think it might be
useful for evaluating various proposals intended to help manage
handling and authentication of forwarded mail.

http://jl.ly/Email/fwdthreat.html

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 19 Jul 2014 10:51:42 -0700

(reposting from the right "from" address)

On Sat, Jul 19, 2014 at 10:50 AM, Kurt Andersen <[email-masked]> wrote:

> On Fri, Jul 18, 2014 at 1:17 PM, John Levine <[email-masked]> wrote:
>
> I'm not sure that this taxonomy is quite that helpful, nor that the
> examples are indicative of anything more than laziness.  Any ESP that does
> not ensure some sort of authentication for the content that they send is
> guilty of negligence; and there is no reason that "forward an article"
> should be spoofing the address of the person asking for the send - most do
> not.
>
> I think that the operative concepts are whether the "last sending" system
> takes ownership for the message (as advocated by the marginally useful SRS
> concept) or tries to be "transparent".  If they try to be transparent, then
> we have the potential for problems since the "chain of custody" becomes
> questionable.
>
> --Kurt Andersen
>

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2014 14:02:24 -0400

> should be spoofing the address of the person asking for the send - most do

Hi, Kurt.  I realize this is the position of some DMARC advocates, but 
each of your statements is factually wrong.

Every ESP I know uses SPF and DKIM to authenticate their outgoing mail, 
but for the ESPs who mail for tiny customers, girl scout troops and the 
like, their customer's only address is often at a freemail provider. For 
those users, the ESP's authentication isn't enough to prevent rejection by 
DMARC, a limitation of which we are all painfully aware.  I know of one 
large ESP who got a signing key from a large freemail provider, but that 
obviously doesn't scale.

Forward an article isn't "spoofing" anything when a real user forwards an 
article using his real address, and it is deeply Orwellian to try to 
redefine terms this way.  It's not authenticated by the owner of the From: 
domain, but that's different.  In DMARC-ese, it's "unaligned".

And your claim that most do not is just wrong -- look at the Wall Street 
Journal as a counterexample.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Sun, 20 Jul 2014 09:11:53 -0700

Thanks for putting that together, and I think its a good starting point for
creating an objective set of criteria for evaluating the multitude of DKIM
/ DMARC repair / enhancement proposals.  Indeed I'd like to understand in
the near future how the different proposals stack up against particularly
GAB, BAG and BAB, though the latter two as you point out are unlikely.
 Would it be easier to read as <sender><auth-state><forwarder>?  As
extensions to this approach: I also wonder about replay spam vector, and
whether they need some sort of distinction in this taxonomy, or otherwise
they are just GAB.  I also wonder if there is an objective measure of
implementation complexity for forwarders, that could also be considered.
 Some factors might be: use of DNS, federation or cooperation between
providers, amount of additional processing at the forwarder, (and also
sender and recipient complexity) beyond baseline DKIM / DMARC, etc.

thanks,
-Wei

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 19 Jul 2014 10:50:05 -0700

--Kurt Andersen