Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues

From: Douglas Otis <[email-masked]>
Date: Mon, 01 Nov 2010 14:56:10 -0700

On 10/30/10 3:05 AM, Alessandro Vesely wrote:
> On 28/Oct/10 03:36, Douglas Otis wrote:
>> I'll repeat the example given previously.  The multiple listing of a
>> header in the h= parameter can not mitigate exploitation of DKIM PASS
>> results where a valuable domain is prefixed to that of large domain.
>> The large domain is unlikely concerned by possible presence of a
>> pre-pended header field, where their decision not to include multiple
>> listing for a message clearly not compliant with RFC5322.  In other
>> words, this leaves DKIM results open to exploitation.
>>
>> From: [email-masked]
>> From: [email-masked]
>> DKIM-Signature: h=from, d=big-isp.com, ...
> Besides RFC 5322 compliance, how is this different from a traditional
> unsigned spoofed "From: [email-masked]"?  Having just a
> signature doesn't mean much, and spelling how to match signature and
>   From field is ADSP's job, even in corner cases.
Sorting or display selection exploits can occur whenever handling is 
based upon valid DKIM signatures by trusted domains.

By not confirming singleton header fields have not pre-pended an 
existing header field, especially a From header field, this creates an 
exploit exposure.  DKIM normally uses a bottom-up selection process that 
mistakenly presumed RFC5322 compliance.  Avoiding exploitation of a 
valid DKIM signature MUST ensure against pre-pended singleton header 
fields, since most subsequent processing will use top-down header field 
selections.

ADSP compliance only requires a valid DKIM signature by the Author 
Domain, as currently defined by DKIM.  This does not protect against 
pre-pended singleton header fields containing a domain that may have a 
restricted ADSP assertion, even one that always signs with multiple 
singleton header fields listed in the h= parameter.  Multiple listings 
of singleton header fields in the h= parameter is an ugly and wasteful 
hack that offers an incomplete remedy for these selection conflicts.

Note:
RFC5322 defines the following singleton header fields:
  orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, 
references, and subject.

In the example, a domain being targeted by attacks may assert ADSP 
discardable and sign with the h= parameter listing multiple singleton 
header fields.   A victim might accept information based upon a valid 
DKIM signature, only to then be misled by different selections used by 
the display or sort process.  DKIM fails to mitigate the exploitation of 
a DKIM signature inappropriately considered valid when multiple 
singleton header fields exist.

Only by ensuring DKIM never asserts a valid signature for messages 
having multiple singleton header fields, can exploitation of a valid 
DKIM signature status be avoided.  It is not reasonable to presume the 
transport will exclude these messages.  Ensuring against a valid DKIM 
result when there are multiple singleton header fields is not the same 
as enforcing RFC5322 compliance.  This only ensures against DKIM's 
mistaken presumption of RFC5322 compliance.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Nov 2010 19:47:23 +0100

> [...]

> singleton header fields listed in the h= parameter.

If big-bank.com asserts a restrictive policy, the relevant author 
address should make that message fail ADSP verification, since no 
author domain signature can be found.  Apparently, RFC 5617 already 
provides for multiple author addresses.  Section 3 reads

   If a message has multiple Author Addresses, the ADSP lookups
   SHOULD be performed independently on each address.

> Multiple listings of singleton header fields in the h= parameter is
> an ugly and wasteful hack that offers an incomplete remedy for
> these selection conflicts.

Why "ugly hack"?  You mean from an aesthetic POV?

Yes, some bytes are wasted, as usual.  Whenever we'll recycle we 
should fix that.  (MIME compliance and UTF-8 header would be valid 
reasons for v=2, IMHO.)

Since it addresses precisely this issue, it is not incomplete in that 
respect.

> singleton header fields exist.

If ADSP verification is thorough, the exploit can only succeed when 
big-bank.com asserts no restrictive ADSP.  In such case, yes, the 
exemplified message may verify.  Blame poor signing practices at 
big-isp.com.

