Subject: Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Jun 2011 18:50:46 -0700

Background on preceding DKIM work--

RFC4686 Introduction states:
,---
The DKIM protocol defines a mechanism by which email messages can be 
cryptographically signed, permitting a signing domain to claim 
responsibility for the use of a given email address.
'---

While several threats to DKIM were considered, multiple From header 
fields were neglected.  This document only focused on use of multiple 
addresses within the From header field.

RFC5585 Introduction states:
,---
DKIM allows an organization to take responsibility for a message in a 
way that can be verified by a recipient. [..] It permits verification of 
the signer of a message, as well as the integrity of its contents.  DKIM 
will also provide a mechanism that permits potential email signers to 
publish information about their email signing practices; this will 
permit email receivers to make additional assessments of unsigned 
messages.  DKIM's authentication of email identity can assist in the 
global control of "spam" and "phishing".
'---

It should be noted that Signing Practices are referenced off a domain 
found in the From header field which also assumes only one will be present.

RFC2119 definition
,---
SHOULD
This word, or the adjective "RECOMMENDED", mean that there
may exist _valid_ reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
'___

Section 3.8 Input Requirements states that verifiers SHOULD take 
reasonable steps to ensure that the messages they are processing are 
valid according to RFC5322, RFC2045, and any other relevant message 
format standard.

Section 8.14 Attacks Involving Addition of Header Fields

acknowledges:
,---
Many email implementations do not enforce [RFC5322] with strictness as 
discussed in Section 5.3 (Normalize the Message to Prevent Transport 
Conversions), DKIM processing is predicated on a valid
mail message as its input.  However, DKIM implementers should be aware 
of the potential effect of having loose enforcement by email components 
interacting with DKIM modules.
'___

and further states:
,---
An MUA then might elect to render to the user the
value of the first, or "top", From: field.  This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result.  Such code in an MUA can
be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters.  Such is
the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated.  (This can also be taken as a
demonstration that DKIM is not designed to support author
validation.)
'___

This indicates the DKIM specification is seriously flawed.  While DKIM 
may not offer author validation, it was intended to establish an 
accountable domain for the signed message content that at a minimum 
includes the From header field.  There are NO valid reasons for a valid 
signature to include multiple From header fields!  Allowing multiple 
 From header fields is _EVIL_ and destroys DKIM's intended purpose as 
defined by prior work.

Free email providers likely use DKIM to gain increased acceptance by 
taking advantage of their "too big to block" volumes.  For these 
domains, their reputation is understood to offer little assurance of 
their overall integrity while perhaps limiting what is allowed in the 
domain portion of the From header field.

By allowing a pre-pended From header field to not affect the validity of 
a DKIM signature according to the specification means the UNDERSTOOD 
source of a message can NEVER be trusted through the aid of DKIM.

Those that phish by taking advantage of this neglected flaw are unlikely 
to affect the acceptance of any exploited high volume domain.  DKIM 
could have avoided offering false assurances by not ignoring illegal 
multiple header fields per RFC5322 and defining such messages as 
resulting in invalid signatures.  Unfortunately, when essential input 
checks are skipped, acceptance based upon DKIM's now potentially 
deceptive results may play an evil role that cannot be repaired through 
the use of reputation.

The general goal of DKIM cryptographically binding at a minimum the From 
header field of the message content to a domain was to act as a trust 
basis for acceptance.  DKIM also purports to allow incremental 
deployment without requiring additional undefined filtering be 
introduced in mail transfer or mail user agents. Clearly, the 
incremental deployment statement conflicts with the original goals due 
to the neglected input validation flaw.

Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

This version of DKIM also introduced use of RFC5890 instead of RFC3490, 
which allows use of the German esset and the Greek final sigma, drops 
string-prep, and defines 3,329 invalid code points.  Unfortunately, this 
version of the DKIM also failed to exclude use of Fake A-Labels, which 
when presented to the user may also prove highly deceptive.

Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Jun 2011 10:17:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Tuesday, June 21, 2011 6:51 PM
> To: [email-masked]; Barry Leiba; [email-masked]; Sean Turner
> Subject: Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
> 
> [...]
> 

