Subject: [ietf-dkim] Pete's review of 4871bis

From: Pete Resnick <[email-masked]>
Date: Tue, 28 Jun 2011 23:46:06 -0500

Folks,

I've been reviewing 4871bis for the IESG review on Thursday. I've got a 
huge number of comments. Some of them (e.g., the first two below) are 
quite trivial or simple issues that I expect you'd either have no issue 
with or that I'm happy to ignore; some of them are clearly not trivial 
at all. I have not entered a ballot position yet, and I haven't sorted 
through all of the comments to decide if any are worthy of entering a 
DISCUSS, but I suspect that some of them are. I therefore wanted to post 
this to the WG list so you all get an idea of what I'm thinking about. 
Tomorrow I'll spend some time cleaning these up and sorting them by 
category instead of by order of the document.

I apologize for the lateness of this review; it's probably something I 
should have done a long time ago.

Comments:

1. I find the use of the word "INFORMATIVE" throughout the document 
superfluous. No other word (e.g., NORMATIVE) is used in its place. I 
think they should all be removed. They serve no purpose.

2. The ABNF "0*" construct is not normally used. Why not just "*"?

3. Section 2.7: I don't understand what the word "module" means in this 
context. It sounds like some sort of specific implementation, not part 
of a protocol. I don't know what it means to deliver values to a module.

4. Section 3.4.4:

       INFORMATIVE NOTE: It should be noted that the relaxed body
       canonicalization algorithm may enable certain types of extremely
       crude "ASCII Art" attacks where a message may be conveyed by
       adjusting the spacing between words.  If this is a concern, the
       "simple" body canonicalization algorithm should be used instead.

This is not an attack, or at the very least it is not an attack on DKIM. 
You can play this same game with MIME encodings or other textual tricks. 
I don't see any justification for this note being in this document.

5. Section 3.4.5:

       INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
       an attack in which an attacker modifies a message to include
       content that solely benefits the attacker.  It is possible for the
       appended content to completely replace the original content in the
       end recipient's eyes, such as via alterations to the MIME
       structure or exploiting lax HTML parsing in the MUA, and to defeat
       duplicate message detection algorithms.  To avoid this attack,
       signers should be wary of using this tag, and verifiers might wish
       to ignore the tag, perhaps based on other criteria.

I don't understand how this is an attack. If the signer said, "I'm 
signing the first n bytes of the body of this message" and the verifier 
is able to verify that the signature is valid for n bytes of the body, 
the algorithm has succeeded. At most, this should lead to an admonition 
that unsigned data is not verified and therefore should not be trusted, 
but that seems obvious. There might be an attack on an MUA that does not 
verify the DKIM signature, but that seems outside the scope of this 
document.

6. Section 3.5:

    v= Version (MUST be included).  This tag defines the version of this
       specification that applies to the signature record.  It MUST have
       the value "1".  Note that verifiers must do a string comparison on
       this value; for example, "1" is not the same as "1.0".

Why "string comparison" here? There's no case sensitivity to worry 
about. There's no character encoding to worry about. Why not instead 
say, "Note that verifiers must (MUST?) ensure that the value is '1'; for 
exmaple '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) And 
why is the value not listed as "plain-text"?

7. Section 3.5: It would be nice to subsection each tag here. (e.g., 
"v=" could be 3.5.1, etc.)

8. Section 3.5, "h=":

It would be nice to add a sentence similar to the one in 5.4: "The field 
MAY contain multiple instances of a header field name; this means that 
multiple occurrences of the header field are being signed by the signing 
algorithm."

9. Section 3.5, "h=":

          INFORMATIVE EXPLANATION: By "signing" header fields that do not
          actually exist, a signer can allow a verifier to detect
          insertion of those header fields after signing.  However, since
          a signer cannot possibly know what header fields might be
          created in the future, and that some MUAs might present header
          fields that are embedded inside a message (e.g., as a message/
          rfc822 content type), the security of this solution is not
          total.

a. I don't understand what MUAs presenting "header fields that are 
embedded inside a message" has to do with anything.

b. I don't know what the words, "the security of this solution is not 
total" are supposed to mean.

Don't you simply mean: "However, since a signer cannot possibly know 
what header fields might be defined in the future, this mechanism can't 
be used to prevent the addition of any possible unknown header fields."?