> DKIM signature status be avoided.

Not quite.  Big-isp.com may delegate responsibility for the From field 
to the relevant author, as it seems common practice.  Then, one 
doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait.

For the "only by" part, unaesthetic signing practices _can_ avoid the 
singleton exploit.  If big-isp.com carefully validates the From field, 
it should also include it twice in the h= tag.  Possibly, one might 
even derive from there a criterion for guessing what kind of signing 
practices have been applied.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 02 Nov 2010 14:58:29 -0700

On 11/2/10 11:47 AM, Alessandro Vesely wrote:
>  If a message has multiple Author Addresses, the ADSP lookups SHOULD
>  be performed independently on each address.

Per RFC5322 Section 3.6.2, the From header field may contain a comma 
separated list of mailbox specifications.  Section 3 of RFC5617 does not 
indicate how multiple From header fields are to be handled.  This refers 
to multiple Author Addresses which may exist within a single From header 
field.

Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP.  
There remains uncertainty as to which From header field might be 
selected whenever multiple singleton header fields exist.  The 
uncertainty is not resolved by Section 3 of RFC5617, which again 
presumes RFC5322 compliance.  When there is a conflict in DKIM's 
bottom-up selection process and a typical display or sorting process 
using top-down, the presumption of RFC5322 compliance creates an easily 
exploited DKIM security gap!

> > Multiple listings of singleton header fields in the h= parameter
> > is an ugly and wasteful hack that offers an incomplete remedy for

This hack does not address the security concern!  It incorrectly 
presumes the valid signature being exploited is that of a high value 
domain attempting to protect their recipients from a spoofing attack.  
The valid signature could easily be that of a large domain that is 
unlikely blocked.  Only proactive policies are able to preclude highly 
polymorphic botnet attacks.  Blocking based upon reputation will not be 
effective in the case of large domains, or in the case of new domains.

> > Note: RFC5322 defines the following singleton header fields:
> > orig-date, from, sender, reply-to, to, cc, message-id,
> > in-reply-to, references, and subject.
>
> > discardable and sign with the h= parameter listing multiple
> > singleton header fields. A victim might accept information based
> > upon a valid DKIM signature, only to then be misled by different
> > selections used by the display or sort process. DKIM fails to
> > mitigate the exploitation of a DKIM signature inappropriately
> > considered valid when multiple singleton header fields exist.
>

Disagree.  DKIM verification failed to ensure the presumption of RFC5322 
singleton header field compliance.  As such, ADSP compliance could be 
based upon an unseen DKIM signature and an unseen From header field.   
It would not matter whether high-value domains always include multiple 
singleton header fields in their h= parameter!  Since other domains are 
unlikely affected by From header field spoofing, why require a practice 
for every other large domain to use this ugly, wasteful, and ineffective 
hack?

> > having multiple singleton header fields, can exploitation of a
> > valid DKIM signature status be avoided.
>
>  Not quite. Big-isp.com may delegate responsibility for the From
>  field to the relevant author, as it seems common practice. Then, one

Only by ensuring valid DKIM signatures included a check that there is no 
multiple singleton header fields, will valid DKIM signature exploitation 
be mitigated!  Only then would deceptive messages be blocked by 
restrictive ADSP assertions.  Currently, one must hope that big-isp.com 
will not sign a message containing multiple singleton header fields.  
Even DKIM verification failed to explicitly require there be no multiple 
singleton header fields before DKIM signatures are considered valid.

>  singleton exploit. If big-isp.com carefully validates the From
>  field, it should also include it twice in the h= tag. Possibly, one
>  might even derive from there a criterion for guessing what kind of
>  signing practices have been applied.

Having the h= parameter list multiple singleton header fields will not 
mitigate the exploit when signed by _different_ domains that have 
_different_ h= parameters and ADSP assertions.  Once there are checks 
for multiple singleton header fields in the DKIM signature verification 
process, there will not be a need to include an ugly, wasteful, and 
ineffective multiple listing of singleton header fields hack.

