Subject: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

From: Hector Santos <[email-masked]>
Date: Mon, 04 Oct 2010 18:24:11 -0400

It has been observed by implementations that is it possible to replay 
a message with a 2nd 5322.From header at the top which wouldn't break 
the DKIM signature validity, but would often be displayed by MUAs to 
display the new 5322.From display rather than the signature bound 
5322.From header.

For example:

    From: [email-masked]        <-- injected, replayed, shown by MUA
    DKIM-Signature:  d=signer.com .......;
    From: [email-masked]        <-- hash bound to signature

The MUA will display the injected 5322.From header and the signature 
is still valid because it only signed the bottom one and verifiers 
also use this header to validate the signature.

A review of the the 4871 specification shows this statement in section 
5.4 which can explains how this is possible:

    5.4.  Determine the Header Fields to Sign

    ...

    Signers choosing to sign an existing header field that occurs more
    than once in the message (such as Received) MUST sign the physically
    last instance of that header field in the header block.  Signers
    wishing to sign multiple instances of such a header field MUST
    include the header field name multiple times in the h= tag of the
    DKIM-Signature header field, and MUST sign such header fields in
    order from the bottom of the header field block to the top.  The
    signer MAY include more instances of a header field name in h= than
    there are actual corresponding header fields to indicate that
    additional header fields of that name SHOULD NOT be added.

There needs to be a special consideration where:

   1) Verifiers and MDAs consider checking for violating RFC5322
      messages with multiple 5322.From headers and rejected it, or

   1) hash verification should be done for all 5322.From fields and not
      just the last one as the above paragraph implies.

   2) signing should be done for all 5322.From fields found, even though
      RFC5322 recommends only one 5322.From should be used.

I propose the following addition text by adding to 48721bis to address 
this serious issue;

   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 should to display only the first
   5322.From header found.

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

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

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 05 Oct 2010 13:15:12 +0100

> display the new 5322.From display rather than the signature bound

Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to 
display the signed header? Are there really MUA's that will display the 
unsigned headers *and* assert that it was validated? If so, that's surely a 
bug in the implementation of the MUA.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Oct 2010 08:45:06 -0400

On 10/5/2010 8:15 AM, Ian Eiloart wrote:
> unsigned headers*and*  assert that it was validated? If so, that's surely a

Your comments underscore the importance of being careful about what we expect 
from DKIM.  As you note, if software is DKIM-aware, it also needs to be 
DKIM-intelligent.

At a deeper level, there is a continuing problem with casting DKIM as a 
mechanism to "protect" a message.  That's something that OpenPGP and S/Mime do; 
it's not something DKIM does.  DKIM merely tries to do enough to ensure that the 
d= is valid, to provide a basis for reputation assessment.

Hence, I recommend that this ISSUE be declined and closed.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2010 06:48:37 -0700

I've removed Tim Polk from the Cc: list because he is not our sponsoring AD.  Our sponsoring AD is already on this list.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Eiloart
> Sent: Tuesday, October 05, 2010 5:15 AM
> To: Hector Santos; [email-masked]
> Cc: Tim Polk
> Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
> 
> unsigned headers *and* assert that it was validated? If so, that's
> surely a bug in the implementation of the MUA.

This is a non-issue for DKIM anyway.  All of this work is predicated on an email that's properly formatted, and RFC5322 says a message with multiple From: headers is malformed.  So this is not specifically an attack on DKIM.

I don't think it's practical in DKIM to enumerate all the ways various malformations can cause misleading displays in an MUA.

The MLM draft work included some chatter about some advice for MUA implementers.  If and when that work is consolidated into a new document of some kind, this issue would be a good one to put there.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 10:47:51 -0400

Dave CROCKER wrote:

>> Ian Eiloart wrote:
>> unsigned headers*and*  assert that it was validated? If so, that's 

> Your comments underscore the importance of being careful about what we 
> expect from DKIM.  As you note, if software is DKIM-aware, it also needs 
> to be DKIM-intelligent.
> 
> mechanism to "protect" a message.  That's something that OpenPGP and 
> S/Mime do; it's not something DKIM does.  DKIM merely tries to do enough 
> to ensure that the d= is valid, to provide a basis for reputation 
> assessment.
> 

> Your comments underscore the importance of being careful about what
> we expect from DKIM.  As you note, if software is DKIM-aware, it
> also needs to be DKIM-intelligent.

> At a deeper level, there is a continuing problem with casting DKIM
> as a mechanism to "protect" a message.  That's something that
> OpenPGP and S/Mime do; it's not something DKIM does.  DKIM merely
> tries to do enough to ensure that the d= is valid, to provide a
> basis for reputation assessment.