10. Section 3.5, "h=":

          INFORMATIVE EXPLANATION: The exclusion of the header field name
          and colon as well as the header field value for non-existent
          header fields allows detection of an attacker that inserts an
          actual header field with a null value.

I cannot parse that sentence. I have no idea what it means.

11. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING". See comment 
in 3.4.5 above. Same comment.

12. Section 3.6.1: It would be nice to subsection each of the tags.

13. Section 3.7: "content-hash" is not defined.

14. Section 3.9:

a. Neither TEMPFAIL nor PERMAFAIL is defined at this point.

b. I have no idea what the "output of a DKIM verifier module" is 
supposed to mean.

I suspect that section 3.9 is at least misplaced in this document, and 
probably completely unnecessary as it sounds like implementation details.

15. Section 3.10: Is this not completely redundant with the text in 
3.6.1 regarding "t=s"?

16. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out 
as such. The title of the section is "Example Scenarios". All of the 
text here is example, and as such it is all informative.

17. Section 4.2, first INFORMATIVE NOTE: Why is this an informative 
note? It seems like good protocol adivce and therefore should say that 
signers SHOULD NOT sign exiting DKIM-Signauture fields.

18. Section 4.2, last paragraph: PERMFAIL is still not defined to this 
point.

I suspect sections 3.8 through all of section 4 belong after (or in) 
section 6.

19. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules 
may be incorporated into any", how about "A signer can be implemented as 
part of any"?

20. Section 5.1: I don't know what the term "signing address" means.

21. Section 5.3:

    Therefore, a verifier
    SHOULD NOT validate a message that is not compliant with those
    specifications.

This section is about signing, not verifying. What is that sentence 
doing in there?

22. Section 5.4:

       INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
       header fields to be reordered (with the exception of Received
       header fields)

5322 does *not* permit header fields to be reordered. It says:

    ...header fields SHOULD NOT be reordered when a message is transported
    or transformed.  More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.

Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit 
header fields to be reordered..."

23. Section 5.5: Though section 5.5 is titled "Recommended Signature 
Content", it is clear that the entire section is devoted to the topic of 
section 5.4: "Determine the Header Fields to Sign". These two sections 
should be combined, and might be subsections of a larger section. But it 
was very confusing to read these as separate.

24. Section 6.1:

    A verifier SHOULD NOT treat a message that has one or more bad
    signatures and no good signatures differently from a message with no
    signature at all; such treatment is a matter of local policy and is
    beyond the scope of this document.

The two clauses in that sentence seem contradictory. Is there an 
interoperability requirement that I not treat messages in a particular 
way, or is it a matter of local policy?

25. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: 
Shouldn't this be a security consideration instead?

26. Section 6.1 (and subsections): This section is playing some sort of 
game. The beginning of 6.1 describes some "statuses" and says things 
like, "The '(explanation)' is not normative text; it is provided solely 
for clarification." If it wanted to give an algorithm for Verfiers to 
follow, where there was a certain state machine with states of 
"PERMFAIL" and "TEMPFAIL", that would have been OK. But it is clear from 
the use of the phrasing, for example, "return PERMFAIL (signature syntax 
error)", the document is trying to sneak in some sort of actual APIs 
into the protocol spec. I think this is bogus and would much prefer that 
these sections be rewritten to say, "enters a PERMFAIL state", perhaps 
labeling each paragraph with the explanation. For example, the first 
paragraph of 6.1.1 could read:

    Signature syntax

    Implementers MUST meticulously validate the format and values in the
    DKIM-Signature header field; any inconsistency or unexpected values
    MUST cause the header field to be completely ignored and the verifier
    enters a PERMFAIL state.  Being "liberal in what you accept" is
    definitely a bad strategy in this security context.  Note however that
    this does not include the existence of unknown tags in a DKIM-Signature
    header field, which are explicitly permitted.

    Version compatibility

    Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
    header field with a "v=" tag that is inconsistent with this
    specification.

The current text is too cute by half, and I think it obfuscates the meaning.

27. Section 6.1.3: I don't understand the meaning of the note, "(note 
that this version does not actually need to be instantiated)".

28. Section 6.1.3:

    verifiers might treat a message that contains bytes beyond the
    indicated body length with suspicion, such as by declaring the
    signature invalid (e.g., by returning PERMFAIL (unsigned content)),
    or conveying the partial verification to the policy module.