Prior to the DKIM verification process being repaired, multiple listings 
of singleton header fields only precludes unlikely inter-domain 
spoofing.  Admitting a mistake and including explicit checks for 
multiple singleton header fields in the DKIM verification process 
properly handles the greater concern.  This proper repair will reduce 
multiple listings of singleton header fields to being an interim 
solution for an unlikely exploit.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Nov 2010 11:24:10 -0000

On Tue, 02 Nov 2010 18:47:23 -0000, Alessandro Vesely <[email-masked]>  
wrote:

> author domain signature can be found. ...

But in Doug's example, the verifier (following the letter of RFC4871) will  
report only that it saw a valid signature from the domain big-isp.com. It  
will not report anything at all (either good or bad) about big-bank.com  
since (followng 4871) it was not signed. That is the 4871 hole we are  
tying to fix.

> ...  Apparently, RFC 5617 already

No, that wording applies to multiple addresses in a single From header. If  
there are two From headers, ADSP has nothing to say on which to use, so  
the expectation is that its implementations will use the first, when asked  
to to an ADSP lookup. The whole point of this scam is that big-isp.com  
(the Bad Guy in this case) wants to prevent that lookup from ever  
happening. As the two specs (DKIM and ADSP) are currently written, his  
scam will succeed.

Even if we fixed the ADSP spec (which is not on our current agenda),  
existing ADSP implementations would still get caught. SO we MUST fix it in  
DKIM, which IS on our agenda.
>> these selection conflicts.

Yes it is ugly but, worse, it does not prevent this particular scam.

> exemplified message may verify.  Blame poor signing practices at

Big-isp.com is the Bad Guy here. His poor signing practices are quite  
deliberate. Which is why only a header-counting verifier can catch him.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 03 Nov 2010 14:28:39 +0100

> Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP.

50% agreed.  This mistake is only in DKIM, IMHO.

> exploited DKIM security gap!

RFC 5616 actually just says "multiple Author Addresses".  It does not 
say that having examined a single From field is sufficient.  Although, 
that is an apparently legitimate inference --if one assumes RFC 5322 
compliance-- software that acts that way can still be considered buggy.

> domain attempting to protect their recipients from a spoofing attack.

It does not presume that.  The hack just allows signers to protect 
from this exploit /if they care/.  In order to protect against illicit 
usage of a domain name by third parties one could use ADSP.

> effective in the case of large domains, or in the case of new domains.

You mean the receiving host has a "whitelist_from_dkim" clause?  Yes, 
in that case the message probably passes even if it fails ADSP.  How 
is this a DKIM error?  It has been repeatedly noted that DKIM allows 
producing poor signatures, and whitelisting signers with such 
practices is a questionable setting.  Nevertheless, it works.

> based upon an unseen DKIM signature and an unseen From header field.

Here you hypothesize that the ADSP verifier is unable to see all the 
 From fields in the message.  That makes this an implementation issue. 
  Tough verifiers see all author addresses.

> for every other large domain to use this ugly, wasteful, and ineffective

Because it protects from this specific attack.  A domain does not set 
h=from:from to protect against abuse of its domain name:  It sets it 
in order to protect its signatures from being spoofed.

> Admitting a mistake and including explicit checks for multiple
> singleton header fields in the DKIM verification process properly
> handles the greater concern.  This proper repair will reduce

IMHO, it is not the proper solution.  It changes the design of DKIM so 
as to include heuristic considerations about RFC 5322 compliance that 
are not pristine to digital signatures.  That would result in fuzzy 
results and more false positives.

I note that the 95% "pass" shown in 
http://www.opendkim.org/stats/report.html#mlm_comparison is so low 
that nobody would discard a message because of an invalid signature. 
For DKIM to be usable, we should reduce that 5% failure rate, rather 
than increase it.

---

From: "John R. Levine" <[email-masked]>
Date: 3 Nov 2010 09:54:36 -0400