> Hence, I recommend that this ISSUE be declined and closed.

Once again, we are mixing out of scope reputation design needs that 
confuses matters.  This has nothing to do with reputation. In fact, it 
can hurt signers if multiple 5322.From are altering scoring.

You can't pass the buck to the MTAs to validate RFC 5322 messages.
You can't pass the buck to the MUAs to enforce them to CHANGE.

While MTAs can address this now, it still needs to be noted in the 
DKIM specification to help API writers add an additional DKIM 
requirement to handle the special case of possible Multiple 5322.From:

DKIM binding the 5322.From is a fundamental requirement.  You can not 
exclude it from any implementation without violating the 
specification.  It is requirement to bind the 5322.From adress to the 
signature and doing so it properly, is directly proportional to the 
signature validity of the signer d= domain.

If there are multiple 5322.From lines, regardless of how it got there, 
then there needs to be additional requirements added to 4871bis which 
help implementators take this security problem into account.

This is precisely what an implementator (Alt-N) discovered and was 
forced to change their software to add an "additional DKIM 
requirement" to their implementation to enforce only one 5322.From 
header signature binding.

What you don't want are future implementators to discovery this 
"additional DKIM  requirement" on their own.  In fact, it can be 
viewed as rather negative if this was known and it was not documented.

4871bis is active.  I highly recommend to address it now with 4871bis 
guidelines so that all current and future implementators can be aware 
of the DKIM security problem.

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

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 14:27:06 +0000

Hector Santos wrote:

>     From: [email-masked]        <-- injected, replayed, shown by
> MUA DKIM-Signature:  d=signer.com .......;
>     than once in the message (such as Received) MUST sign the
> physically last instance of that header field in the header block. 
> Signers wishing to sign multiple instances of such a header field MUST
> DKIM-Signature header field, and MUST sign such header fields in order
> from the bottom of the header field block to the top.  The signer MAY
> include more instances of a header field name in h= than there are
> actual corresponding header fields to indicate that additional header
> fields of that name SHOULD NOT be added.
>
>    2) signing should be done for all 5322.From fields found, even
> though RFC5322 recommends only one 5322.From should be used.
>

No.  The trick is to list From twice in h=.  This ensures more From 
headers cannot be added without breaking the signature.

Perhaps this could be mentioned in the spec with a specific reference to 
the From header, but in general terms the spec is pretty clear about how 
to prevent the addition of a header field.

-Julian

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 11:15:31 -0400

Murray S. Kucherawy wrote:

> This is a non-issue for DKIM anyway. 

-1 Highly disagree.

> All of this work is predicated on an email that's properly 
> formatted, and RFC5322 says a message with multiple From: headers 
> is malformed.  So this is not specifically an attack on DKIM.

-1.  It would be protocol flaw to pass the buck to MTA and MUAs when 
the issue can be address with the protocol itself.

When BAD GUYS discover that valid signed mail can be replayed with a 
spoofed 2nd 5322.FROM, you will become a major problem.

> I don't think it's practical in DKIM to enumerate all the ways various malformations can cause misleading displays in an MUA.

What would be not be practical is to expect existing MTA and MUAs to 
compensate for this DKIM security loop hole.

This is about one specific item only - Multiple 5322.From. As a major 
MTA discovered, they were required to change their implementation to 
add an additional requirement which in effect, enforces only one 
5322.From for signature validity. We did the same. We easily confirmed 
this with a modified replay.

4871bis has the opportunity NOW to add the design insight now - not 
after it is too late and bad guys and other current and future 
implementators find out about this and had to opportunity to address 
the problem but were DENIED the discovery and opportunity to address it.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 11:39:05 -0400

> headers cannot be added without breaking the signature.

Julian, this was explored and it does not matter.  You can add N 
number of h=from: and N+1 is all that is needed in the security hole.

> to prevent the addition of a header field.

If you referring having duplicate from: in h= mitigate this issue, see 
above.

As I proposed, the semantics must include an exception clause for the 
Verifier and Signer signing 5322.From binding logic as described in 
section 5.4 to address this.  It also needs to recommend that MTAs do 
RFC5322 validating  as well - but you are not going to find this in 
the wild unless the MTA is DKIM compliant and is aware of this situation.

It has to be documented in 4871bis for DKIM standardization to make 
implementations now and the future aware of it and deal with it.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 05 Oct 2010 11:46:37 -0400

> d= is valid, to provide a basis for reputation assessment.
Deeper still, DKIM prevents false positive phishing detection.  But 
since a bad actor can poison reputation whenever verification of a DKIM 
domain is associated with undesired delivery, such use suggests DKIM as 
a basis for reputation will not work.