Up to the word "suspicion", fine. After that, it is complete nonsense. 
The signature is not invalid. If what you mean is "and may choose to 
treat the signature as if it were invalid (e.g., by going into the 
PERMFAIL state)", then say that. And again, this is trying to wrap APIs 
and implementations choices into the protocol.

29. Section 8.1: See comments above regarding section 3.4.5.

30. Section 8.2: I don't see how this is DKIM specific. More 
importantly, this section doesn't explain how user private keys relate 
in any way to keys used in DKIM. Shouldn't this be a discussion about 
security of private keys in general (not just ones on user machines)?

31. Section 8.5: I don't understand what the attack here is that has 
anything to do with DKIM. I especially don't see why the accomplice is 
an essential part of the example, unless all that is meant by 
"accomplice" is "relay". The attack sounds like, "people can spam signed 
messages", which is not an attack.

32. Section 8.14: This is a complete mischaracterization of the problem. 
This is absolutely not an attack vector. If a signer wishes to prevent 
additional *known* header fields from being verified, it can simply use 
the technique outlined in 8.15. If the signer chooses not to do that, it 
is expressing the intent that it considers messages valid that have 
additional header fields added. *That's* the security consideration: 
Signers should know that failing to include, e.g., "h=...:from:from:..." 
on messages with one "From:" header field are leaving themselves open to 
this attack. The attack is not on the verifier. Additionally:

    Note that the technique for using "h=...:from:from:...", described in
    Section 8.15 below, is of no effect in the case of an attacker that
    is also the signer.

That sentence is utter nonsense. The signer *can't* be the attacker for 
purposes of DKIM when it comes to the header fields it's willing to 
sign. The Introduction (section 1) makes it absolutely clear that DKIM 
is about transmitting information from a signer to a verifier.

Section 8.14 needs to be completely rewritten. It is nonsensical as it 
stands.

33. Section 8.15:

    However, [RFC5322] also tolerates obsolete message syntax, which does
    allow things like multiple From: fields on messages.  The
    implementation of DKIM thus potentially creates a more stringent
    layer of expectation regarding the meaning of an identity, while that
    additional meaning is either obscured from or incorrectly presented
    to an end user in this context.

DKIM can perfectly well deal with the obsolete syntax. The signer can 
sign as many "From:" fields as the message has when signed, and add a 
":from" to the "h=" tag to insure that the right number of them are 
verified. As in 8.14, the attack is not on DKIM per se; it's on signers 
that don't properly use the "h=" tag to sign those header fields that 
they don't want added to.

Other malformed input might cause problems for a DKIM implementation, 
but multiple header fields where 5322 3.6 only allows one is not that 
sort of attack.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Jun 2011 12:11:06 -0400

Pete:
I'll mostly let the editors reply to this, but there are a couple of
things I want to say first.

The first thing is that it's out of scope to address changes to things
that were in RFC 4871, which was approved by the working group, the
community, and the IESG in 2007, if it's simply a question of one or
two people not liking those things so much -- even if one or two of
those people now sit on the IESG.  The working group has really made
an effort to avoid casual changes, and I support that, as chair and
document shepherd.

> think they should all be removed. They serve no purpose.

This is one category of those things that appeared in 4871.  I also
strongly disagree that they serve no purpose.  It's useful to make it
clear when we have informative text that readers might misunderstand
to be normative.  In any case, it's harmless, even if you don't like
it for stylistic reasons.  But the bottom line is that these were
there before, and should stay there now... except, of course, for
removing or changing ones that are wrong or truly unclear.

> I don't see any justification for this note being in this document.

It's a very weak attack, and might be something we shouldn't bother
mentioning, but it is an attack, and one that the working group
decided to put into 4871.  One thing that DKIM ensures is that someone
can't put, say, a line that says "viagra" into the middle of an
otherwise legitimate message without invalidating the signature.  But
with relaxed body canonicalization, an attacker can insert and remove
spaces at will, wherever there's already a space, and that can be used
to create the word "viagra" in ASCII art, though quite crudely.

Personally, I think it's a silly thing to worry about, and that we
shouldn't mention it.  But it's not up to me: it has working group
consensus from before RFC 4871 was published.