> 50% agreed.  This mistake is only in DKIM, IMHO.

At this point, it would be helpful if you could propose specific language 
for 4871bis.  And if it's not presuming 5322 compliance, it would also be 
helpful if you could say in detail what a DKIM signer and verifier should 
do if presented with, say, a Windows executable file.  Not a MIME encoded 
message body containing one, just an EXE file.  If you don't require 5322 
compliance or something close to it, that's as legitimate a signing 
candidate as anything.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 03 Nov 2010 12:19:10 -0700

On 11/3/10 6:28 AM, Alessandro Vesely wrote:
> > Per RFC5322 Section 3.6.2, the From header field may contain a
> > comma separated list of mailbox specifications. Section 3 of
> > RFC5617 does not indicate how multiple From header fields are to
> > be handled. This refers to multiple Author Addresses which may
> > exist within a single From header field.
> >

We're in agreement.  When fixed in DKIM, it would not be needed for ADSP.

> > bottom-up selection process and a typical display or sorting
> > process using top-down, the presumption of RFC5322 compliance
> > creates an easily exploited DKIM security gap!
>
>  RFC 5616 actually just says "multiple Author Addresses". It does
>  not say that having examined a single From field is sufficient.
>  Although, that is an apparently legitimate inference --if one assumes
>  RFC 5322 compliance-- software that acts that way can still be
>  considered buggy.

This includes specifications lacking confirmations needed to avoid 
selection error exploits.

> > presumes the valid signature being exploited is that of a high
> > value domain attempting to protect their recipients from a
> > spoofing attack.
>
>  from this exploit /if they care/. In order to protect against
>  illicit usage of a domain name by third parties one could use ADSP.

From: [email-masked] (pre-pended by bad actor)
From: [email-masked]
DKIM-Signature: d=big-isp.com; h=from; ...
<misleading body content when related with "[email-masked]">

Current DKIM specifications allow messages with pre-pended singleton 
headers to receive valid Author Domain Signature status.   As such, ADSP 
might not offer any additional protection, since DKIM header stack 
selection is normally bottom-up.

However, displaying or sorting might select "[email-masked]" 
instead of "[email-masked]" when header stack selection by these 
processes is top-down.

It does not matter how "big-bank.com" normally signs their messages!  
Big-bank.com is unable to prevent the exploit that uses  big-isp.com, 
even by using ADSP with a discardable assertion!  Their recipients may 
accept spoofing attempts based upon erroneous DKIM PASS status.  These 
recipients may then draw incorrect conclusions based upon this erroneous 
DKIM PASS status.

> > unlikely blocked. Only proactive policies are able to preclude
> > highly polymorphic botnet attacks. Blocking based upon reputation
> > will not be effective in the case of large domains, or in the case
> > of new domains.
>

No.  You have incorrectly concluded big-bank.com controls the signature 
being exploited.  A bad actor can exploit signatures of "big-isp.com" to 
deceive recipients who might see From: [email-masked].  This 
exploits the likely acceptance of big-isp.com's message stream, and 
perhaps any added general status annotations.

> >> If ADSP verification is thorough, the exploit can only succeed
> >> when big-bank.com asserts no restrictive ADSP. In such case,
> >> yes, the exemplified message may verify. Blame poor signing
> >> practices at big-isp.com.
> >
> > Disagree. DKIM verification failed to ensure the presumption of
> > RFC5322 singleton header field compliance. As such, ADSP
> > compliance could be based upon an unseen DKIM signature and an
> > unseen From header field.
>

ADSP depends upon DKIM PASS status.  However, DKIM failed to require the 
needed checks against possible inclusion of pre-pended singleton header 
fields.

> > It would not matter whether high-value domains always include
> > multiple singleton header fields in their h= parameter! Since
> > other domains are unlikely affected by From header field spoofing,
> > why require a practice for every other large domain to use this
> > ugly, wasteful, and ineffective hack?
>
>  Because it protects from this specific attack. A domain does not
>  set h=from:from to protect against abuse of its domain name: It sets
>  it in order to protect its signatures from being spoofed.