It would be accurate to say DKIM provides a basis for white-listing 
based upon information derived by other means, and offers a strong basis 
to apply acceptance policy based upon associations with the From header 
field.  However, this policy also needs to consider legitimate 
third-party services to discourage the bad practice of using sub or 
cousin domains with MX records or MTAs lacking restrictive 
authentication policies, since this would make the phishing problem even 
more intractable.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2010 08:57:18 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Mehnle
> Sent: Tuesday, October 05, 2010 7:27 AM
> To: [email-masked]

But the attacker in this scenario is already the signer (or has compromised the signer), so he/she will just sign the single From:.

> Perhaps this could be mentioned in the spec with a specific reference
> to the From header, but in general terms the spec is pretty clear about
> how to prevent the addition of a header field.

From: is already there.  The RFC explains how to prevent addition of a field that wasn't there to begin with, not to prevent addition of new ones.

Enumerating MUA issues, though, is a bottomless pit and not really within our scope to do.  We should avoid it.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 11:58:10 -0400

> surely a bug in the implementation of the MUA.

Ian,  it would be not practical to expect MUAs to address this.  But 
sure a recommendation for MTAs and MUA to validate RFC522 specifically 
in regards to 5322.From would suffice.

As Keith Moore recently stated in IETF-822:

    "Okay, I'll state it with more precision: The checking of
     headers should only occur when such a feature is actually being
     used: e.g. when the message is actually being submitted, being
     filtered for spam specifically on behalf of a sender or recipient,
     or being gatewayed into (or out of) a foreign (non-Internet)
     mail system."

His point, in IMV, is that you are not going to find many MTA doing 
RFC 822/2822/5322 checking unless it has a specific purpose.

A DKIM ready ADMD or MTA receiver might be able to reject/drop invalid 
mail with multiple 5322.From lines.   We added a script for this 
ourselves.

But to cover all loopholes the DKIM-verifier MUST have an additional 
requirement to  fault a message with 2 or more 5322.From lines.

That is exactly what the ALT-N open source DKIM/ADSP API did - added 
an additional requirement for DKIM verification that is above and 
beyond what the current specs says and currently allows.

The whole point of a BIS is to help codify the implementation field 
testing and experiences which alter or fine tunes the proposed draft 
protocol.

This one chalks up as on par with what we are seeking.

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 16:28:25 +0000

Murray S. Kucherawy wrote:

> But the attacker in this scenario is already the signer (or has
> compromised the signer), so he/she will just sign the single From:.

If the attacker is the signer, they can just as well resign many times.

I don't think that's the scenario that Hector meant, though.

> > to the From header, but in general terms the spec is pretty clear
> > about how to prevent the addition of a header field.
>
> From: is already there.  The RFC explains how to prevent addition of a
> field that wasn't there to begin with, not to prevent addition of new
> ones.

No, read section 5.4 again.  Hector even quoted the relevant parts in his 
thread opening message.

-Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2010 10:25:02 -0700

> Sent: Tuesday, October 05, 2010 9:28 AM
> No, read section 5.4 again.  Hector even quoted the relevant parts in
> his thread opening message.

Ah, I see now.  I understand 5.4, but I've only ever applied it to preventing addition of a header field that wasn't there in the first place, not to prevent addition of a second one.  That's a pretty clever solution.

Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem.

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 17:44:38 +0000

Please don't CC me.  I'm subscribed to the list.

Hector Santos wrote:

> Julian Mehnle wrote:
>
> > The trick is to list From twice in h=.  This ensures more From headers
> > cannot be added without breaking the signature.
>

I don't get what you're saying.

I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted 
originally), such that signing a message that has a dingle From field 
with h=From:From ensures that adding another From field will break the 
signature.  If you're saying there is a way to add a second From field a 
message thusly signed without breaking the signature, could you please 
explain to me how?

-Julian

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 5 Oct 2010 14:50:53 -0400

Comments inline

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, October 05, 2010 8:45 AM
> To: Ian Eiloart
> Cc: Tim Polk; [email-masked]
> Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with
Multiple
> 5322.From
> expect

Agreed.

> S/Mime do;
> it's not something DKIM does.  DKIM merely tries to do enough to
ensure
> that the

As long as DKIM signs the body and fails to validate on a signed but
modified body then there has to be some presumption that DKIM is a
mechanism (of some sort) that protects the message (to some extent).

> Hence, I recommend that this ISSUE be declined and closed.

I'm still cogitating on the appropriate response to this ISSUE.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Oct 2010 15:23:45 -0400

>Hence, I recommend that this ISSUE be declined and closed.