> but that seems obvious.

Of course, that's why it's an informative implementation note.  You're
saying that it's not worth pointing out pitfalls, and that we should
stick to the facts of the protocol.  Maybe.  Maybe this should be in
the informative documents, the overview and the deployment guide.
Maybe several of the similar items should.  The working group chose to
put it into RFC 4871 instead.

It's worth noting that this is warning about a tag that the working
group considers VERY problematic, and that the WG thought hard about
removing in the progression to DS.  In the end, we did not have
consensus to remove it.  We do have consensus to leave in the
warnings.

> I cannot parse that sentence. I have no idea what it means.

It's a horrible sentence, and needs rewording (or removal).  But I
know what it means.  When you sign an empty header field (like
"Floob:"), you are signing the field name ("floob"), the colon, and
the terminating CRLF (with a null value).  When you "sign" a header
field that doesn't exist in the message, you are signing a complete
null string: a null field name, and a null (absent) colon, value, and
CRLF.  This is trying to point out the difference, and is explaining
how it prevents the insertion not just of "Floob: bleeg", but also of
an empty "Floob:".

> way, or is it a matter of local policy?

Yes, this is awkward.  It is a requirement to prevent attacks that
rely on absent signatures being treated more favourably than "broken"
ones, or vice-versa.

I have serious issues with your comments on section 8, the Security
Considerations.  But I'll leave that to the editors (and perhaps the
security ADs) to talk with you about.

Barry, DKIM chair

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2011 17:20:03 +0100

> Section 8.14 needs to be completely rewritten. It is nonsensical as it

I agree that 8.14 is poorly written (and it was even worse a while back).  
However, there most certainly IS an attack here, which is NOT the same as  
the related attack discussed in 8.15, and cannot be prevented by putting  
extra entries in the 'h=' tag. Unfortunately, many WG members have failed  
to understand the difference between the two. Here is the attack,  
described in plain terms:

A phisher obtains a throwaway domain and creates a public/private key pair  
for
it. He then sends messages of the following form:

------------

To: [email-masked]
From: eBay <[email-masked]>
Date: Tue, 17 May 2011 13:21:06 +0100
Subject: Some plausible Ebay subject
<Lots of other normal headers>
From: [email-masked]
DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
       h=from:to:subject:date; ....... b=<valid signature>

Body of message of typical Phish style.

-------------

A compliant DKIM verifier will report that as a validly signed message. The
Ebay signature is irrelevant for the signing process (so even if Ebay has
declared a "Discardable" ADSP policy it will not be invoked). Normal  
readers
using current MUAs will see just the From: Ebay header and, believing that
their ISP has done some magical cryptographic checks to prevent bogus Ebay
messages from getting through, will be reassured.

The present draft does make some woolly attempts to fix this problem.  
Section
3.8 says "verifiers SHOULD take reasonable steps to ensure that the  
messages
they are processing are valid according to [RFC5322] ... ". But gives no
guidance as to what "reasonable" means (and full RFC5322 compliance  
checking
is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves  
it to the implelemtor to work out what he needs to do.

In my opinion, there needs to be some REQUIRED action in the verifier which
will result in a PERMFAIL, and which would then catch all attacks of this
nature. But the WG consensus has been against this.

There are clearly related attacks, possibly involving duplications of  
other headers (including some MIME headers), and there are similar attacks  
involving replays and men-in-the-middle and which are covered under 8.15.  
But the one I have shown is the real killer IMHO.

-- 
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: Pete Resnick <[email-masked]>
Date: Wed, 29 Jun 2011 11:39:39 -0500

> an effort to avoid casual changes, and I support that, as chair and

Yup, absolutely agreed. As I said, I do need to sort these comments into 
"serious", "I hope the WG looks at", and "Pete makes a comment that can 
be ignored". I didn't want to spring this long list on folks Thursday 
morning and not at least give people a chance to digest them. I'll work 
today on that list.

> This is one category of those things that appeared in 4871.

Yes. Definitely in the category of "Pete makes a comment that can be 
ignored". If the WG finds that implementation of 4871 was not hindered 
by this, and it wasn't added without consideration, so be it. I hold my 
nose and put up with it.

> I also strongly disagree that they serve no purpose.
>    

Bar BOF to be arranged on the "INFORMATIVE/NORMATIVE" verbal tick that 
has developed in the IETF.

> to create the word "viagra" in ASCII art, though quite crudely.

So I don't understand. You're saying that a MITM can insert and delete 
spaces freely, so they're going to be able to change my text to make it 
appear that it has a different message? That would be an attack, but 
rather insane.

I *suspect* that what this really means is that the *signer* can insert 
funny messages. But (see below) *the signer cannot be the attacker*. 
It's nonsense.

Either way, the paragraph needs clarification.

> Of course, that's why it's an informative implementation note.

Though this appears again later in the document.

> You're
> stick to the facts of the protocol.

No, that's not what I'm saying. If you want to put in an admonition, so 
be it. It's just not an attack.

> how it prevents the insertion not just of "Floob: bleeg", but also of

Yes, it needs rewording or removal. :-)