This purported security flaw and surrounding FUD was discussed at huge length in the working group, and consensus was clearly against the idea of dealing with this in DKIM because it's the wrong place to address the problem.  The record, both in the issues tracker and in the working group's archive, is quite clear about this, and both are open to public scrutiny.

And I find the tactic of taking a lost battle from a working group to the IETF as a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy that I outgrew by the time I was a teenager...

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Jun 2011 13:27:51 -0400

On Wednesday, June 22, 2011 01:17:16 pm Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Douglas Otis Sent: Tuesday, June 21, 2011 6:51 PM
> > Subject: Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys
> > Identified Mail (DKIM) Signatures) to Draft Standard
> > 
> > [...]
> > 
> This purported security flaw and surrounding FUD was discussed at huge
> length in the working group, and consensus was clearly against the idea of
> dealing with this in DKIM because it's the wrong place to address the
> problem.  The record, both in the issues tracker and in the working
> group's archive, is quite clear about this, and both are open to public
> scrutiny.
> 
> And I find the tactic of taking a lost battle from a working group to the
> IETF as a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy
> that I outgrew by the time I was a teenager...

While I'm not thrilled by the post-4871 changes in general, I think on this 
point there's not an issue.  I recently worked through the multiple From case 
for a DKIM implementation I'm helping on and found sufficient guidance in RFC 
4871 to deal with it reasonably.  This was definitely beat to death in the WG.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 22 Jun 2011 11:14:36 -0700

Folks,

The bottom line about Doug's note is that the working group extensively 
considered the basic issue of multiple From: header fields and Doug is raising 
nothing new about the topic.

A quick summary of the technical point at the core of Doug's concern is that the 
presence of multiple rfc5322.From header fields does appear to represent a 
plausible attack vector, but it also violates RFC5322 -- and RFC822, if anyone 
is worried about the history of this issue.  DKIM (RFC4871) requires that the 
signing engine be handed a valid RFC5322 message.  Hence the burden of ensuring 
that there is only one From: field rests outside DKIM.

For reference, Doug posted a related blog recently and I posted a response 
yesterday:

    <http://www.circleid.com/posts/searching_under_lampposts_with_dkim/>

Others are posting responses also. The Comment mechanism, to the Circleid 
article, is being used to list these additional responses.

Inline comments...

On 6/21/2011 6:50 PM, Douglas Otis wrote:But,
> RFC4686 Introduction states:
...
> While several threats to DKIM were considered, multiple From header fields were
> neglected. This document only focused on use of multiple addresses within the
>  From header field.

Any possible omissions in an Informational threats document -- done 6 years ago 
and before the signing specification (RFC4871) was written -- is of marginal 
relevance, at best.

> It should be noted that Signing Practices are referenced off a domain found in
> the From header field which also assumes only one will be present.

It also should be noted that Signing Practices (ADSP) issues are irrelevant to 
the candidate RFC4871bis effort, which pertains only to the signing specification.

> This indicates the DKIM specification is seriously flawed.

It indicates that there is an issue, not that it is DKIM's responsibility to 
solve it.

> While DKIM may notoffer author validation,

Does not.  Not may not.  It's a simple and direct fact.

 >    it was intended to establish an accountable domain for
> the signed message content that at a minimum includes the From header field.

And it does that.  But it does not make any assertions about the /validity/ of 
any of the data it signs, nevermind any of the data it does NOT sign.

> There are NO valid reasons for a valid signature to include multiple From header
> fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's
> intended purpose as defined by prior work.

It actually has no discernible effect on DKIM's utility, nor have there been 
reports from the field of problems in 6 years of deployed use.

> Free email providers likely use DKIM to gain increased acceptance by taking
> advantage of their "too big to block" volumes. For these domains, their
> reputation is understood to offer little assurance of their overall integrity
> while perhaps limiting what is allowed in the domain portion of the From header
> field.

This appears to be a political rant.

> By allowing a pre-pended From header field to not affect the validity of a DKIM
> signature according to the specification means the UNDERSTOOD source of a
> message can NEVER be trusted through the aid of DKIM.