Nack. DKIM also purports to provide assurance that the signed content of the message is unmodified. I think mentioning that all instances of a header that is signed should be used for signing and verification is a useful data point for implementors.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2010 13:05:53 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, October 05, 2010 12:24 PM
> Nack. DKIM also purports to provide assurance that the signed content
> of the message is unmodified. I think mentioning that all instances of
> a header that is signed should be used for signing and verification is
> a useful data point for implementors.

I'm having trouble parsing that.  Aren't all instances of a signed field used for verifying already?  Or are you proposing an "If you sign one, you have to sign them all" sort of approach?

That will wreak havoc with Received:, if so.

---

From: John Levine <[email-masked]>
Date: 5 Oct 2010 20:30:53 -0000

>> a message with a 2nd 5322.From header at the top ...

A thing with two From: headers isn't a valid RFC 5322 message.

You may recall a lengthy argument about what to do with messages with
bare carriage returns, with the final conclusion being "don't do
that."  DKIM is only defined to sign valid messages.

If a MUA does something undesirable with invalid messages, I'd encourage
people to improve their MUAs.  I expect that an MUA that does something
wacky with extra From: lines also does something wacky with extra Subject:
or other extra lines.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 16:29:52 -0400

> message thusly signed without breaking the signature, could you please 

You are correct. Adding a second from: to the h= tag:

         "h=from:from:.........."

can address this.   But no implementation does that.  Instead the 
ALT-N open source code library counts the 2nd in the verification 
process and invalidates the signature.

My earlier response to you got mixed up with SIGNING test cases where 
there was multiple 5322.From and multiple from: adding to the h=.

Example:

     From:  <--- Injected, Replayed and MUA Display
     From:  <--- satisfy 2rd hash binding
     DKIM-Signature: h="from:from:...."
     From: <--- satisfy 1rd hash binding and EXPECTED MUA Display

So you have N number of h=from SIGNER binding, and you need N+1 to 
exploit it in the VERIFICATION.

Of course, you would have violate 5322 in the first place to have a 
2nd bound 5322.From.  So no good guy will do this.  But bad guys will 
see your typical single 5322.From and one from: in the h= tag.

Either way, there is a security issue and a new requirement to secure 
it either with your suggestion or changes to the guidelines to check 
for this exception.

Obviously, the ease of this exploit is a concern.  Any high value 
domain mail can now be found and replayed with a phished or spooked 
2nd or more 5322.From:

---

From: John Levine <[email-masked]>
Date: 5 Oct 2010 20:36:26 -0000

>Still, though, it's a solution to deal with malformations to which
>MUAs are susceptible, and not strictly a DKIM problem.

Would it be a good idea to recommend in 4871bis that DKIM
implementations should not sign or verify invalid messages?  I
cheerfully admit that I haven't thought out all the implications
thereof.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 05 Oct 2010 13:45:56 -0700

> cheerfully admit that I haven't thought out all the implications

I'd suggest that it would be better to take that up with
rfc5822-bis since this is hardly a dkim-specific problem.

Mike

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 21:04:06 +0000

Hector Santos wrote:

> Julian Mehnle wrote:
> 
> > I interpret RFC 4871, section 5.4 (actually, exactly the part you
> > quoted originally), such that signing a message that has a dingle
> > From field with h=From:From ensures that adding another From field
> > will break the signature.  If you're saying there is a way to add a
> > second From field a message thusly signed without breaking the
> > signature, could you please explain to me how?
>
> can address this.   But no implementation does that.

I don't think this is a matter of implementation, but one of *configura- 
tion*.  Are there any DKIM implementations that *hard-code* the value of 
h=?

In any case I think all that's warranted is adding an explicit note that 
From should be included in h= twice, be it in a hard-coded (default) 
value or in user-made configuration.

> [...]

Agreed.  Assuming you're right and single-"From" h='s are indeed a 
frequent configuration, then apparently the significance of this was 
underestimated.

-Julian

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 17:02:59 -0400

> rfc5822-bis since this is hardly a dkim-specific problem.

In my engineering opinion, it was a security hole that fell through 
the cracks during the development of the RFC 4886 Threat Analysis.

If it was presented back then, we would be dealing with the semantics 
as I propose  to deal with it simply because we can't ignore it or 
blame RFC 822/2822/5322 implementation or MUAs.

This is a DKIM issue and it needs to get addressed.  Any system today 
that displays:

     signed by:

but displays a spoofed 2nd From can produce a major confidence problem 
for DKIM.

I have a problem understanding the blow back to the security issue. 
4871bis is active.   Something needs to be added to 4871bist so that 
implementations and operators are made aware of it, now and into the 
future.