Better and more immediate protection would be achieved by requiring 
DKIM's verification to make necessary singleton header checks.   It is 
not reasonable to expect all domains to alter their h= parameters to 
include double listings of all singleton header fields.  This is 
wasteful of resources and, in most cases, will not directly benefit the 
domain making the change.

>  IMHO, it is not the proper solution. It changes the design of DKIM
>  so as to include heuristic considerations about RFC 5322 compliance
>  that are not pristine to digital signatures. That would result in
>  fuzzy results and more false positives.

Which singleton header compliance check would inappropriately cause a 
DKIM signature to be considered invalid?

>  For DKIM to be usable, we should reduce that 5% failure rate, rather

We agree DKIM can be make more reliable.  There is far greater harm 
caused when recipients confront a barrage of deceptive spoofing 
attempts, and then stop using the service.

IMHO, the TPA-Label approach offers alternative authentication methods 
to recover most of the failures, along with the necessary control of 
third-party reporting.  The next revision of the TPA-Label draft will 
include more examples and will add semantics for third-party reporting 
aimed at addressing the issues when attempting to restrict acceptance 
based upon DKIM status.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Nov 2010 22:04:16 -0400

> compliance or something close to it, that's as legitimate a signing 

Based on the discussions, providing the proper technical does not seem 
to be problem, but rather how it conflicts with satisfying IETF RFC 
passage guidelines to avoid yet another WG review cycle.

All that aside..

IMV, it was not a mistake to presume 5322 compliance. All mail 
processing components begins with that basic design presumption.

But it was mistake to presume specific DKIM related input requirements 
can be violated or incorrect and yet be ignored or not checked due to 
the subjective software engineering idea that it a protocol Layer 
violation and thus isn't a DKIM technical responsibility to make sure 
these DKIM related specific input parts are correct.

In other words, since a RFC5322 presumed compliance carries over a 
concept that there MUST be only one 5322.From, there is a solid 
Software Engineering (SE) design consideration for the DKIM input 
requirement protocol to take this into account.  A robust function 
generators will check for its boundary conditions and the mistake is 
in the failure to recognize this SE design consideration.

While it is a valid SE consideration to avoid this is an optimization 
or lower overhead consideration, but that should not preclude the idea 
that the SE design semantics not be part of the functional specification.

For example:

Section 5.4 speaks in generic terms regarding signing the last 
instance (from the top, with the presumption that this last instance 
is the first introduction of the header) only but failed to highlight 
the design requirement for a specific single field only 5322.From 
requirement as it relates to a) RFC5322 correct DKIM signature output 
and b) RFC 5322 compliance itself.

It is (A) that is most important here and this is where the corrective 
text should be added.  The original ISSUE Posting included proposed 
text to follow the "last header" paragraph in Section 5.4:

    Special Consideration for Verifying and Signing From: Header

    As an exception, header hash verification MUST be done for all
    5322.From fields and not just the last one.  Signing MUST be done
    for all 5322.From fields found, even though RFC5322 recommends
    only one 5322.From should be used. This will mitigate any
    replay that prepends a new 5322.From header to a DKIM signature
    valid message.  Some MUAs have shown to display only the first
    5322.From header found.

With all the WG participant since then, the above can be better 
clarified, but my main point here is that Section 5.4 is where the 
reader is learning how to implement the logic related multiple headers 
and it is here where the reader should be quickly made aware of the 
RFC5322 compliance reminder and exception to the "Last Header" guideline.

I think a new security Section 8.14 is needed to further describe the 
"reason" for the exception in 5.4.  I think my version is better than 
Murray's but I don't really care about that.

Probably, what is also needed that will really help implementators are 
"tips" and "methods" to address this with an eye to how realistically 
DKIM components are added or integrated to a system. But I believe 
this can be done first by simply stating:

     DKIM implementators can mitigate this issue by adding 5322.From 