That statement well might be correct, but that's OK, since DKIM does not make 
assertions about "source" validity, except in terms of the separate DKIM signing 
identifier (in the DKIM-Signature: header field.)  The signer is sometimes 
referred to as a source.  However DKIM makes no assertions concerning the Author 
or Originator [RFC5598].

> The general goal of DKIM cryptographically binding at a minimum the From header
> field of the message content to a domain was to act as a trust basis for
> acceptance.

The general goal is to attach an identifier than is reliable and valid, and it 
does that.  The identifier can be used for developing a reputation assessment of 
message streams signed with that identifier.

>  DKIM also purports to allow incremental deployment without requiring
> additional undefined filtering be introduced in mail transfer or mail user
> agents. Clearly, the incremental deployment statement conflicts with the
> original goals due to the neglected input validation flaw.

I have no idea what the above means.

> http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

And it nicely shows that the working group considered the issue.

> This version of DKIM also introduced use of RFC5890 instead of RFC3490, which
> allows use of the German esset and the Greek final sigma, drops string-prep, and
> defines 3,329 invalid code points. Unfortunately, this version of the DKIM also
> failed to exclude use of Fake A-Labels, which when presented to the user may
> also prove highly deceptive.

Excellent.  Now it is also DKIM's job to fix problems with Unicode...

> http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

wrong citation.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Thu, 23 Jun 2011 00:41:59 -0400

To add chair support to Murray's comment:

On Wed, Jun 22, 2011 at 13:17, Murray S. Kucherawy <[email-masked]> wrote:
> This purported security flaw and surrounding FUD was discussed at huge length
> in the working group, and consensus was clearly against the idea of dealing with
> this in DKIM because it's the wrong place to address the problem.  The record, both
> in the issues tracker and in the working group's archive, is quite clear about this,
> and both are open to public scrutiny.

Indeed.  We gave this issue at least two clear consensus calls, and
it's very clear that the rough consensus considers the kind of
validation that Doug is asking for to be a good idea, but outside the
scope of the DKIM protocol.  That is, the validation ought to be done
in another part of the software system.  The document does actually
advise that, and that advice is all that working group consensus was
behind.  Consensus also is that Doug is severely overstating the
problem.

This has been decided and re-decided.

> And I find the tactic of taking a lost battle from a working group to the IETF as
> a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy that I outgrew
> by the time I was a teenager...

I, too, have a problem with how IETF last call is sometimes being used
by working group participants to rehash issues.  But that's a subject
for a separate conversation, and not for here.

Barry, DKIM working group chair

---

From: Doug Otis <[email-masked]>
Date: Thu, 23 Jun 2011 00:41:24 -0700

On 6/22/11 11:14 AM, Dave CROCKER wrote:
> considered the basic issue of multiple From: header fields and Doug is
> raising nothing new about the topic.
>
> A quick summary of the technical point at the core of Doug's concern is
> that the presence of multiple rfc5322.From header fields does appear to
> represent a plausible attack vector, but it also violates RFC5322 -- and
> RFC822, if anyone is worried about the history of this issue. DKIM
> (RFC4871) requires that the signing engine be handed a valid RFC5322
> message. Hence the burden of ensuring that there is only one From: field
> rests outside DKIM.

First, thank you for your response.

I must ask however where do you see this burden being placed?  If not on 
DKIM where?

To clarify, the message format standard authored by you back in 1982 
imposed no limit on the number of header fields and this was not revised 
until 2001.

RFC822 Section 4.1 Syntax states:
,---
This specification permits multiple  occurrences  of  most
fields.   Except  as  noted,  their  interpretation is not
specified here, and their use is discouraged.
'---

The current RFC4871bis only vaguely *recommends* compliance.
3.8. Input Requirements
,---
DKIM's design is predicated on valid input.  Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322], [RFC2045], and
any other relevant message format standards.
'---