I highly recommend that the key editors embrace this and deal with it 
or risk negative DKIM public relations if this gets into the media or 
into the mind set of any hackers and potential DKIM exploiters.  You 
need to deal with it.  Not ignore it or pass the buck to other layers 
of email.

[1] http://tools.ietf.org/html/rfc4686

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Oct 2010 17:46:12 -0400

>That will wreak havoc with Received:, if so.
I'm suggesting making it clear that if one signs a type of field they should sign all of them. I'm not suggesting adding any requirements that additional types of fields be signed.

Scott K

P.S. I'm not sure I parsed your question correctly. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Oct 2010 11:47:23 +0100

>    valid message.  Some MUAs have should to display only the first

I think you need stronger wording than that. And while you are fixing the  
problem for From: headers, you might as well fix it for the other  
once-only headers (such as Subject:) while you are at it. But the prime  
place to fix it is in the verification. I therefore suggest the following  
in section 6.1.1, presumably after the paragraph beginning "If the "h="  
tag ...":

"If the "h=" tag includes any header field for which, according to  
[RFC5322], the maximum number within the header section is limited to 1,  
and if more than 1 occurrence of that header field is present in the  
message, the verifier MUST ignore the DKIM-Signature header field and  
return PERMFAIL (multiple occurrences of XXX header field). Moreover, it  
SHOULD so treat any header field defined in any other standards track  
document to have a maximum occurrence of 1."

If you think that is a bit too vicious, here is a slightly more  
permnissive version:

"If the "h=" tag includes any header field for which, according to  
[RFC5322], the maximum number within the header section is limited to 1,  
and if the number of occurrences of that header field present in the  
message exceeds its number of occurrences in the "h=" tag, ......".

Having fixed the verification process, one could then add similar wording  
to the signing process.

NOTE that this is a serious security issue, and the present draft cannot  
proceed until this problem is fixed. If that means progression to Draft  
Standard gets delayed, then so be it.

And note that pious exhortations to ensure that RFC5322 be followed, or  
that MUAs should be fixed to solve this problem, are no solution. We live  
in the Real World (TM), and neither of those things is going to happen,  
desirable as they might be.

-- 
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: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Oct 2010 05:25:28 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, October 06, 2010 3:47 AM
> To: DKIM

If we can't rely on people to provide valid input when admonished to do so, then there's no point in continuing any of this work.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 6 Oct 2010 14:11:20 -0400

> rfc5822-bis since this is hardly a dkim-specific problem.

+1

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Oct 2010 11:28:44 +0100

On Wed, 06 Oct 2010 13:25:28 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> From: [email-masked]  
>> [mailto:[email-masked]] On Behalf Of Charles Lindsey
>> Multiple 5322.From
> If we can't rely on people to provide valid input when admonished to do  
> so, then there's no point in continuing any of this work.

Well it is a plain fact that lots of mail non conforming to RFC 5322 is  
floating around, and nearly all MUAs are accepting it on the grounds of  
"being liberal in what they accept". So it is clear that we cannot "rely  
on people" as you suggest. And for sure you cannot expect phishers to heed  
any admonishments whatsoever.

And yet we must develop systems that are secure in spite of all that.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Oct 2010 12:54:47 -0700

> Sent: Thursday, October 07, 2010 3:29 AM
> To: DKIM

Any implementer must understand that "be liberal in what you accept" is not carte blanche to weaken parsing strictness in arbitrary ways just to make things easier on the user (or to satisfy a laziness quota).  Every such choice introduces risk.

There's a difference between a what specification can mandate in order for an implementation to be compliant with it, and what people actually do.  We can say MUST until we're blue in the face but there's no way to compel implementers to stick to every aspect of a specification other than to expose them to the risks of not doing so.  They simply lose the badge of saying they're compliant.  As you say, a lot of people are probably okay with that until it stings them somehow.

This has been a vector for spoofing users via MUAs for a long time because a message with two From: fields may still render the "wrong" one when, say, a greylist or spam filter has acted on the "right" one (whatever those terms might mean).  This was true even before DomainKeys or SPF happened along, so it's not strictly a DKIM issue.  That "From" is a special case for DKIM merely because its signing is required doesn't change that fact.

As another data point, RFC4407 (the PRA portion of Sender ID) also declared that a multiple-From message could not be considered to have a valid Purported Responsible Address, and so Sender ID cannot execute on such a message because there is no input to its algorithm.

And I do not buy the argument that DKIM is the right place to "fix" this just because it's the most recent email RFC that email people might read.

Maybe we need a "Be Liberal In What You Accept Considered Harmful" document.