checking
     in their verifiers and signers.  The 5322.From checking can also 
be done
     at the integration points such as MTA receivers.

The problem is the next statement because it appears to have IETF 
conflicts:

     It is HIGHLY RECOMMENDED for all DKIM verifiers to ALWAYS perform a
     multiple 5322.From header check and return an invalid signature when
     two or more 5322.From headers are found.

Putting aside the IETF conflicts, by making this a new fundamental 
4871bis requirement for DKIM verifiers to perform this check, it would 
be begin to address the problem to a very high degree.

But at the end of the day, it is an integrated solution.  DKIM can not 
work by itself.  It works when integrated with other parts; MSA, MDA, 
MTA, MLS/MLM and MUAs both online and offline.

As a generic protocol, DKIM can offer a solution for this specific 
multiple 5322.From header fault at the verification and signing 
process and we should provide DKIM software writers the insight to 
consider it when providing tools to the DKIM integrators.  It will be 
the DKIM integrators who will decide how to use the DKIM tools 
provided depending on what the other integrated parts can do or not do.

The "total" solution is an integrated one and since this belated 
highlighted ISSUE has now shown it is also a problem for non-DKIM 
streams, integrators are now smarter about the issue and will most 
systems will begin to do more RFC5322 checking prior to any DKIM 
processing or display to users.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Nov 2010 23:55:51 -0400

> happening. As the two specs (DKIM and ADSP) are currently written, his  

Charles,

It should be noted that this single 5322.From header with multiple 
address values scenario was discussed at length in the past with the 
original SSP draft and the consensus was that SSP checkers should use 
the first address domain.  From the August 2006, SSP draft rev02 
draft, section 2.3:

    http://tools.ietf.org/id/draft-allman-dkim-ssp-02.txt

    2.3.  Originator Address

    The "Originator Address" is the email address in the From header
    field of a message [RFC2822], or if and only if the From header field
    contains multiple addresses, the first address in the From header
    field.

       NON-NORMATIVE RATIONALE:  The alternative option when there are
       multiple addresses in the From header field is to use the value of
       the Sender header field.  This would be closer to the semantics
       indicated in [RFC2822] than using the first address in the From
       header field.  However, the large number of deployed Mail User
       Agents that do not display the Sender header field value argues
       against that.  Multiple addresses in the From header field are
       rare in real life.

As noted that this very rare, to cover all security angles regarding a 
possible domain order relationship of the addresses, IMO, ADSP is 
technical correct in stating it SHOULD check each domain value.

I seem to recall citing a method that can help decide the order of 
checking the domains using the sender or the signer domain.   If the 
signer domain matches any of the single 5322.from header with multiple 
domains, it might consider checking this domain policy first with the 
idea the 1st party signature is more important (trust wise) than a 3rd 
party domain.  It can also use logic to compare the Sender.

For example:

  Sender: [email-masked]
  From: [email-masked], [email-masked], [email-masked], 
[email-masked]
  DKIM-Signature: d=domain2.com

There is reasonable logic here to suggest the domain policy lookup 
order might be:

   domain2.com      - check for 1st party policy
   domain3.com      - check for a "Sender" policy
   domain1.com      - check remaining in order presented
   domain4.com

> DKIM, which IS on our agenda.

Technically, in the name of protocol consistency, if there is no DKIM 
signature, POLICY is still part of the handling framework.  This was 
highlighted in the Threats Analysis (TA) RFC4686 and the SSP 
Functional Requirements RFC5016 in how it related to failed signature 
and also 1st party versus 3rd party signatures.

Overall, if there was probably one absolute majority consensus among 
all sides of the policy question, was the solid TA recognition that a 
valid 1st party signature was a solid reason to short-circuit (skip) a 
policy lookup.   This is codified in RFC5016 section 5.3 item #9:

    9.  SSP MUST NOT be required to be invoked if a valid first party
        signature is found.

So policy is still active when there is no valid signature.