Another decade has passed and SMTP still fails to impose strict message 
format enforcement after limits were imposed on Orig-date, From, Sender, 
Reply-to, To, Cc, Message-id, In-reply-to, References, and Subject. 
Voicing opinions of protocol layering lends permission to DKIM 
implementers to also ignore these limits.  :^(

RFC5321 Section 3.3 states:
,--
When the RFC 822 format ([28], [4]) is being used, the mail data
include the header fields such as those named Date, Subject, To, Cc,
and From.  Server SMTP systems SHOULD NOT reject messages based on
perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
header section or message body.
'--

It is not reasonable to expect SMTP will impose necessary restrictions 
able to prevent deceptive DKIM results anytime in the near future.  As 
the DKIM draft states, SMTP is not enforcing header limitations now.

You expressed concern over protocol layers.  What do you call the 
protocol layer you expect to be making these needed checks?  Is this 
some highly opaque spam filter protocol layer?  Will this layer guess 
whether DKIM checked RFC5322's header field requirements?  If not 
guessing, how is this check being signaled?

Those wishing to implement secure systems need to know whether a high 
value From header field might be mistakenly accepted based on signatures 
offered by some large free email provider.  Free email providers often 
don't care whether header fields might be pre-pended when their 
reputation is based upon their volume. They are also unlikely to 
implement a wasteful fix of double listings of signed headers which then 
exposes high value domains to abuse well beyond their control.

The DKIM specification claims it can be incrementally deployed.  One 
might presume that acceptance might be based upon the signing domain. 
If not DKIM, what protocol layer ensures header field limitations have 
been imposed to prevent the signing domain's DKIM's assurances from 
becoming deceptive or evil?

> For reference, Doug posted a related blog recently and I posted a
> response yesterday:
>
> Others are posting responses also. The Comment mechanism, to the
> Circleid article, is being used to list these additional responses.
>
>
> Inline comments...
>
>> fields were
> Any possible omissions in an Informational threats document -- done 6
> years ago and before the signing specification (RFC4871) was written --
> is of marginal relevance, at best.

Nevertheless, RFC4686 missed the threat created by multiple From header 
fields.

>> found in
> It also should be noted that Signing Practices (ADSP) issues are
> irrelevant to the candidate RFC4871bis effort, which pertains only to
> the signing specification.

ADSP depends upon RFC4871's output where it is not possible to achieve 
the desired policies when pre-pended From header fields are ignored.

> It indicates that there is an issue, not that it is DKIM's
> responsibility to solve it.

What protocol do you expect will solve this issue?

>> While DKIM may not offer author validation,
>

I never said DKIM authenticated the From header.  DKIM is expected to 
authenticate a binding of the signing domain with the From header at a 
minimum.  It might also include other headers and the message body.

> And it does that. But it does not make any assertions about the
> /validity/ of any of the data it signs, nevermind any of the data it
> does NOT sign.

The intent of DKIM is completely missed when a pre-pended From header is 
ignored in signature validation.  It is also not reasonable to expect 
all subsequent mail handling will retroactively adopt DKIM's bottom-up 
header selection methods.

> It actually has no discernible effect on DKIM's utility, nor have there
> been reports from the field of problems in 6 years of deployed use.

Is it reasonable to wait for massive exploitation?  Social engineering 
attacks need not occur at high frequencies before significant damage can 
be created.  It seems users are seeking social network communications in 
part because they don't wish to sort through high levels of fraud.

>> taking

No. This was to counter several who expect reputation systems can deal 
with this type of abuse.  They can't when DKIM reports valid signatures 
when messages contain multiple From header fields.

> That statement well might be correct, but that's OK, since DKIM does not
> make assertions about "source" validity, except in terms of the separate
> DKIM signing identifier (in the DKIM-Signature: header field.) The
> signer is sometimes referred to as a source. However DKIM makes no
> assertions concerning the Author or Originator [RFC5598].

DKIM does assert, at a minimum, a signing domain is bound to the From 
header field.  This is important whenever DKIM is used as a basis for 
acceptance.  However, this binding is rendered meaningless when a 
pre-pended From header field is ignored, and yet is predominately 
displayed to the recipient.

> The general goal is to attach an identifier than is reliable and valid,
> and it does that. The identifier can be used for developing a reputation
> assessment of message streams signed with that identifier.

What affect will this have on a massive Free email provider being 
exploited with some pre-pended From header fields?  The answer is NONE. 
Reputation will not solve the issue of abuse of "too big to block" 
providers.

> I have no idea what the above means.

The hand waving about something other than DKIM fixing its bogus results 
will not allow for incremental deployment.

> Excellent. Now it is also DKIM's job to fix problems with Unicode...

No. DKIM can not safely offer a basis of trust without also ensuing the 
domain conveyed to a recipient is not visually deceptive.  This requires 
ensuring against Fake-A labels as defined by the referenced RFC5890. 
Soon there will be many unfamiliar TLDs where users may have difficulty 
discerning which domains are published within a private zone or are 
registered.  Either way, recipients are better served by ensuring Fake 
A-labels are never used to validate DKIM signatures.

It is also important to ensure against use of U-labels as well.  This 
should not become a problem since the range of the character code-points 
should exclude this problem.

>> http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

Thanks. That should have been:

http://trac.tools.ietf.org/wg/dkim/trac/ticket/17

-Doug

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2011 15:24:58 -0000

>> raising nothing new about the topic.

Dave is quite right.  Doug's purported attack just describes one of
the endless ways that a string of bytes could be not quite a valid
5322 message, which might display in some mail programs in ways that
some people might consider misleading.  If it's a problem at all, it's
not a DKIM problem.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Jun 2011 10:33:12 -0700

On 6/23/11 8:24 AM, John Levine wrote:
> In article<[email-masked]>  you write:
Perhaps you can explain why the motivation stated in RFC4686 includes 
anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the 
 From header field MUST be signed?  Why RFC5617 describes the From 
header field as the Author Author address that is positively confirmed 
simply with a Valid DKIM signature result?  Both RFC4686 and RFC5617 
overlooked a rather obvious threat clearly demonstrated by Hector Santos 
on the DKIM mailing list:  Pre-pended singleton header fields.

Neither SMTP nor DKIM check for an invalid number of singleton header 
fields. These few header fields are limited to one because they are 
commonly displayed.  Multiple occurrence of any of these headers is 
likely deceptive, especially in DKIM's case.  DKIM always selects header 
fields from the bottom-up, but most sorting and displaying functions go 
top-down selection.

Complaints from John, Dave, and Barry and others is likely and 
understandably out of fatigue.  They just want the process to be over.  
We are now hearing there is a vital protocol layering principle at stake 
which even precludes DKIM from making these checks!  Really?

Although DKIM will be securely hashing the headers fields which MUST 
include the From header,  developers are being told they must ignore 
multiple singleton header fields discovered in the process.  It is not 
their burden!  As if securely hashing, fetching any number of public 
keys, and verifying any number of signatures isn't?

-Doug

---

From: Al Iverson <[email-masked]>
Date: Fri, 24 Jun 2011 12:47:10 -0500

On Fri, Jun 24, 2011 at 12:33 PM, Douglas Otis <[email-masked]> wrote:
> anti-phishing as DKIM's goal?  Why of all the possible headers ONLY the From
> header field MUST be signed?  Why RFC5617 describes the From header field as
> the Author Author address that is positively confirmed simply with a Valid
> DKIM signature result?  Both RFC4686 and RFC5617 overlooked a rather obvious
> threat clearly demonstrated by Hector Santos on the DKIM mailing list:
>  Pre-pended singleton header fields.
>
> fields. These few header fields are limited to one because they are commonly
> displayed.  Multiple occurrence of any of these headers is likely deceptive,
> especially in DKIM's case.  DKIM always selects header fields from the
> bottom-up, but most sorting and displaying functions go top-down selection.
>
> understandably out of fatigue.  They just want the process to be over.  We
> are now hearing there is a vital protocol layering principle at stake which
> even precludes DKIM from making these checks!  Really?

I'm not suffering from fatigue, personally, and I agree with their
negative reaction toward your commentary. You're speaking as though
you expect DKIM to be the *only* type of message validation that's
going to happen to a message and thus it must account for and handle
message flaws far outside of scope.

This is like complaining that four wheels don't work as a car. True,
but you're missing the point. And you're doing it in a manner so laden
with hyperbole as to be offensive. It's really distressing and
disrespecting to the rest of us to have to read your same complaint
over and over and over. You've made your point. Few (none?) seem to
agree. Could you please move on?

Regards,
Al Iverson

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 24 Jun 2011 15:59:20 -0700

On 6/24/2011 10:33 AM, Douglas Otis wrote:
> Complaints from John, Dave, and Barry and others is likely and understandably
> out of fatigue. They just want the process to be over. We are now hearing there
> is a vital protocol layering principle at stake which even precludes DKIM from
> making these checks! Really?

For those who weren't paying attention, I thought it worth noting that Doug has 
now devolved into an ad hominem line of attack, complete with proffered insight 
into the personal motivations driving 3 of us, absent any external signs to 
support that insight.

My own, actual, view is that a number of us have been considerably more than 
thorough in responding to Doug's entirely misguided campaign, within the DKIM 
working group, here on the IETF list, at the TrendLabs blog, at Circleid, and at 
the MAAWG Technical committee mailing list.

The decision to stop responding to the substance of his postings is merely 
because there is no new substance.  Absent any indication of his view gaining 
support, there's very obviously no benefit to be had in responding further.

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Jun 2011 22:07:47 -0400

One final response from me to this, because it is relevant to the IETF
last call:

> understandably out of fatigue.  They just want the process to be over.

No.  We want to get the spec right, and to make sure it specifies the
right normative things.

> Although DKIM will be securely hashing the headers fields which MUST include
> the From header,  developers are being told they must ignore multiple
> singleton header fields discovered in the process.

No one is saying that anyone "must ignore" anything.  If you think we
are, cite the words in the spec that say that.

What we are saying, and have said repeatedly in many places, is that
it is not the job of the DKIM specification to define the handling of
this normatively.  Developers may certainly handle the presence of
multiple instances of header fields that are not allowed to have
multiple instances... in any manner they like, and we even suggest
(non-normatively) what they might do -- and ignoring the situation
isn't among our suggestions.

But it's not a normative part of the DKIM protocol, and it shouldn't be.

Now I'm done responding to this topic.  The points have all been made,
on both sides.

Barry, DKIM chair

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 28 Jun 2011 15:07:19 +0200

One final note from me, as I want to state my current position regarding 
4871bis, with respect to Last Call.

As the receiving verifier has all the information to _reliably_ [0] 
determine which combination(s) [1] of From [2] and DKIM-Signature 
verifies correctly, it has the means to provide any consuming 
application with the right information. The mechanism(s) by which the 
verification results can be communicated to a consumer (as per par. 6.2 
of 4871bis) can be chosen by the verifier and does not restrict the 
results to only TEMPFAIL, PERMFAIL and SUCCESS [3].

Second, today there is hardly any installed base of MUA's that present 
any form of DKIM results to the end user, so most of this technology 
still needs to be written and 4871bis contains sufficient warnings about 
duplicate From and other fields; so in my view the argument of DKIM not 
being 'compatible' with the currently installed base of MUA's does not 
apply.

Third, DKIM is only one of multiple technologies that can and will be 
deployed by both senders and receivers. This means that any policy 
published by a sender regarding the use of DKIM does not have to provide 
a sharp 'black' or 'white', 'keep' or 'discard' result. Senders that 
wish to publish a policy need to take into account that the world is not 
perfect and that there always will be lousy implementations of protocols 
(be it RFC5321, RFC5322, RFC4871 or RFC4871bis). [4] It's better to 
acknowledge this, than to rely on the 'MUST's in this particular DKIM 
RFC. Policies that do not take this into account, can/may have dramatic 
results.

Hence, I no longer see a problem in 4871bis not mandating the duplicate 
header check.

/rolf

[0] irrespective of whether a From field has been prepended or appended 
or no such thing at all
[1] (s) plural form, if there are multiple DKIM-Signatures and multiple 
 From fields.
[2] From is mentioned here only:
- because it is the only mandatory header field to be used to generate 
the signature and
- for the case that there's a consuming application that would display 
the From header, which in your view is the attack vector
Apart from that, there is no special reason to focus here on From
[3] although TEMPFAIL and PERMFAIL are mentioned in 4871, there is no 
equivalent identifier for a positive result, is there? I suggest to make 
the success status explicit in 4871bis
[4] The fact that a sender doesn't know in advance how well the receiver 
implements the DKIM verification process will need to be taken into 
account for any policy protocol that will be built on top of DKIM.