> rely on absent signatures being treated more favourably than "broken"

Clarification would be helpful.

> security ADs) to talk with you about.

Ack.

Again, sorry for the brain dump. I thought it better to dump and fix 
later than dump late. I am willing to accept that I did not make the 
best of two non-wonderful choices.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Jun 2011 10:31:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, June 29, 2011 9:20 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Pete's review of 4871bis
> 
> to understand the difference between the two.

That's a mischaracterization of the objection.  "h=from:from:..." was not meant to address the attack about which you are complaining.

> nature. But the WG consensus has been against this.

This was discussed ad nauseam.  The consensus reached was that DKIM is the wrong place to enforce compliance of RFC5322.  Rather, we stipulate that we expect those modules to do their jobs properly.

Nobody has said either of the two variants of this attack are not valid concerns.  The dispute is about what module in the handling of a message is responsible for detecting and dealing with it.

Since the problem exists even with a message that is not DKIM-signed, I still fail to understand how this is specifically a DKIM problem.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 29 Jun 2011 12:40:07 -0400

> an effort to avoid casual changes, and I support that, as chair and

RFC 4871 is full of gratuitous and often wrong advice on everything from 
APIs to MUA design to key management.  4871bis got rid of some of it, but 
there's still a lot left.  If Pete can force us to strip out more of the 
gratuitous stuff and stick to telling people how to do reliably 
interoperable signing and verification, the actual standards part of the 
standard, he'll be doing everyone a favor in the long run.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 29 Jun 2011 11:02:37 -0700

> standard, he'll be doing everyone a favor in the long run.

Well, perhaps you are right.

After all, the group's ability to make decisions about changes, it's enthusiasm 
for such an effort and the community's demonstrated problems with the 
problematic text are all clear enough to easily justify our continuing to expend 
significant effort and to further delay publication of this document.

Not.

d/

-- 

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Jun 2011 13:49:27 -0500

On 6/29/11 11:20 AM, Charles Lindsey wrote:

> From: eBay<[email-masked]>
> A compliant DKIM verifier will report that as a validly signed message.
>    

The second From field is absolutely irrelevant in the example. The 
phisher could simply leave out the From field with their address in it 
and sign the ebay From field.

And that's not an attack. The signer signed the message and the 
signature verifies. *DKIM* has done its job successfully and has not 
been attacked. DKIM communicates from the signer to the verifier. The 
signer *can't* attack itself. You *might* characterize this as an attack 
against 5322 (in that From addresses are not bound in any secure way to 
the actual author), but DKIM does not even attempt to address that 
attack, so it's not an attack against DKIM. You go on to say something 
that is an attack, but again you get the analysis wrong:

> The
> declared a "Discardable" ADSP policy it will not be invoked).

Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack 
on ADSP. If ADSP sees the above message and doesn't discard it, then 
ADSP has done the wrong thing. If ADSP has a bug where it thinks it 
ought not discard the above message (with the appropriate policy), then 
that should be fixed. It should certainly be called out in the security 
considerations of ADSP. But it's NOT a security consideration for DKIM.

> Normal