> Yes it is ugly but, worse, it does not prevent this particular scam.

I don't particular like the kludge, but that should not mean it could 
not be mentioned as part of the specification as a possible "feature" 
DKIM API writers or implementors to consider to cover all bases.  In 
other words, the functional spec (ideally) should just mention all the 
known possible methods software engineers can consider to mitigate the 
potential exploit.

   1 - Integrate DKIM with mail system components that can perform
       RFC5322 compliance checking with a focus on multiple 5322.From
       violations.

       Note: As a new general consideration, all MTA/MUA developers
       should consider implementing this multiple 5322.From checking,
       if not done already, as a general practice.

   2 - Include specific RFC5322 checking for items that are related
       to the DKIM verification or signing process. i.e. check for
       multiple 5322.From headers.

   3 - Consider a multiple h=from:from...[:from] N from values to
       force invalid signatures when N+1 5322.From headers are found.

Overall, we should emphasize that all DKIM verifiers SHOULD perform 
this check or offer an option to check for this specific double 
5322.From violation to address integration models where it is not 
possible for MTA receivers to perform this checking.

The above is all I would need as a software person to weigh all design 
and integration decisions and/or what to make available to operators.

For us, we learned that we can best address this a 
SMTPFILTER-CHECK-RFC5322 filter at our MTA receiver for all inbound 
messages.  Like Murray, I believe this is prudent and the best 
approach.  But unlike Murray, from a generalize protocol standpoint 
adding DKIM to a product line, I know I can not enforce this method 
with all MTA systems which may not have the capability or level of 
software options to do this checking at a MTA.  So the DKIM verifier 
and signer protocol components or API SHOULD also provide a mitigating 
solution when specific MTA integration models does not provide an answer.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 04 Nov 2010 20:08:56 +0100

> compliance or something close to it, that's as legitimate a signing

Uh, ok, you're right.  I guess I should have stopped arguing since 
this thread became a dialogue among deaf people --I would have done so 
if I had seen any other sign of progress on this subject.

BTW, I haven't yet tried to submit that EXE file to the DKIM software 
I use.  I will.  I hope we all agree that the spec's better not 
contain phrases such as "an implementation SHOULD crash..." :-/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 04 Nov 2010 15:33:16 -0400

Charles Lindsey wrote:
> On Thu, 04 Nov 2010 02:04:16 -0000, Hector Santos <[email-masked]> wrote:
> 
> + 1/2
> You seem to imply that hash verification MUST be done for all From 
> fields both during signing AND verification. Fine! You say exactly what 
> is to be done when signing, but leave it unclear what to do if a 
> verifier hashes all the From:s it can find, but finds there are 
> insufficient of them listed in the 'h=' tag.
> 
> So I suggest you add the following:
> 
>       Verification MUST check that all 5322.From fields found have been
>       included in the signature. This will mitigate any deliberate omission
>       to sign some 5322.From (such as the first, which might be the only
>       one displayed by some MUA) by a malicious signer.

+1.

I guess I as a bit bias because the DKIM API I was using had already 
resolve this issue with an option:

         Allow Unsigned From Headers

which was an extra option and by default is zero (OFF, FALSE,
DISABLED) hence each 5322.From header found were checked against the
h= list of tag values.

Think of how a verifier migh parse this stuff. While there could be
different methods, a typical model is a streaming line parser:

        while ReadNextLine(line) do
           DKIM_VerifyLine(Line)
        wend

As it reads the headers line by line, it checks the h= tags to do the
hashing. The method used in this DKIM API is to remove the h= tag
value as it matched and rehashed the header as it rebuilding the
signature hash.

So when it found the first 5322.From, it checked, hashed and removed
the "from" tag from the list of tags in h=.

If another 5322.From was streamed in, the special IF statement for
"Allow Unsigned From Headers" checked to make sure there was still a
h=from tag for it. If not, an invalid signature result was immediately
returned.