Again, the second From is not required for that to happen. If MUAs 
believe that some magical crypto thing happens to a message with 
"d=badguy.example" and "From: ebay" (with no other From's), then they 
get what they paid for.

> it to the implelemtor to work out what he needs to do.

As this conversation has developed (here and off line), I'm getting 
convinced that 3.8 is a red herring. DKIM deals perfectly well with the 
obsolete message format, including multiple From fields. I think the 3.8 
admonition is overblown.

> nature. But the WG consensus has been against this.

If the WG is against it, it is correct. This is NOT a PERMFAIL condition 
for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a 
different document.

pr

---

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

On 6/29/2011 11:49 AM, Pete Resnick wrote:
> Now*that's*  the attack. But it's NOT AN ATTACK ON DKIM! It's an attack

So?

The original directive to produce a threats analaysis was for threats to 
recipients that DKIM might help remedy.

Clearly, techniques later designed to circumvent or exploit DKIM weaknessare 
also relevant, but they aren't the only attacks that are relevant here.  Also, 
I'm just guessing that that's what you mean by "attack on DKIM".

If I missed it, I apologize, but have you define what you mean by "attack on 
DKIM"?  And why is it important to distinguish which category an attack falls into?

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Jun 2011 12:26:18 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, June 29, 2011 11:56 AM
> To: Pete Resnick
> Cc: DKIM

I'll offer this up:

Something is an "attack on DKIM" if it involves input that can cause DKIM to report a "pass" when it should report a "fail", or report "d=example.com" when it should've said "d=example.org".

Since the general output of DKIM is pass/fail and a domain name plus some other optional signature stuff, I fail to see how double-From type attacks are attacks on DKIM.  Rather, I think these things we're discussing are attacks on MUAs (or on ADSP implementations) that fail to do RFC5322 enforcement or fail to understand what DKIM is telling them.

---

From: [email-masked]
Date: Wed, 29 Jun 2011 11:28:53 -0700 (PDT)

+1

				Ned

---

From: SM <[email-masked]>
Date: Wed, 29 Jun 2011 13:09:54 -0700

Hi John,
>standard, he'll be doing everyone a favor in the long run.

Agreed.

Regards,
-sm

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Jun 2011 15:16:07 +0100

> and sign the ebay From field.

But not with Ebay's private key, and that would surely get spotted (with  
or without ADSP).
> signer *can't* attack itself.

Sure, but this is an attack directed against Ebay. If the signer succeeds  
in fooling both the verifier/policy module/whatever else the ISP provides,  
and thereby in fooling the ultimate recipient, then something has gone  
badly wrong.

The ultimate recipient is not interested in arcane details of who has  
attacked whom, or who was responsible, or which RFC has been broken; he  
just discovers that he has been fooled (and his pocket emptied), and all  
he can see is that the people who were supposed to protect him are busy  
passing the buck amongst themselves.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Jun 2011 15:04:40 +0100

On Wed, 29 Jun 2011 18:31:04 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> From: [email-masked]  
>> [mailto:[email-masked]] On Behalf Of Charles Lindsey
> That's a mischaracterization of the objection.  "h=from:from:..." was  
> not meant to address the attack about which you are complaining.

True, but up to a couple of months ago that was not clear in 8.14/8.15,  
and I suspect some WG members still have not caught up with the  
distinction.

> Nobody has said either of the two variants of this attack are not valid  
> concerns.  The dispute is about what module in the handling of a message  
> is responsible for detecting and dealing with it.

That is true enough, but there is no indication anywhere as to what  
subsequent modules in the chain ARE to be responsible for it, axcept for  
ADSP (and I agree with Pete that it is an attack on ADSP); but the WG  
seems to have washed its hands of ADSP.
>
> Since the problem exists even with a message that is not DKIM-signed, I  
> still fail to understand how this is specifically a DKIM problem.

The problem is that an apparently valid signature (albeit atching the  
wrong From) is likely to give a false impression of validity somewhere  
along the line unless modules down the line are watchig for this case (and  
for sure MUAs will not be watching for it for a long time, so it is the  
ISPs/boundary agents that need to do it).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Jun 2011 09:53:10 -0700

> Sent: Thursday, June 30, 2011 7:05 AM
> To: DKIM

If the advent of DKIM means that numerous modules implementing other specifications loosely suddenly have to pay a price for doing so, then that's the reality, and I still don't see how that's a problem DKIM needs to fix.  Sure, we need to document the nuances DKIM introduces, but it's still not an attack against DKIM, so this remains the wrong place to deal with it in a normative sense.

If you prefer the loose application of other standards, don't use DKIM (and lose out on its benefits).