Think of this option as a "plug and play" extra requirement which
allowed an operator to revert to the original 4871 described behavior
if the option was enabled.  When enabled, the presence of a 2nd
5322.From did not violate the 4871 Section 5.4 logic.

My text was basically trying to keep with the idea that its
(erroneously) possible to have an extra 5322.From header but the DKIM
protocol "extra requirement" would enforce only one to be hashed.  So
by saying "header hash verification MUST be done for all
5322.From fields and not just the last one," it will help keep with
the current logic in Section 5.4 but also help create the invalid
signature we are looking for from a "plug and play" aspect.

> And furthermore, I would suggest replacing "5322.From fields" by 
> "once-only fields" (where "once-only" is defined as some explicit list 
> of headers derived from RFCs 5322, 4045 and maybe others - precise 
> contents to be discussed separately).

True. I'm on the fence with that though to the extent here required as
I think the main focus should be with the security issue here which is
mostly with 5322.from since it is the only required DKIM binding for
headers and arguably the #1 Display Header to be concern about.

But sure, even if generic text is used here, it should probably have
an i.e, or e.g, for 5322.from to make sure the prime focus is the main
security reason for these extra considerations.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Nov 2010 12:36:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, November 04, 2010 12:09 PM
> To: [email-masked]
> Subject: [...]
> 

It boggles my mind that a specification called DomainKeys Identified _MAIL_ has to be explicit about the fact that the input is expected to be formatted like a mail message, and that there's even pressure to say in a normative way that someone implementing this has to make sure that's the case.

Security Considerations of RFC5451 was updated to include language about hardening against input deliberately crafted to try to confuse or crash applications, and I was surprised that they (secdir) felt that was necessary; I expected that to be fairly obvious to anyone in the audience of a standards track RFC.

(It wasn't required to be normative, however.)

---

From: Hector Santos <[email-masked]>
Date: Fri, 05 Nov 2010 13:02:19 -0400

> (It wasn't required to be normative, however.)

In my view of the IETF RFC documents, its a matter of technical 
writing style.
They are neither a 100% Functional Specification nor 100% Technical 
Specification, but a blend to help reach a wider audience of disciplines.

A good amount of expertise and/or experience is required to get the 
"message" across and it also requires a good amount of 
expertise/experience to be able to read the message to both a) extract 
and b) extend the engineering insights required to produce the protocol.

In this case, in my technical opinion, Section 5.4 has incomplete 
implementation insights regarding the single field requirements for 
RFC 5322.  It is an insight that would of been included if we had 
"seen" the issue when it was first written four years ago, especially 
when we went through the TA process.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 05 Nov 2010 11:46:37 -0700

Append to Section 6 Verifier Actions:

It is not reasonable to assume a message is in compliance with RFC5322.  
To mitigate trivial exploitation of trust established by DKIM 
signatures, messages having multiple header fields for "orig-date", 
"from", "sender", "reply-to", "to", "cc", "message-id", "in-reply-to", 
"references", or "subject" MUST always return PERMFAIL for any DKIM 
signature associated with the message.  When there are multiple 
singleton header fields, a field selected for display or sorting is 
therefore undefined.  Likely top-down selections by consumers of DKIM 
status where the signature verification selects bottom-up leaves 
singleton headers highly prone to trivial exploitation.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 08 Nov 2010 10:49:02 -0000

> singleton headers highly prone to trivial exploitation.

+0.75

I prefer requiring the signer to make such a check and then verifying that  
the signer had done so. It comes to the same thing, of course (it  
establishes that no extra headers had appeared in between, or  
alternatively that no malicious signer had failed to make the check). See  
wording proposed by Hector and myself.

The benefit of this approach is that we avoid accusations ot "layer  
violations".

Note also that it is also sufficient to address only this "header  
counting" violation of 5322. If any other 5322 violation is present (e.g.  
a malformed header, which might be part of some scam) then, assuming that  
header has been signed, the evidence of the malformation will be preserved  
and its effect will be the same as if such a scam were attempted with  
current unsigned messages.