Subject: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

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

THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE

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

--
HLS

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

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 22:54:47 +0000

President Obama wrote:

> [...]

Funny, but this shows nothing because mipassoc.org resigns messages 
(d=mipassoc.org).  (Oh, and it even included *two* "From"s in h= on your 
message.)

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

-1.  Why do you insist on changing the hashing semantics to special-case
"From"?  Recommending that one more "From" be added to h= (and hashed) 
than From headers are initially placed in the message should be enough.  
There is no need to change the semantics of the spec.

-Julian

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 19:30:21 -0400

> (d=mipassoc.org).  (Oh, and it even included *two* "From"s in h= on your 

Right. Does this add "signer" reputation weight for the injected 
5322.From?

Not good. If mipassoc.org is being vouched by some 3rd party 
reputation service.  The user sees a signed valid message possibly 
vouched by trusted service with a signature hash bound spoofed 5322.From.

> There is no need to change the semantics of the spec.

Not proposing a to change the semantics.  But rather to add insight 
about the issue so that implementators can deal with it.

For example, when I received the echo back from the list, my MTA 
rejected it.

18:46:07 C: MAIL From:<[email-masked]> SIZE=5329
18:46:07 S: 250 <[email-masked]>
18:46:07 C: RCPT To:<[email-masked]>
18:46:08 S: 250 <[email-masked]>... Recipient ok
18:46:08 C: DATA
18:46:08 S: 354 Start mail input; end with <CRLF>.<CRLF>
18:46:08 ** end of data received. (bytes: 5738)
18:46:08 ** WCX Process: SmtpFilterHookLoader  ret: 0
18:46:08 ** Invalid 5322 Message - multiple From: headers not allowed
18:46:08 S: 551 Message Not Accepted by filter.
18:46:10 C: QUIT
18:46:10 S: 221 closing connection

Personally, -1 on suggesting a h=from:from, because you are assuming 
that operators are actually defining a h= tag.  If its blank, its 
falls back to the semantics written - use the LAST header found.

However, if you are suggesting that it needs to be explicitly defined 
to mitigate this problem, then the specs needs to be updated to 
address the security issues.

The fact, Mipassoc.org, stripped my original header and signed with 
the double from: lines, one real, one an injected spoofed, proves 
exactly what the problem here is.

I would not be surprised if testing this with gmail.com shows the same 
thing which the online gmail MUA will have an indicator:

     signed by: some signer domain

but will it display the injected spoofed unbounded 5322.From?

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

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 23:51:53 +0000

> Right. Does this add "signer" reputation weight for the injected

Probably not.  AFAICT mipassoc.org doesn't verify DKIM sigs on list 
messages, and even if it did, a verified DKIM sig (such as one created by 
the original author of the message) doesn't tell anything about the 
legitimacy of the use of the From identity.

> falls back to the semantics written - use the LAST header found.

No.  h= must not be empty.  The spec explicitly forbids this.

Cf. http://tools.ietf.org/html/rfc4871#page-20

> h=   [...]
>      This list MUST NOT be empty.  [...]

As for a possible change in RFC 4871bis, if you look at page 41 of 
4871bis-01 (page 36 in RFC 4871), it already has this nice little note:

|       INFORMATIVE NOTE: A header field name need only be listed once
|       more than the actual number of that header field in a message at
|       the time of signing in order to prevent any further additions.
|       For example, if there is a single Comments header field at the
|       time of signing, listing Comments twice in the "h=" tag is
|       sufficient to prevent any number of Comments header fields from
|       being appended; it is not necessary (but is legal) to list
|       Comments three or more times in the "h=" tag.

I suggest replacing "Comments" with "From".  That should solve the 
problem.

-Julian

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 5 Oct 2010 23:59:07 +0000

Again, please don't CC me.  I'm subscribed to the list.

Stephen Farrell wrote:

> On 05/10/10 23:54, Julian Mehnle wrote:
> > Recommending that one more "From" be added to h= (and hashed)
> > than From headers are initially placed in the message should be
> > enough. There is no need to change the semantics of the spec.
>
> Assuming that "recommending" above maps to a (putative)
> "MUST/SHOULD" statement in 4871bis, I'd be interested in
> opinions as to whether such a change might slow progress
> to draft standard, or be detrimental to current deployments.

Yeah, possibly.  I wasn't even thinking of using RFC 2119 verbiage.

As I've written in my previous mail I think there's a better way to solve 
this (non-)issue.  Just s/Comments/From/ in that INFORMATIVE NOTE on page 
41 of 4871bis-01.  What do you think?

-Julian

---

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

> but will it display the injected spoofed unbounded 5322.From?

For the records, from my gmail testing, it will spambox the RFC 5322 
message with one or more 5322 lines.  But it also does one other thing 
- it removes ALL the headers and recreates its own with no subject. 
It doesn't matter if its signed or not.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 20:22:03 -0400

Julian Mehnle wrote:
> Probably not.  

How do you know what the heuristic systems are doing?

> AFAICT mipassoc.org doesn't verify DKIM sigs on list 
> messages, 

it does.....  It verifies, adds an Authentication-Results: header, 
strip the original signature, add a fooder and a [list] to the subject 
and resigns.

> and even if it did, a verified DKIM sig (such as one created by 

Not sure what that means Julian.

> No.  h= must not be empty.  The spec explicitly forbids this.

You misunderstood.  What that means is that the signing function MUST 
add a h= to the 5322.DKIM-Signature line for the 5322.headers it 
decides to hash and bind to the signature.

The operators with their DKIM implementation can set what headers to 
sign or they can choose NOTHING and allow the default behavior for the 
implementation.

In other words, the operator can set (in whatever way the software 
does it):

   RequiredHeaders From:To:Date:Message-Id:Organization:Subject

Now the signing engine will follow this.  If not set, then it has its 
own default rules.  The recommendation is presented in RFC 4871.

What you are suggestion is that implementation had their defautlt to 
include From:From, like above:

   RequiredHeaders From:From:To:Date:Message-Id:Organization:Subject

> I suggest replacing "Comments" with "From".  That should solve the 

I did notice this too and thought the same idea. :)

What the specs need in whatever IETF method you guys like to do things:

  1) Semantics that DKIM-compliant MTA doing stonger RFC 5322 checking
     and at a minimum, checking for multiple 5322.From (and
     possible even 5322.Subject).

  2) To close the loophole to #1 (legacy software), the DKIM verifier
     SHOULD void messages with 5322.From which are not bound to the
     signature.

  3) To close the loophole to #1 (legacy software), the DKIM signer
     MAY consider adding a h=from:from to the DKIM-Signature.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Oct 2010 00:46:58 +0100

One could argue that this'd be a material change to the
protocol that is not a deletion, and hence that deployed
code would have to change to comply, which, to me, goes
against at least the spirit of the PS->DS transition.
(Which is the point of the current exercise.)

So in terms of meeting our chartered goals, this specific
addition might have undesirable side effects were it to
represent the WG's opinion. (Much as the chairs love you
all, starting right in on a 4871ter is not attractive:-)

Stephen.

PS: Note that I'm saying nothing about whether or not this
issue should be mentioned in 4871bis.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Oct 2010 20:48:01 -0400

> all, starting right in on a 4871ter is not attractive:-)

To address current implementations,  guidelines should be considered:

  1) Suggest MTA do stonger RFC 5322 checking and at a minimum,
     checking for multiple 5322.From (and possible even 5322.Subject).

  2) To close the loophole to #1 (legacy software), the DKIM signer
     MAY consider adding a h=from:from to the DKIM-Signature.

  3) To close the loophole to #1 (legacy software), the DKIM verifier
     SHOULD void messages with 5322.From which are not bound to the
     signature.

#1 is words and a remember for MTA especially those that are with a 
DKIM environment to tighten up there wares.

#2 can be done with current implementation operators. I am assuming 
all or not most of DKIM signing engines will allow operators to set 
"Required Headers" to sign.  It would be rather inflexible if it did not.

#3 is already done by at least one open source DKIM API developed
by a large MTA vendor.  Not sure how OpenDKIM is will do it, but 
Murray did speak of the layer (#1) approach.

#1 and #2 will allow most implementations to close this loophole until 
software vendors catch up with #3.

That said, I don't think writing #1, #2 or #3 text for 4871bis should 
slow down progress to draft standard.

-- 
HLS

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Oct 2010 22:31:32 -0400

> issue should be mentioned in 4871bis.

FWIW:

Adding to a specification, by trying to protect against behavior that is already 
illegal is wasteful, redundant and  opens the door to an infinite path of 
similarly unnecessary provisions.  Plainly bad specification methodology.

d/
-- 

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

---

From: "Mark Delany" <[email-masked]>
Date: 5 Oct 2010 20:05:41 -0700

> similarly unnecessary provisions.  Plainly bad specification methodology.

Right. This seems like it's going down a rat-hole.

There was an assertion in RFC4780 about "conforming emails" that must
only have a single 2822.From header. That got lost in the translation
to 4781 I guess. Unfortunately, 4780 failed to specify what
"conforming" means explicitly.

I also know that this WG has repeatedly stated that messages that are
not within standard MUST fail verification.

That this is not in 4871 seems to be mostly a WG assumption that
should be made explicit.

Mark.

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Tuesday, October 05, 2010 8:06 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> 

I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way.  We've certainly, as I understand it, been proceeding from that assumption for a very long time.

I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers.

I don't like the idea of being any more specific than that.  That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical.  A blanket admonishment to implementers is sufficient and appropriate.

---

From: SM <[email-masked]>
Date: Tue, 05 Oct 2010 22:18:14 -0700

Hi Stephen,
>to draft standard, or be detrimental to current deployments.

Such a change may affect the progress to draft standard.

Regards,
-sm

---

From: "Mark Delany" <[email-masked]>
Date: 5 Oct 2010 22:47:14 -0700

> I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers.

Agreed. Though frankly I couldn't care less about signers. It's always
the verifier that really counts.

> I don't like the idea of being any more specific than that.  That
> is, I don't want to create specific text for specific cases we know
> about because that means anything we don't list could be perceived
> as less critical.  A blanket admonishment to implementers is
> sufficient and appropriate.

Right. We could attempt to enumerate the 1,000 edge-cases we know
today and then re-bis 4871 for the additional 1,000 edge-cases we
learn tomorrow, or we could simply say that invalid 2822 messages
MUST never verify and call it a day.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Oct 2010 02:44:49 -0400

> MUST never verify and call it a day.

+1.

However, the rat hole is when we are not specific and leave it open 
ended.

The proposed text can be:

     Verifiers MUST make sure only check valid RFC 5322 messages
     are verified. Specifically verifiers MUST check for multiple
     5322.From headers in the message and if found, the verifier MUST
     invalidate the signature [and reject|discard the message].

If we remain focus with this specific issue on hand - multiple 
5322.From, which is critical in the mail infrastructure in every 
network and is used for every Online or Offline MUA,  and today 
related to DKIM with the required 5322.From hashing, this is one 
specific invalid mail case that can be easily addressed and doesn't 
have to be a rat hole nor delay 4871bis progress to draft standard.

The funny thing is, I am not even a hacker and I was able to take an 
archived 5322 message text file, prepend a 5322.From line and resubmit 
back into the stream with perfect DKIM validity and resigning by 
another MTA/MLM.  It was too easy and I am not smart enough to 
determine what real hackers can imagine to come up with.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 6 Oct 2010 03:19:43 -0400

I've cogitated on this a bit and spoken with a few knowledgeable people.
I'm an operations guy and only marginally a standards wonk.

So, my belief is that this is really more of a 5322 issue than a 4871
issue. Having said that, I'm not comfortable kicking the can down the
road given that what we know, this potentially leads to abuse.

If the message is malformed and nonconforming then would it be
appropriate to treat the malformed message as no signature? This would
be one approach that appears consistent with 4871 yet this grinds on me
because it means we are saying that a malformed message with a signature
is the same as a conforming signature with no signature.

We also have to consider that verifier may be an MTA or an MUA. The
implications (operationally) are different for each case. It has also
been pointed out to me that a mail implementation may try to fix a
malformed message.

Regardless of my belief that this is a 5322 issue, my personal
preference would be for DKIM verifiers to not validate malformed
messages with an outcome of something along the lines of "unable to
validate due to malformed message". I view this as different than DKIM
none. This is perhaps more of an operations perspective.

Just a few poorly expressed thoughts and lacking a concrete
recommendation that is actionable.

Mike

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, October 06, 2010 1:22 AM
> > From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Mark Delany
> I think several of us thought it was in there, but on review it
apparently
> was indeed lost somewhere along the way.  We've certainly, as I
understand
> it, been proceeding from that assumption for a very long time.
> 
> I like the idea of saying so explicitly in 4871bis, and applying it
both
> to signers and to verifiers.
> 
> I don't like the idea of being any more specific than that.  That is,
I
> don't want to create specific text for specific cases we know about
> because that means anything we don't list could be perceived as less
> critical.  A blanket admonishment to implementers is sufficient and
> appropriate.
>

---

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

>            THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE

Interestingly, my MUA (Opera) displayed both of those From headers, But I  
can quite well understand that many other MUAs don't, and even where they  
do I would expect many phishees would  not notice the second one.

-- 
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:13:50 -0700

> From: MH Michael Hammer (5304) [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2010 12:20 AM
> To: Murray S. Kucherawy; [email-masked]
> Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> 

I don't think that's a fair characterization.  It is simply wrong to try to deal this problem in DKIM.  For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs.

There's also a practical difference between software engineering and specification.  You'd be justified in deciding to make your MUA code resilient to this problem, but it's wrong for doing so to be mandated by a standards document that has nothing to do with defining the proper format of email.

I believe this is a good example of a layering violation.

> because it means we are saying that a malformed message with a
> signature is the same as a conforming signature with no signature.

I understand that concern, but it sounds a lot to me like trying to ascribe a different value to the former case than the latter when we don't know that they deserve different handling.  (And that sounds a lot like the unresolved ADSP rathole.)

To me, there's a clear boundary between what DKIM defines and what RFC5322 defines.  This problem isn't on our side of that line.  The RFC5322 part of the code in a verifier should detect and report that the message is malformed, and the DKIM part shouldn't even be invoked.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 06 Oct 2010 13:41:09 +0200

On 06/Oct/10 01:59, Julian Mehnle wrote:
> 41 of 4871bis-01.

+1, I quote the resulting text

     INFORMATIVE NOTE: A header field name need only be listed once
     more than the actual number of that header field in a message at
     the time of signing in order to prevent any further additions.
     For example, if there is a single From header field at the
     time of signing, listing From twice in the "h=" tag is
     sufficient to prevent any number of From header fields from
     being appended; it is not necessary (but is legal) to list
     From three or more times in the "h=" tag.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Wietse Venema <[email-masked]>
Date: Wed, 6 Oct 2010 08:01:29 -0400 (EDT)

> MUST never verify and call it a day.

+1. This makes more sense to me than trying to enumerate all the
possible effects of malformed messages on naive programs. 

An explicit example may help to motivate the reader ("Invalid
messages must never verify; for example messages with multiple
Subject:, From: or To: header fields").

	Wietse

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Oct 2010 08:00:25 -0400

> MUST never verify and call it a day.

To comply with that MUST every DKIM verifier would have to
include a full 5322 verifier. That's a fairly high bar.

It also changes what DKIM means, operationally, as I know that
most email nodes don't check for well-formed emails today rather
they parse them with a fairly robust parser.

Either the message has a valid DKIM signature, or it does not.
If the signature is valid, then the signing domain takes responsibility
for the message, subtly malformed or not. Just because the message
lacks a Date: header or has bare linefeeds doesn't mean that the
signing domain isn't responsible for it.

I don't see how adding all that functionality and cost to a DKIM
verifier does anything at all to add any value. If anything, it seems
it'll just increase the rate at which a DKIM verifier fails to verify a
DKIM signature contrary to the expectations of both sender and
recipient.

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Oct 2010 09:15:43 -0400

On 10/6/2010 8:00 AM, Steve Atkins wrote:
> It also changes what DKIM means,
...
> Either the message has a valid DKIM signature, or it does not. If the
> signature is valid, then the signing domain takes responsibility for the
> message, subtly malformed or not. Just because the message lacks a Date:
> header or has bare linefeeds doesn't mean that the signing domain isn't
> responsible for it.

THis is a particularly clean and precise attention to DKIM's job, nicely 
filtering out issues that are not part of DKIM's job.

In particular, it makes the multiple From: issue entirely irrelevant to DKIM.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 6 Oct 2010 09:17:03 -0400

> signing domain isn't responsible for it.

Recall that the original question was about a valid message with a valid 
signature, which the attacker mutated by adding an extra header that makes 
it an invalid message with a signature that still mechanically verifies. 
Who's responsible for it now?

Is it DKIM's job to make the verification fail, or is it an MUA's job to 
do something reasonable with malformed messages?

R's,
John

---

From: "Mark Delany" <[email-masked]>
Date: 6 Oct 2010 06:52:22 -0700

> I don't think that's a fair characterization.  It is simply wrong to try to deal this problem in DKIM.  For example, a bug in the TCP stack that causes malformed data to arrive in an application wh…

Yeahbut. Isn't that conflating detection with fixing?

Lots of protocols have end-to-end or layer-to-layer verification to
detect intervening bugs. You also well know that treating all external
input with the greatest suspicion *almost* goes without saying in any
programming endeavour, but particularly so in this one.

I agree that a full 2822 parser is over the top and something that is
unlikely to exist near verification code, but we do need to instruct
verifiers to be suspicious and untrusting. What's the middle ground?

Serendipitously, my early implementation refused to verify an email
that had a From: prior to the signature header.

The general problem is that applying authentication results to the
whole payload is wrong. I don't argue this, but one could consider
removing or denaturing all payload outside of the signature...

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Oct 2010 07:00:47 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Wednesday, October 06, 2010 6:17 AM
> To: Steve Atkins
> Cc: DKIM List
> Recall that the original question was about a valid message with a
> valid signature, which the attacker mutated by adding an extra header
> that makes it an invalid message with a signature that still
> mechanically verifies.
> Is it DKIM's job to make the verification fail, or is it an MUA's job
> to do something reasonable with malformed messages?

Yeah, this just occurred to me as well.  Any application (signer/verifier, spam filter, MLM, user agent, whatever, even if it has nothing to do with DKIM) that bases its actions on header fields but doesn't check for valid format first may have this vulnerability in some form.  For example, an MLM that authenticates a poster based on one From: field while MUAs might render a different one has the very same problem.

Trying to deal with this in 4871bis almost seems pointless when the issue is scaled that far.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Oct 2010 10:02:08 -0400

On 10/6/2010 9:17 AM, John R. Levine wrote:
> Is it DKIM's job to make the verification fail, or is it an MUA's job to do
> something reasonable with malformed messages?

At one level, that's merely an implementation choice.  At another level, it is a 
question of whether conformance enforcement MUST occur at all.

The discussions have tended to assume that it MUST occur, by virtue of the DKIM 
requirement for 'conformant' messages.  Steve's point cleverly suggests that 
DKIM itself can dodge the issue by -- once again -- having things simply rest on 
verification outcome.

I find the simplicity and sufficiency of Steve's point pretty darn appealing. 
To emphasize:  It's sufficient because it focuses on DKIM's actual goal and does 
not expand that scope.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Oct 2010 07:11:35 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, October 06, 2010 7:02 AM
> To: John R. Levine
> Cc: DKIM List

Can we get some proposed text?

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 6 Oct 2010 11:50:34 -0400

> In particular, it makes the multiple From: issue entirely irrelevant to DKIM.

If you put back this piece of what Steve said:

Do you come to the same conclusion? Steve, do you agree with Dave's conclusion?

-- 
Jeff Macdonald
Ayer, MA

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 6 Oct 2010 13:57:10 -0400

Apologies all for top posting. Having to use a different client due to technical difficulties.

Murray, I'm violently agreeing with you that it is not strictly speaking a 4871 issue. 

Having said that, I believe that it is an issue that begs the question... where should it land? You are correct that this is the difference between implementation and standards. Either way, we need to look at the outcomes of what we do.

I'm agreeing with you that IETF-DKIM may not be the place to address it...assuming there is a beleif that it is a problem at all. So the first question is whether this is a problem, if the consensus is that it isn't a problem, great...nothing more need be done.

If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - "not our problem"? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... "hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this".

Mike

---

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

> I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers.

+1

> I don't like the idea of being any more specific than that.  That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be percei…

+1

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Oct 2010 14:50:13 -0400

> do I would expect many phishees would  not notice the second one.

  Authentication-Results: dkim.winserver.com;
    dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
    adsp=none author.d=whitehouse.gov signer.d=mipassoc.org;

And for ADSP, our verifier picked up the first (top) 5322.From domain
as well.   Since I whitelist mipassoc.org, I get all its output.

Mind you, that I had to do this twice to get a copy because I had
already added a multiple 5322.From rejector script at the SMTP DATA
session. I had to turn it off and repeat it to get a copy that I see
here from spoofed "President Obama".

So the 5321/5322 filtering layer approach works fine (but we lose
interesting mail <g>). But I would not have done this if I was not
made aware of this problem by Alt-N who discovered this security hole.

And that is the main gist of this, and I don't care how the IETF cats
wants to do this:

     Engineering AWARENESS must be added to the 4871bis.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Oct 2010 15:01:20 -0400

>In particular, it makes the multiple From: issue entirely irrelevant to DKIM.

In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with "It's not valid 5322, so it can't be valid DKIM", it puts the question of how implementors should deal with such things back on the table.

I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations?

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Oct 2010 15:21:08 -0400

> In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with "It's not valid 5322, so it can't be valid DKIM", it puts the question of how implementors should deal…

They can deal with it however they like - but as far as the DKIM validator is concerned there's either a valid DKIM signature, or there isn't, so it's the associated code (where DKIM plugs into the rest of the mail handling engine) that'll need to be aware of it.

Were I writing the signer, though, or the code surrounding the validator I'd appreciate some mention of this gotcha in the spec so I know I need to deal with it.

> I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing.

+1

The more helpful the spec can be to implementors, the better, and this is a grubby corner.

> Maybe this is an added item for security considerations?

Likely, yes.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Oct 2010 15:40:38 -0400

Scott Kitterman wrote:

> In a normative sense, perhaps, but in real world terms, it doesn't. 
> Since this does away with "It's not valid 5322, so it can't 
> be valid DKIM", it puts the question of how implementors should 
> deal with such things back on the table.

+1

> I'd like to see us include a general helpful note to 
> implementors about covering the case where a duplicate header 
> field is added after signing. Maybe this is an added item 
> for security considerations?

+1. This is where I thought it would go.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 06 Oct 2010 14:52:33 -0400

On 10/6/2010 1:57 PM, MH Michael Hammer (5304) wrote:
> Having said that, I believe that it is an issue that begs the 
> question... where should it land? You are correct that this is the 
> difference between implementation and standards. Either way, we need 
> to look at the outcomes of what we do.
>
> I'm agreeing with you that IETF-DKIM may not be the place to address 
> it...assuming there is a beleif that it is a problem at all. So the 
> first question is whether this is a problem, if the consensus is that 
> it isn't a problem, great...nothing more need be done.
>
> If the consensus is that it is a problem but not really a 4871 problem 
> then do we just walk away from it and leave it at that - "not our 
> problem"? Should we perhaps look for the place where the 5322 people 
> roost (I hear that working group shut down as part of IETF reorg) and 
> at least say... "hey, this came up in the context of 4871 and we 
> believe there may be some wider implications and it may be worth 
> considering whether 5322 should be considered in light of this".
>
One possibility is in a bis version of the Development, Deployment and 
Operations document.

     Tony Hansen
     [email-masked]

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 6 Oct 2010 23:50:30 -0700 (PDT)

IMHO, a user who would be fooled by your:

> From: President Obama <[email-masked]>
> From: Hector Santos <[email-masked]>

would also likely be fooled by:

> From: President Obama <[email-masked]>

The latter problem is a hole DKIM just can't plug.  At least the
dual-From: trick is an easy signature to add to a content filter.

By the way, there is no whitehouse.gov ADSP record, so a simple first
person forgery of Obama with no trickery would pass today.  Although the
forger would be wise to use his own MAIL FROM:, as they do have SPF.

Being constructive, recommendations such as "don't allow multiple From:
-- if you really have to then *at least* act on the least favorable ADSP
result for each address" should probably go into a seperate document,
likely a BCP.

We could probably fill a document with other recommended techniques an ISP
could use to help protect banks from the gullibility of their users,
including techniques outside the scope of DKIM.  Such as any kind of stab
at solving the human-name problem I've highlighted (but that's a huge can
of worms), or suppression of attacks using lookalike domains.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

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

> Subject:, From: or To: header fields").

s/must/MUST/, and then +1

---

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

On Wed, 06 Oct 2010 18:57:10 +0100, MH Michael Hammer (5304)  
<[email-masked]> wrote:

> roost (I hear that working group shut down as part of IETF reorg) and at  
> least say... "hey, this came up in the context of 4871 and we believe  
> there may be some wider implications and it may be worth considering  
> whether 5322 should be considered in light of this".

The 5322 people roost on [email-masked].

But since it is already a REQUIREMENT of 5322 that From, Subject et al  
should appear no more than once, just what do you suppose they could do  
beyond what they have already done?

---

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

> include a full 5322 verifier. That's a fairly high bar.

No, that is not true, as I have demonstrated in the text I have proposed.

You only need to look at whatever headers are actually mentioned in the  
"h=" tag of the signature, and you only need to verify those properties of  
those headers that could lead to trouble, and that would seem to be a  
simple count of the number of occurrences of those headers.

That is actually quite a low bar.

> signing domain isn't responsible for it.

The signing domain can only take responsibility for the message it signs.  
It cannot take responsibility for slightly altered copies of the message  
that get used in replay attacks.

It is DKIM's job to detect such cases, and in the case of the particular  
scam under discussion it would be quite simple for it to do so.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Oct 2010 09:09:14 -0700

On 10/07/2010 03:40 AM, Charles Lindsey wrote:
> On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkins<[email-masked]>
> wrote:
>

I'm with Steve on this one. Forcing implementations of DKIM to
determine whether a message is compliant is a pretty high bar. I
for one wouldn't be in any particular big hurry to add a batch of
code to insure that that MUST was fulfilled. I doubt anyone else
would be either. The net effect of this MUST would be to make a
lot of compliant DKIM implementations non-compliant. And for what?

I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.

Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Oct 2010 13:02:12 -0400

> anything that I'm aware of.

This is a half full, half empty issue.   Lets look at the positive side.

DKIM by its very nature has already raised the bar of legacy mail by 
adding a new level of considerations that mandates certain parts, 
especially the 5322.From (since its the only requirement for hashing), 
be valid.  We never (afaik) had any technology that does this at the 
MTA level.  DKIM serves that purpose, thus the beauty of it.

Before DKIM, RFC5322 has this major problem today.  DKIM can leverage 
this RFC5322 vulnerability by helping address attention to it and 
close the loophole.  It does raise the bar for "wannabe" DKIM 
compliant systems to do more than what is normally done. A implicit 
presumption that mail is RFC5322 compliant is not a safe presumption.

The beauty of DKIM is that it moves us away from the legacy system 
exploits - by raising the "email compliancy" bar.   In that vain this 
multiple 5322.From issue is directly related to a DKIM purpose to 
secure it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Oct 2010 11:01:48 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Thursday, October 07, 2010 9:09 AM
> To: Charles Lindsey
> Cc: DKIM

I disagree that it's all that tough.  Any DKIM implementation already has to have some code to isolate particular header fields so that they can be replayed in the order "h=" states, for example.  Code to verify there's only one From: (plus the rest of the min/max counts that RFC5322 defines) in that set can't be that expensive.  Granted that only covers the chart in section 3.6 of RFC5322, but it would completely handle this problem vector.

And there are plenty of open source MTA implementations, the union of which contains a variety of validity checking code that can be used to come up with a valid solution to satisfying the entire RFC.

> anything that I'm aware of.

Generally I agree, but does saying "verification is undefined" satisfy those concerned that this is a security vulnerability?  The example of double-From: shows verification succeeds.  It's the interpretation of those results that is the problem.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Oct 2010 11:18:19 -0700

> And there are plenty of open source MTA implementations, the union of which contains a variety of validity checking code that can be used to come up with a valid solution to satisfying the entire R…

The larger issue here is would anybody rush out to close this MUST.
I think that it is highly unlikely that anybody is going to care at this
point. That goes for *any* new MUST, IMO: unless it's really a serious
protocol endangering problem, it shouldn't be in the -bis document. Save
new MUST's for genuine emergencies.

> Generally I agree, but does saying "verification is undefined" satisfy those concerned that this is a security vulnerability?  The example of double-From: shows verification succeeds.  It's the int…

These are two separate questions, I think. I'm only commenting on whether
DKIM should be the SMTP police.

Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Oct 2010 15:12:50 -0400

> DKIM should be the SMTP police.

I don't think so, but it should inspect its own protocol requirements 
and within those requirements is its crown jewel - 5322.FROM, the only 
header that is required binding.

Now lets consider if its wasn't a requirement, would it matter then?

       I think it greatly matters to the MUA participants.

Note, the 5322.Subject is also a victim here, but its optional and its 
security threat is not even close that what a multiple 5322.From 
reveals.  So I think it warrants adding a check for that too.  But not 
as much as the From.

The point is DKIM took on the job of providing a mail integrity and 
authentication work and raised the about what is expected. Included in 
that job is protecting its primary header - 5322.From.

Keep in mind that not protecting it will also hurt ADSP which I 
already showed that implementation may look for the first one as well. 
  In the spoofed Obama message, this is the authentication results 
generated here:

   Authentication-Results: dkim.winserver.com;
     dkim=pass header.i=mipassoc.org header.d=mipassoc.org 
header.s=k00001;
     adsp=none author.d=whitehouse.gov signer.d=mipassoc.org;

It picked up the wrong one.

So we have TWO protocols that are affected by this.  The irony in all 
this is that this Multiple 5322.From could be used to solve the MLM 
3rd party issue. :)

The verifier MUST check for invalid 5322.From messages if only because 
its part of the DKIM and ADSP formula and mechanics.

Anyway, I hope the right decision is made and address it before it 
widely discovered and becomes a problem.  Even without DKIM, MTA 
should be more aware about this and deal with it.  But only DKIM can 
close the loophole for legacy operations.

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Thursday, October 07, 2010 3:50 AM
> To: DKIM

This seems to support the idea that RFC4871bis simply referring back to RFC5322 to mandate an input requirement is quite sufficient.

---

From: SM <[email-masked]>
Date: Thu, 07 Oct 2010 13:02:09 -0700

At 10:57 06-10-10, MH Michael Hammer (5304) wrote:
>the place where the 5322 people roost (I hear that working group 
>shut down as part of IETF reorg) and at least say... "hey, this came 
>up in the context of 4871 and we believe

That working group did not shut down; it took a pause.

>made aware of this problem by Alt-N who discovered this security hole.

This case was reported in an implementation several years ago as part 
of a different issue.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Oct 2010 13:08:04 -0700

Hi SM,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, October 07, 2010 1:02 PM

Sorry, it was me who told him that.  I misunderstood.

Even so, as Charles pointed out, I'm not sure exactly what it is we could ask them to change.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 07 Oct 2010 16:18:35 -0700

Hi Murray,
>could ask them to change.

RFC 5322 specifies a format for Internet mail.  I don't see what 
could be changed in there as this discussion is not about an issue 
with the format.  You could use the following text:

    A naive recipient can be tricked if implementations of MUAs and mail
    filters incorrectly assume that a message that has been successfully
    verified is RFC 5322 compliant.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Oct 2010 16:27:19 -0700

On 10/7/2010 4:18 PM, SM wrote:
> with the format.

5321 and 5322 are component specifications, although of course they do have 
/some/ systems integrative text. But their attention to implementation issues is 
restricted to the scope of their protocol and format work.

One might wish for a broader, systems oriented document that discusses how the 
components fit together and explains where systems-level and end-to-end issues, 
such as the one being described here, might get resolved.

Darn.  That would probably require normative status for such a document.

Hmmm.  I wonder where the closes approximation might be...

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 7 Oct 2010 20:01:37 -0400

>> anything that I'm aware of.

Except that's not the situation we have here.

a) Author creates a 100% compliant message

b) Signer signs 100% compliant message

c) Bad guy adds an extra header, making it non-compliant, and sends it to 
someone

d) Receiver receives it and, uh, well, what?

Nobody has signed a non-compliant message, so while there is nothing wrong 
with Mike's advice, it completely misses the point.

As far as I can tell, this problem, detecting header changes, is a 
security problem that has never come up before.  PGP, S/MIME, and PEM only 
protect the body, in some cases by wrapping the entire message as a 
message/rfc822 MIME body part and signing that.  RFC 2822 and its 
predecessors tell you what is a valid message, but say approximately 
nothing about invalid messages other than a few historically motivated 
notes like bare linefeeds really are invalid.  I think I can safely say 
that there is no chance at all that Pete Resnick et al. would agree to 
change 2822bis to fix holes in DKIM.

I'm scratching my head to see if there is any advice we can offer to make 
signing and verification more robust while not changing the behavior of 
existing code for normal (for some definition of normal messages).

A) You have to sign either all occurences of a header or none of them, and 
a message with some but not all occurences signed fails verification. This 
is probably too strong, although I doubt that there are many places in 
practice where it would matter.

B) Same as A, but limited to an enumerated set of headers that are 
supposed to occur only once.

c) Same as B, but tell signers to use the h= trick to make verification 
fail if extra headers show up.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Oct 2010 17:26:09 -0700

> with Mike's advice, it completely misses the point.

You're right, it does miss the point. What I'm trying to get my
head around is whether this is a real problem in the real world.
Any reasonable spam filter would notice evil double From:'s in
a New York minute, so I can't get particularly worked up about
this being some sort of existential threat. Can someone come
up with a scenario where this really could be evil and isn't
trivially fixed by... making spam filters insist that they're
really receiving valid 5322 as one of their rules?

Mike, I only have vague recollection of the h= trick anymore...

---

From: "John R. Levine" <[email-masked]>
Date: 8 Oct 2010 01:00:35 -0400

> really receiving valid 5322 as one of their rules?

If one does real whitelisting based on valid signature from senders known 
to be well behaved, it would be a pain if we had to run everything through 
spamassassin anyway.

> Mike, I only have vague recollection of the h= trick anymore...

You list all the headers you sign in h= list, and you can include headers 
that don't exist, which means that they can't exist when verified either. 
So for a header that occurs N times, you can list it N+1 times in h= to 
ensure that more aren't added.  The original motivation was usually N=0 to 
avoid games played by adding MIME headers to messages that don't have 
them, but it's generally applicable.

Having the signer put the extra junk in h= should make existing verifiers 
do the right thing, although I doubt the bit of verification code that 
checks for the non-existence of the N+1st header for N>0 is well tested in 
DKIM implementations.

R's,
John

---

From: "Mark Delany" <[email-masked]>
Date: 7 Oct 2010 22:38:43 -0700

> fail if extra headers show up.

Realistically useful advice probably has to influence rendering of
messages. That might mean MUA participation or it might mean mailstore
participation that removes all (typically) rendered headers that are
unsigned.

That raise a pre-cursor question as to whether DKIM is intended to
offer rendered-to-user value? If not, then this whole discussion is
moot. If so, then that implies greater participation from the
rendering process.

Mark.

---

From: John Levine <[email-masked]>
Date: 8 Oct 2010 06:14:15 -0000

>> A) You have to sign either all occurences of a header or none of them, ...
>> 

>participation that removes all (typically) rendered headers that are

Gosh, I hope not.  I'd like DKIM to be sturdy enough that I can trust
stuff signed by people I know and not have to backstop it by tricks
elsewhere to defend against malicious changes that DKIM didn't notice.

R's,
John

---

From: Wietse Venema <[email-masked]>
Date: Fri, 8 Oct 2010 07:37:28 -0400 (EDT)

John R. Levine:
> c) Bad guy adds an extra header, making it non-compliant, and
> sends it to someone
...
> them, but it's generally applicable.

With this signer-side configuration solution, the verifier can
detect attempts to "spoof" any header that was covered by the DKIM
signature (spoof as in "add a forged header, and hope that naive
programs will use the forged header instead of the authentic one").

So the solution is already available in DKIM. We just need to use
the solution, and make it part of routine DKIM tests.

> checks for the non-existence of the N+1st header for N>0 is well tested in 

To address this, make this solution part of routine DKIM test suites.

	Wietse

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Oct 2010 15:36:56 +0100

On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas <[email-masked]> wrote:

> determine whether a message is compliant is a pretty high bar. ...

How can you claim it is a "high bar" when clearly it isn't.? All that the
implementor of a verifier has to do is:

1: Construct a list of all the RFC5322 headers which can occur at most
once. FYI, that is Orig-Date, From, Sender, Reply-To, To, Cc, Bcc,
Nessage-ID, In-Reply-To and References. For good measure, add the
once-only headers defined in all the other RFCs that you can locate (which
would give you, for a start, MIME-Version, Content-Type and
Content-Transfer-Encoding).

2. Your implementation already needs to scan all the headers in order to
identify the ones it needs to hash in order to verify the signature. It is
a pretty trivial addition to count the occurrences of each one mentioned
in the "h=" tag as part of your scan, and to check whether any of the ones
in the list have occured twice.

> ... I for one wouldn't be in any particular big hurry to add a batch of

Yes, existing verifiers will become non-compliant, but that will not cause
the sky to fall in overnight. They will still continue to verify as at
present, but they will also remain vulnerable to the scam that has been
identified, which should be a pretty good incentive to get them fixed ASAP.
> anything that I'm aware of.

And that indicates that you have not realised the nature or the
significance of this scam. Let me describe it again.

1. A phisher creates a throwaway domain, e.g. ebay.phish.com.

2. He creates a signing key for his domain, and advertises the key in the
usual manner.

3. For good measure, he might also create an ADSP discardable policy for
his domain, just to give an added air of respectability.

4. He then creates and sends emails of the following form:

     From: [email-masked]
     Subject: Your ebay account is about to expire
     DKIM-Signature: d=ebay.phish.com; h=From,Subject,...; ........
     From: [email-masked]
     .........

     Typical phish requesting Password, etc.

5. Note that the phisher signs it with his own key (and it is the 2nd From
that gets hashed). All current verifiers that are strictly compliant with
RFC4871 will report the signature as valid (except for the few that have
already been patched by people aware of the scam).

6. Many, if not most, current MUAs will show only the first signature
     From: [email-masked]

7. The email never goes anywhere near ebay, so their signing practices are
irrelevant. There is absolutely nothing that ebay can do to prevent it.

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Oct 2010 10:50:04 -0400

> head around is whether this is a real problem in the real world.

Not yet, but this has a higher risk of occurrence in the future than 
let's say, SHA1 exploits which required us to incorporate SHA256 into 
the options mix.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Oct 2010 11:06:51 -0400

> To address this, make this solution part of routine DKIM test suites.

+1, however.....

This is only part of the solution.  A temporary one to allow current 
operators to cover themselves using their "Required Header" 
configuration, if any.

The real solution is to void double 5322.From messages. Either the 
DKIM compliant MSA, MDA do it or the "better" DKIM signer/verification 
engine does it to cover for legacy MSA, MDA or to make sure customers 
using a 3rd party signing engine are sending the proper mail to sign.

Can someone come up with IETF amenable copy text for Dave to add to 
4871bis that won't prohibit or slow it down its progress?

IMV, all would be implementers need to read is a basic idea of:

     "Make sure there are no two or more 5322.From headers when signing
      or verifying.  These messages should be voided."

and thats it.

-- 
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Oct 2010 15:38:46 +0100

> new MUST's for genuine emergencies.

But it IS a serious protocol endangering problem.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 08 Oct 2010 17:33:56 +0200

> checks for the non-existence of the N+1st header for N>0 is well tested in

+1, and the revised example proposed by Julian can be enough.

The whole discussion on multiple "From"s then boils down on whether it 
is worth to change the protocol so that, for example, 
"h=from:subject:date:message-id:to" MUST be interpreted by the 
verifier to mean 
"h=from:from:subject:subject:date:date:message-id:message-id:to:to", a 
handy abbreviation for known fields.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Oct 2010 09:28:21 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, October 08, 2010 8:34 AM
> Subject: Re: [ietf-dkim] detecting header mutations after signing
> 

I'm still cringing at the layering violation of "fixing" in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification.

Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it?

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Oct 2010 09:33:38 -0700

> Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it?

I'm a bit confused.

We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge 
condition that is only a theoretical issue and only fixes a problem that is 
actually outside of the scope of what DKIM is trying to achieve?

d/

-- 

   Dave Crocker

---

From: Wietse Venema <[email-masked]>
Date: Fri, 8 Oct 2010 13:25:40 -0400 (EDT)

> actually outside of the scope of what DKIM is trying to achieve?

If I understand things correctly, the solution is already available
in DKIM today.  It involves signer configuration (sign for N+1
instances of each header that is covered by the signature) and
requires no change in protocol or semantics. It merely hardens the
DKIM signature and I see nothing wrong with doing so.

If I am mistaken then please correct me.

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 8 Oct 2010 13:00:30 -0400

On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote:
> > I'm still cringing at the layering violation of "fixing" in DKIM the fact
> > that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't
> > bother to enforce normative portions of that specification.
> > 
> > Is there precedent of this being done elsewhere, i.e. compensating in one
> > protocol for abundant lousy implementations of a layer below it?
> 
> I'm a bit confused.
> 
> We want to re-submit DKIM Signing to Proposed Standard, in order to fix an
> edge condition that is only a theoretical issue and only fixes a problem
> that is actually outside of the scope of what DKIM is trying to achieve?
> 
> d/

Detecting modification in transit is outside the scope of what DKIM is trying 
to achieve?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Oct 2010 10:41:15 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, October 08, 2010 10:01 AM
> Detecting modification in transit is outside the scope of what DKIM is
> trying to achieve?

Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario?

---

From: "John R. Levine" <[email-masked]>
Date: 8 Oct 2010 13:52:13 -0400

> I'm still cringing at the layering violation of "fixing" in DKIM the
> fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, 
> don't bother to enforce normative portions of that specification.

The standard advice has always been to accept malformed mail and render 
it as best you can, on the theory that it was probably from a legit but 
buggy sender.  Other than this DKIM issue, that's still good advice.

Here's another way to look at it: if we think that adding extra headers is 
a significant threat, someone's going to have to check for them.  History 
suggests that in the absence of DKIM, it's not worth doing since nobody 
does it.  That also suggests that all the places other than a DKIM 
verifier will continue not to do it, since it's still of no great benefit. 
So if we don't do it in the verifier, it's not going to happen.

"Our software works, but you have to make changes of no direct benefit to 
yourself to plug a hole we could have plugged" has rarely been a winning 
argument in the past.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 8 Oct 2010 13:58:02 -0400

On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote:
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Scott Kitterman
> > > We want to re-submit DKIM Signing to Proposed Standard, in order to fix
> > > an edge condition that is only a theoretical issue and only fixes a
> > > problem that is actually outside of the scope of what DKIM is trying
> > > to achieve?
> > 
> Doesn't DKIM try to detect modification of the portion covered by the
> hashes, which is unchanged in this scenario?

For what I view as a very abstract definition of unchanged, sure.  I think 
adding additional From or Subject does change the content of the message From 
or Subject.  If one takes the view that we've defined things such that this is 
OK from a protocol definition perspective, so it's not an issue, I think we've 
lost sight of the original goal of this requirement in the protocol.

I think that this can be dealt with through an additional security 
consideration and doesn't have to disrupt the rush to get this advanced 
through the standards process.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 08 Oct 2010 20:01:41 +0200

On 08/Oct/10 18:33, Dave CROCKER wrote:
>> I'm still cringing at the layering violation of "fixing" in DKIM
>> the fact that many RFC5322 implementations, MTAs, MSAs and MUAs
>> alike, don't bother to enforce normative portions of that
>> specification.
>> 
>> Is there precedent of this being done elsewhere, i.e.
>> compensating in one protocol for abundant lousy implementations
>> of a layer below it?

I don't know of a precedent standard, but I recall of an MTA that did
bother to enforce normative portions.  Users periodically complained,
because it is not quite practical to not be liberal in what we
accept.  The best of users' protests that I recall was

   No, just to deliver mail rather than being
   a pedantic-mode SMTP debugger.
      [http://www.mail-archive.com/[email-masked]/msg16896.html]

> I'm a bit confused.
> 
> We want to re-submit DKIM Signing to Proposed Standard, in order to
> fix an edge condition that is only a theoretical issue and only
> fixes a problem that is actually outside of the scope of what DKIM
> is trying to achieve?

Hmm... it is only theoretical until it becomes productive to put it
into practice, and at that point it will be too late.  No doubt most
of us will update their to-be-signed field lists during the next few
weeks.

However, introducing what I called "a handy abbreviation" would be a
source of confusion.  When "h=from:from" will be automatically
assumed by verifiers on seeing "h=from", will we still have to
specify "h=from:from" in case we hit an older verifier?  Otherwise,
just to be safe, we may end up with "h=from:from; h2=from;" :-/

In addition, the current "style" of the DKIM specs doesn't dig into
the meaning of fields.  Rather than being layered on top of 5322,
DKIM looks parallel to it:  In case one does sign multiple "From"s
--as it happened upthread-- the resulting signature looks
unambiguously valid.  If anything is undefined, it is the 5322
semantics, not that of 4871.  Introducing knowledge of what fields
may occur what number of times would alter that style.  Why not also
take into account MIME preambles and epilogues, then?  After all, I'd
keep that handy abbreviation for a revised canonicalization, whenever
it will come.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Oct 2010 15:11:22 -0400

> If I am mistaken then please correct me.

It depends on the Application implementation of DKIM.

How are you doing it or offering DKIM signer configuration in postfix? 
  Do you have a "Required Headers" to sign operation option?

Let me give you a summary background of events leading up to this.

We began to finally go full steam with DKIM integration into our 
integrated mail framework.

I had explored the 2006 revision of the Alt-N open source API to 
explore all this, and to begin the effort in earnest, I upgraded the 
API to latest 2009 version which included ADSP support.

There were one thing I noticed when I did a diff between the two API 
versions. The one that stood out was a new signer options:

   int nAllowUnsignedFromHeaders;  // 0 = From headers not included in 
the
                                   // signature are not allowed, 1 = 
allowed

Note I wasn't aware of this multiple from issue yet, so I presumed 
this was an implementator field experience after three years with a 
need to relax the RFC 4871 requirement to hash the 5322.From. After 
all, with the direction to disassociate the author and signer, it felt 
that was all part of it.

There was another related header hashing option that was both in the 
old and new versions:

   char szRequiredHeaders[256];  // colon-separated list of headers that
                                 // must be signed

The API also provides a callback where it passes each 5322 header as 
it parsed the 5322 message where it wants a TRUE or FALSE function 
response.  This allows an application to prepare a callback to 
determine what specific headers to sign.

The difference is:

   With a CALL BACK, application be be specific with the headers to 
sign and
   only these headers appear in the tag h= values list.

   With szRequireHeaaders defined, it was not exclusive but added headers
   that by default the API didn't sign.

In other would, by default, the signing function signed ALL headers 
excluding

    X-*
    Authentication-Results:
    Return-Path:

Using szRequiredHeader, would allow you to sign other headers not 
already signed.

But for the application which imports the API into a p-code language 
for SMTP receiver (verify) and SMTP router (signing) shimming, I could 
not use the call back method and I needed a way to give operators a 
configuration method way to allow them which headers should be signed. 
   So I added an option:

   int nUseRequiredHeadersOnly;  // 1 - used szRequireHeaders and 
exclude the rest

which says if szRequiredHeaders is set, then only those headers are 
signed.

I then ask Alt-N about the nAllowUnsignedFromHeaders feature and to 
inform them if the change I made with nUseRequiredHeadersOnly.

That is why I found out why they needed nAllowUnsignedFromHeaders 
because a customer incident reported the multiple 5322.From issue.

I was able to confirm this and I traced the logic of 
nAllowUnsignedFromHeaders and saw that it doesn't stop multiple 
5322.From (N) but rather it enforces that each one was included in the 
h= tag.

So while the trick to add N+1 "from" values to the h= tag would help 
mitigate this,  we don't know if most applications give an operators 
option to set the exclusive headers to sign.

I did because I wanted to explore different h= headers signing setup 
especially with integrated list operations.  For example, the operator 
configuration default:

#---------------------------------------------------------------------
# Signing Options for author-domain section
#
# Possible values for canon=
#
# DKIM_CANON_SIMPLE
# DKIM_CANON_NOWSP
# DKIM_CANON_RELAXED
# DKIM_SIGN_SIMPLE
# DKIM_SIGN_SIMPLE_RELAXED
# DKIM_SIGN_RELAXED
# DKIM_SIGN_RELAXED_SIMPLE
#
# [<AUTHOR-DOMAIN>]
# signer                 = <SIGNER-DOMAIN>    # this is the signature 
d= tag
# selector               = <SELECTOR>         # this is the signature 
s= tag
# Canon                  = DKIM_SIGN_SIMPLE   # canonization
# IncludeBodyLengthTag   = 0                  # opt, 1 - include l= 
tag body size
# IncludeTimeStamp       = 1                  # opt, 1 - include t= 
tag timestamp
# IncludeQueryMethod     = 0                  # opt, 1 - include q= tag
# Hash                   = 1                  # req, 1 - SHA1, 2 - SHA256
# IncludeCopiedHeaders   = 0                  # opt, 1 - use z= tag
# Identity               =                    # opt, i= tag
# ExpireTime             = 0                  # opt, days, adds x= tag
# UseRequiredHeadersOnly = 1                  # opt, 1 - used 
szRequireHeaders
# RequiredHeaders        = 
From:To:Date:Message-Id:Organization:Subject:List-ID
#---------------------------------------------------------------------

I wanted to ability to always have the List-ID to handle both type of 
streams, private email and list email with one default setup.  It 
would also help to protect against replay by a foreign list server.

What I can do now with our setup is change the default to:

  RequiredHeaders = 
From:From:To:Date:Message-Id:Organization:Subject:List-ID

So the "kludge" idea is good, but we don't know if most other DKIM 
application implementations offer this.  I believe Levine is correct 
on this point that most implementations may not be this flexible.

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Oct 2010 15:27:55 -0400

Scott Kitterman wrote:

>  Murray S. Kucherawy wrote:

+1.

Well, then again, one side of my is trying to be cooperative and 
sensitive of those who want to "rush" the document.  Minimize text 
with not saying too much.

But the other side is saying technically "Fix this ASAP" - get the 
proper protocol semantics in in the 4871bis specs and use this 
incident or at least prepare a response ready against any negative PR 
that could emerge as a plus to enhancing the marketability of DKIM as 
a tool that helps solved a 25+ year old problem.

---

From: Wietse Venema <[email-masked]>
Date: Fri, 8 Oct 2010 16:15:56 -0400 (EDT)

> It depends on the Application implementation of DKIM.

What I describe would be a best practice application of DKIM
mechanisms that already exist.

Mail is signed as if there are N+1 instances of each header that
is covered by the DKIM signature.  The verifier will then fail if
any such header is added after-the-fact.

With this, there is no need to rely on enforcement mechanisms
outside DKIM, such as the correct implementation of RFC 5322.

	Wietse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Oct 2010 13:30:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Wietse Venema
> Sent: Friday, October 08, 2010 1:16 PM

I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6.  For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages.

---

From: Wietse Venema <[email-masked]>
Date: Fri, 8 Oct 2010 17:01:56 -0400 (EDT)

Murray S. Kucherawy:
> I would suggest constraining that to include only those fields
> that are 0-or-1 in RFC5322 Section 3.6.  For example, doing this
> with Received: is begging for signature invalidation on otherwise
> unaltered messages.

I see your point, but there are more "sensitive" headers than the
0-or-1 headers in RFC 5322 (IIRC, the N+1 signing method was
introduced to protect MIME headers).

I suppose that the guidelines for best practice application of DKIM
could recommend what headers to sign with the N+1 signing method.
These guidelines can be updated as RFC 5322 evolves, and as standards
that extend RFC 5322 introduce new "sensitive" headers.

	Wietse

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Oct 2010 17:40:42 -0400

> in the list have occured twice.

If you think that that's all it means to comply with 5322 then you should
go and read 5322 again. Line lengths. Bare CRs or LFs. ABNF from atoms
on up. Timestamp format. Message-ID format. Address structure in any
of To, From, Cc, Reply-To and so on. Similarly for all the Resent-* variants
of those. And that's before you get to the really ugly obsolete header formats.

I'm not aware of existing code that does all that - and if it were found or
written, it would reject mail that's successfully delivered today.

If one were to add the "MUST" mentioned upthread then
a DKIM validator would be _required_ to implement all that checking
and to decline to validate mail that would commonly be delivered.

If you want to talk about adding some minimal header checking to
DKIM then go right ahead, it seems like a reasonable thing to discuss
 - but take it to a new thread, rather than this one, as it's an entirely
different thing than requiring all DKIM validators to also be 5322
validators.

Cheers,
  Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 8 Oct 2010 17:49:08 -0400

> [email-masked]] On Behalf Of Wietse Venema
> Sent: Friday, October 08, 2010 1:26 PM
the
> fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike,
don't
> > > Is there precedent of this being done elsewhere, i.e. compensating
in
> one protocol for abundant lousy implementations of a layer below it?
> >
> >
> > I'm a bit confused.
> >
fix
> an edge
> > condition that is only a theoretical issue and only fixes a problem
that
> is

Whether this is the correct solution or not, I want to thank everyone
from moving away from "kick the can" somewhere else to discussing the
issue with a view to resolving the problem.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 08 Oct 2010 17:33:41 -0400

Hence my original post with the suggested "special consideration" text 
for section 5.4 in regards to 5322.from.

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Oct 2010 19:20:34 -0400

> for section 5.4 in regards to 5322.from.

My apology to Jeff.  It was not Jeff Macdonald who wrote the text 
above. This was not an attempt at a spoof.  I somehow replied to the 
wrong message and my MUA (ThunderBird) somehow used the wrong From: 
address with the text I was writing.  My Apology to Jeff.

---

From: "John R. Levine" <[email-masked]>
Date: 8 Oct 2010 23:19:59 -0400

> I would suggest constraining that to include only those fields that are 
> 0-or-1 in RFC5322 Section 3.6.  For example, doing this with Received: 
> is begging for signature invalidation on otherwise unaltered messages.

Signed Received headers at all is asking for trouble, but I take your 
point.  So here's a 0th cut at a list of headers where we should recommend 
N+1 entries in the h=

rfc 5322

   From
   Sender
   Reply-To  (maybe not, since often smashed by mailing lists)
   To
   Cc        (not Bcc even though it's 0/1)
   Message-ID
   Subject
   Date

rfc 4021

   MIME-Version
   Content-Type

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 9 Oct 2010 11:25:56 -0400

Shit happens :)

-- 
Jeff Macdonald
Ayer, MA

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Oct 2010 12:40:33 -0400

John R. Levine wrote:

> So here's a 0th cut at a list of headers where we should recommend 
> N+1 entries in the h=
> 
> rfc 5322
> 
>    From
>    Sender

I would focus on the main rendering items, the ones common across the 
mail universe of devices, gated systems, etc.

     From:            required by 822/2822/5322
     Date:            required by 822/2822/5322
     Subject:         optional 822/2822/5322
     To:              required by 822, optional 2822/5322

The others are related to Network Control Lines and are generally 
hidden and only the ones necessary for a "reply" (if different than 
the From) may be kludged in.  I know this is old school but it still 
applies today.

Many systems do a "Valid Header" check in order to see if a header 
block needs to be generated.  This is what allows a human or simple 
mail bot (print, fax job, etc) to enter no headers in a DATA state and 
still get mail through because the fields can be filled:

     From:            <--- 5321.MAIL FROM
     To:              <--- 5321.RCPT TO
     Date:            <--- Local Computer Timestamp
     Subject:         <--- left blank or filled with (NO SUBJECT)

That said....

I don't see incentives to spoof:

     Message-ID
     MIME-Version
     Content-Type

What are the gains?

The Sender: can change too, like in a list.

Not sure about CC:  I guess it should be included.

I think for 4871bis, we should keep it simple with focusing on the 
main security hole, 5322.From (and also make a statement that 
regarding RFC5322).

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Oct 2010 12:42:57 -0400

I'm still trying to figure it out how that happen with Thunderbird. It 
has to be a click and drag thing with my old hands :)

-- 
HLS

Jeff Macdonald wrote:
>> My apology to Jeff. �It was not Jeff Macdonald who wrote the text
>> above. This was not an attempt at a spoof. �I somehow replied to the
>> address with the text I was writing. �My Apology to Jeff.
>>
>>
>> --
>> Hector Santos, CTO

---

From: "John R. Levine" <[email-masked]>
Date: 9 Oct 2010 14:10:30 -0400

> I don't see incentives to spoof:

This has been discussed at great length.  Please consult the list 
archives.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Oct 2010 15:47:07 -0400

John R. Levine wrote:
> This has been discussed at great length.  Please consult the list archives.

Thanks - you couldn't summarize or its too hard to explain?

I can search, certainly not consult.   But let me "consult" GOOGLE:

      MIME-Version Exploits IETF-DKIM

Without going nuts looking all the results, I see whats in 4871 section

     8.1.1.  Addition of New MIME Parts to Multipart/*

and this seems about the l= body size issue which most people already 
agreed is a bad idea.

I don't see how the 5322.Mime-Version header can be exploited.

Anyway, never mind.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Oct 2010 10:36:28 +0100

> If I am mistaken then please correct me.

You are indeed mistaken.

All you have ensured is that any message signed (say by ebay) is proof  
against reply attacks that add additional headers.

But the scam we are considering does not involve replay attacks at all. It  
involves a message created and signed by the scammer using his own key.

Naturally, scammers feel no obligation to follow advice or requirements in  
standards, so they will sign just one instance of the two headers.

The ONLY way to defeat this scam is for the Verifier to count the headers  
itself. And the threat is serious enough that the counting has to be a  
MUST.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 11 Oct 2010 10:35:47 +0100

> But it IS a serious protocol endangering problem.

No, I don't think so. The protocols are quite clear. rfc5322 section 3.6 
says there must be exactly one From: header. If there are two, then you 
don't have a compliant email. Why any software should assign a positive 
trust value (like claiming the Author address has been verified) to a 
non-compliant email, I don't know. Anyway, this is clearly a problem with 
rfc5322 compliance, not with DKIM.

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

---

From: Wietse Venema <[email-masked]>
Date: Mon, 11 Oct 2010 09:07:03 -0400 (EDT)

> involves a message created and signed by the scammer using his own key.

Please read my entire response carefully before responding.

The above detects the case where a bad guy adds a forged header to
a DKIM-signed message, in the hope that naive mail programs will
render their forged header with an indication that THE GOOD GUY'S
DKIM SIGNATURE VERIFIED.

When the bad guy sends mail with (multiple) forged headers, the
best they can get is that naive mail programs render their forged
header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED.

Sending forged headers with bad guy's DKIM signatures is not an
interesting attack on DKIM.

	Wietse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Oct 2010 10:04:39 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Eiloart
> Sent: Monday, October 11, 2010 2:36 AM
> To: Charles Lindsey; DKIM
> non-compliant email, I don't know. Anyway, this is clearly a problem
> with rfc5322 compliance, not with DKIM.

+1

-MSK

---

From: Wietse Venema <[email-masked]>
Date: Mon, 11 Oct 2010 18:05:13 -0400 (EDT)

Charles Lindsey:
> On the contrary, it is an exceedingly interesting attack.

If you believe that sending mail with a valid bad guy signature is
an interesting attack on DKIM, then that implies that you're willing
to believe mail that is signed by arbitrary strangers.  That is a
problem that DKIM is not designed to solve.

	Wietse

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Oct 2010 15:18:09 -0700

On 10/11/2010 3:05 PM, Wietse Venema wrote:
> to believe mail that is signed by arbitrary strangers.

Well...

But it's not an attack on DKIM.

It's not really an 'attack' on anything, but the most one could claim is that 
it's an attack on the recipient's reputation data base, or failure to use one.

The DKIM part is used correctly and works fine.  So there's no 'attack'.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Oct 2010 15:26:02 -0700

> problem that DKIM is not designed to solve.
Use of a pre-pended From could be for [email-masked], where the 
valid signature could be for [email-masked].  It seems important to 
keep this from being an attack vector, as bad actors might send 
themselves their messages to replay them in a deceptive fashion.  Its 
not hard to imagine this becoming a problem.  It also seems unlikely to 
have messages from a large provider blocked when a few of their messages 
are used in an attack that they did not directly issue.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Oct 2010 16:13:30 -0700

> Sent: Monday, October 11, 2010 3:18 PM

I would even submit that it's an attack on user confidence via MTAs and/or MUAs that are too forgiving of invalid syntax.

But that was a problem before DKIM even existed anyway.

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Oct 2010 21:23:45 -0400

> The DKIM part is used correctly and works fine.  So there's no 'attack'.

Thats "poster framing" material.

I sure hope you are right.  After all, President Obama did get by your 
defenses on your list.

   No Signature, Double From ---> Trapped/rejected by mipassoc.org
   DKIM signed Double From  ----> Accepted, Resigned by mipassoc.org

So without DKIM, 100% RFC5322 compliant - trapped multiple 5322.From 
headers.  With DKIM, there is a loophole.  Go figure.

Lets hope this DKIM exploit does not become common place and surprises 
a bunch of layman operators.  At the point, you can say you were aware 
about it.

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 21:49:51 -0400

50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in your example its the operator and how they determine reputation

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 09:36:42 -0400

> 50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in your example its the operator and how they determine reputation

Please read what was said.

If mipassoc.org is going to an "example" of many systems, then we have 
a unfortunate problem until current systems are updated to prevent the 
DKIM loophole for what is otherwise RFC5322 checking systems.

What it means for most systems that they need to change a model based 
on this:

      CHECK DKIM     ---- PASS  --> ACCEPT
      CHECK RFC5322  ---- BAD   --> REJECT
      BREAK
      RESIGN
      DISTRIBUTE

To this:

      CHECK RFC5322  ---- BAD   --> REJECT
      CHECK DKIM     ---- PASS  --> ACCEPT
      BREAK
      RESIGN
      DISTRIBUTE

---

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

>     No Signature, Double From ---> Trapped/rejected by mipassoc.org

Really? You tested this? I assumed the message was accepted because it 
contained a From: header belonging to a list member. Not because it was 
signed.

>     DKIM signed Double From  ----> Accepted, Resigned by mipassoc.org

Yes, we saw that.

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 13:02:41 -0400

Ian Eiloart wrote:

> Hector Santos <[email-masked]> wrote:

> contained a From: header belonging to a list member. Not because it was 

The list checks the 5321.Mail From address (return path), not the 
5322.From.

Yes, tested twice.  I got a bounce back from the list saying it was 
waiting moderator approval and it gave me the opportunity to click a 
URL to cancel the submission.

GMAIL imports it the spam box as a "NO SUBJECT" message because it 
stripped all headers and recreates its own.

You will find this common with many MTA that use a "Valid 822 or 
2822/5322" detector.

Let me try it again...  Yup.  I created a 5322 message with two 
5322.From and no signature:

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

    ENV-FROM: <[email-masked]>
    ENV-TO: <[email-masked]>
    ENV-DATA:
    From: President Obama <[email-masked]>
    Message-ID: <[email-masked]>
    Date: Mon, 12 Oct 2010 12:24:11 -0400
    From: Hector Santos <[email-masked]>
    Subject: Non-signed, double from
    User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
    MIME-Version: 1.0
    To: [email-masked]

    Non-signed, double from

    --
    HLS
               ------------------------------

When I put that message in the router outbound spool, the MTA routed 
it to mipassoc.org and this is the list approval message I just received:

               ------------------------------
EYrWHRYjdfdVipu0RZ4kvY8vYtkbsZLHvtqtXdi2cgu16xWxuwltYn/+MmPmEufyu47
	GtNzERKTf0Tbp+4Hm8EmjayZI3pP0tlkDrZ+cSkfxwwKOm7EBvF+9xrPlmB1k=
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Your message to ietf-dkim awaits moderator approval
From: [email-masked]
To: [email-masked]
Message-ID: <[email-masked]>
Date: Tue, 12 Oct 2010 09:46:01 -0700
Precedence: bulk
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
X-List-Administrivia: yes
Sender: [email-masked]
Errors-To: [email-masked]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 
(sbh17.songbird.com [127.0.0.1]); Tue, 12 Oct 2010 09:46:08 -0700 (PDT)

Your mail to 'ietf-dkim' with the subject

     (no subject)

Is being held until the list moderator can review it for approval.

The reason it is being held:

     Message has implicit destination

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:
 
http://mipassoc.org/mailman/confirm/ietf-dkim/c3ab82450dcdff2c7e15dcfc1748c57f69c4e956
               ------------------------------

So this is to show you that it isn't about a receiving MTA not being 
compliant with RFC 5322, it is about a DKIM loophole.  Thats not to 
say any component in the integrated mail network is not responsible 
for RFC5322 checking, but DKIM can not expect everyone to do it right, 
thus it needs to check for itself.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 00:12:05 -0400

> contained a From: header belonging to a list member. Not because it was

You are correct.  The list accepts submissions only from subscribers, as checked 
in the From: field.  This test message failed that stricture.

d/

-- 

   Dave Crocker

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 13 Oct 2010 10:28:08 +0100

> this posting, please visit the following URL:

Strange. That message suggests that the list address is Bcc'd, which isn't 
the case. It may be that Mailman is parsing the message incorrectly. Or 
ceasing to parse it when it finds the second header. A similar behaviour 
might explain why Gmail is not detecting the "Subject:" header.

What happens if you do the same thing, but put the "To:" header above the 
"From:" headers? What about when it's between the two "From:" headers?

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:34:32 +0100

>       CHECK DKIM     ---- PASS  --> ACCEPT

But full 100% RFC5322 checking is extremely tedious, and is more that we  
actually need.

What we want is more like
         CHECK DKIM && CHECK RFC5322 headers included in h= tag --> ACCEPT
where at least the CHECK RFC5322 counts the number of occurrences, perhaps  
a little more, but not worry about the more obscure checks such as LFCR  
instead of CRLF.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:12:05 +0100

> render their forged header with an indication that THE GOOD GUY'S

Yes, and that is relatively easy to guard against by careful signing. But
it is not the scam I am talking about.

On the contrary, it is an exceedingly interesting attack.
It is in fact exactly and precisely the attack against which we currently
have NO DEFENCE.

The bad guy (the phisher) provides two From headers, but only signs one
which, as DKIM is currently defined, has to be the second one.

His two headers are:

     From: [email-masked]
     From: [email-masked]

BUT many/most MUAs currently display only the first From header if two are
provided. There is no reason why the verifier at the boundary should
report an invalid signature, so the message gets through to the intended
victim who just sees what his MUA shows him, which apparently is a message
  from the genuine ebay address.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 09:54:23 -0700

> Sent: Wednesday, October 13, 2010 9:12 AM
> To: DKIM
> victim who just sees what his MUA shows him, which apparently is a
> message from the genuine ebay address.

This is true if the message is not DKIM-signed at all.  The rendering choice you're highlighting here already exists in many/most MUAs.

If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem?

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:25:42 +0100

>> On the contrary, it is an exceedingly interesting attack.

Note that Wietse is replying to a message that I mistakenly sent to him  
offlist. I have now reposted that messqge for all to see.
> problem that DKIM is not designed to solve.

The average naive user never gets the chance to be willing or not to  
believe mail that is signed by arbitrary strangers, for the simple reason  
that his MUA does not routinely display any headers that mention  
signatures at all. All he sees is a message apparently From a known  
genuine ebay address (his MUA happens not to show the second From placed  
there by the phisher).

Worse, he may be vaguely aware that his provider/boundary implements some  
amazing crypto stuff that purportedly guarantees that forged email From  
genuine ebay addresses will be stopped, and that will reinforce his belief  
that the message he saw is genuine.

And yet the tests provided by his provider/boundary are 100% 4871  
compliant. Surely this shows that there is something seriously wrong with  
4871, which is clearly not providing the service it was supposed to.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 13:04:44 -0400

> "From:" headers? What about when it's between the two "From:" headers?

Actually, the chairs would rather take this off the DKIM mailing list,
as out of the group's scope.  If some folks want to go do some testing
about what different DKIM verifiers do in these situations, and post a
summary report afterward, that's fine.  But let's not focus the
group's attention on ongoing experiments.

We're all well aware that

1. a message with multiple "from" headers is not in compliance with
the standards, and

2. when presented with a non-compliant message, different MDAs and
MUAs (and possibly MTAs) will do different, inconsistent things,
including rejecting or discarding the message, altering it to try to
make it compliant, accepting it as is but displaying it in
unpredictable ways, and so on.

We also seem to agree that we have to address this situation in the
spec.  For this group's purpose, what matters is the text we put into
the document.  Let's stick to getting consensus on that.

Barry, as chair

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 14:27:29 -0400

> If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem?

I agree with this.

And even if there was a DKIM signature, it is the BAD GUY'S signature,
which should cause it to go into the SPAM folder, with a large
phishing warning.

<rant>
Count me as one of those who was confused early on about what DKIM
provides. DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It should just provide an
identifier that can be verified. Instead of using the body for
hashing, use the Message-ID header along with the Date header and just
hash that. That way most folks would understand DKIM is just providing
an Identifier.
</rant>

-- 
Jeff Macdonald
Ayer, MA

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 14:33:04 -0400

Murray S. Kucherawy wrote:

> If we can extract DKIM from the equation entirely and the 
> problem remains, how is it a DKIM problem?

Because DKIM raises the bar and begins to bind headers that it 
required to be *exclusively* correct - a new level of thinking and 
concept that is above and beyond any other email requirement we ever had.

That means that all DKIM implementations *MUST* check its own DKIM
requirements.  It can no depend on other layers which by its (erroneous)
8.14 premise, there are many that are not compliant with 5322.

Just because the problem predated DKIM does not excuse DKIM from doing
what it suppose to do.  All this means is that DKIM verifiers (and 
signers) MUST make sure there are no multiple 5322.From.

Remember, the theme premise in section 8.14 is:

    Many email implementations do not enforce [RFC5322] with
    strictness.	As discussed in Section 5.3 DKIM processing
    is predicated on a valid mail message as its input.

That alone says DKIM started with a known problem and a requirement
to make sure its input is correct in order to function correctly in 
order to cover all loopholes.

This is by far a DKIM issue. The reality is that there are systems 
that do perform strict RFC  822/2822/5322 checking.  But as I already 
shown, there are DKIM implementations that are bypassing it.

Saying RFC 5322 compliance is required is simply not enough.  DKIM is 
a technology that requires that it checks for such faults.

*Seriously*

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 11:37:54 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
> Sent: Wednesday, October 13, 2010 11:27 AM
> To: DKIM

Then you send me a piece of signed mail, I change everything except the Message-ID and Date, and send it to someone else.  And the verifier will green-light it, meaning you've taken responsibility for it.  Are you OK with that?

My way of thinking about this is that verification of a message is equivalent to collecting all the pieces (header, body, signature) and coming to you and saying "Do you take responsibility for this?"  If I get your public key from DNS and everything lines up, you're implicitly saying "yes".

Now, if I remove the whole body and most of the header from what I'm presenting to you for that question, you're now possibly saying "yes" to content you didn't create.  Are you OK with that?

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 14:40:45 -0400

On 10/13/2010 2:27 PM, Jeff Macdonald wrote:
> DKIM seems to make assurances to message integrity. But it

my goodness, but your version of ranting is far too mild and reasonable.

which is not to say i agree with you about tossing out the body hash.

Although DKIM is not trying to "protect" the message, it /is/ trying to reduce 
the ability to take a valid use for one message and apply it to an invalid use 
with another.

 From a mathematical standpoint, your suggestion is quite reasonable, given that 
message ids are supposed to be unique, etc.  But the question is whether a 
verifying can know whether a signature is being replayed -- that is whether it 
is being reapplied to a different message.

Verifiers do not track message ids.  So they can't detect a new use.

Using the body hash is a convenient hack that is likely to make it nearly 
impossible to apply valid use of a DKIM identifier to different content.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 13 Oct 2010 11:42:55 -0700

> hash that. That way most folks would understand DKIM is just providing

The reason for the body hash is solely to prevent replay attacks - where a spammer
receives legitimate email, then reuses the signature to send out spam.

That's the only reason it's there, not for anything to do with message integrity,
but it is a good reason for it to be there.

That this has been documented and evangelized poorly is something to
rant about, perhaps.

Cheers,
  Steve

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 15:14:05 -0400

On Wed, Oct 13, 2010 at 2:40 PM, Dave CROCKER <[email-masked]> wrote:
> Although DKIM is not trying to "protect" the message, it /is/ trying to
> reduce the ability to take a valid use for one message and apply it to an
> invalid use with another.
>
> From a mathematical standpoint, your suggestion is quite reasonable, given
> that message ids are supposed to be unique, etc.  But the question is
> whether a verifying can know whether a signature is being replayed -- that
> is whether it is being reapplied to a different message.
>

All valid points, but the implementation is being misunderstood. It is
to late for this now, but if the initial criteria included prevent
replay and not use the body, what implementation would of been thought
up instead? No need to answer that, like I said, I was ranting.

-- 
Jeff Macdonald
Ayer, MA

---

From: "John R. Levine" <[email-masked]>
Date: 13 Oct 2010 15:17:19 -0400

> remains, how is it a DKIM problem?

But it doesn't.  Absent a DKIM signature, nobody's making any assertions 
about incoming messages, and there's no reason to treat duplicate headers 
as anything beyond a software bug.

With a valid DKIM signature from a credible signer, I would really like to 
be able to drop a message into the recipient's inbox without further 
processing.  If I have to run it through spamassassin anyway to detect 
message mutations that DKIM doesn't, its utility is vastly less.

We put a bunch of stuff in DKIM to allow benign modifications of messages, 
notably relaxed canoncalization.  (We can argue about whether l= is 
useful, but it's easy enough to ignore if one thinks it isn't.)  I think 
it's also reasonable to put stuff in to disallow malevolent modifications.

I'm certainly not suggesting a full 5322 body cavity search, but I think 
reasonable checks would include checking for duplicates of headers that 
MUAs are likely to show, such as Subject, To, From, Sender, and Cc.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Oct 2010 14:45:50 -0400

On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
> > [mailto:[email-masked]] On Behalf Of Charles Lindsey
> > BUT many/most MUAs currently display only the first From header if two
> > are provided. There is no reason why the verifier at the boundary should
> This is true if the message is not DKIM-signed at all.  The rendering
> choice you're highlighting here already exists in many/most MUAs.
> 

If the DKIM signature doesn't verify after signed headers have been altered, 
then it's not.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Oct 2010 14:47:54 -0400

> which should cause it to go into the SPAM folder, with a large

No.  That misses the point entirely.  The problem here is that one can take a 
DKIM signed message that is signed by any entity and add additional 
From/Subjects and the message may still appear to be the one signed by the 
original entity even though it's been modified post-signature.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 12:30:00 -0700

> Sent: Wednesday, October 13, 2010 11:46 AM
> If the DKIM signature doesn't verify after signed headers have been
> altered, then it's not.

I don't understand how that follows.  I'm talking about a dual-From: message that wasn't signed at all.  An MUA will still show the "wrong" one.  So I fail to see why a DKIM specification needs to make a normative requirement about a problem that's been around since years before the acronym "DKIM" ever appeared anywhere.

---

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

> From: John R. Levine [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2010 12:17 PM
> To: Murray S. Kucherawy
> Cc: DKIM

I'm concerned that if we name that specific check, that's all people will do and then think they're safe.  And later some other "attack" will come to light, and because we didn't just say the message has to be compliant overall, we've now left a hole behind.  We'll never be finished.

And as a developer I have a problem with something up in the higher layers trying to compensate for bugs, complacency or misguided attempts at being "nice" in the lower layers or adjacent higher layers.

DKIM simply highlights an issue that's been there for a very long time now.  The right way to fix a problem is to deal with it where the problem exists, not to scatter bandages all over the place.

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 15:47:46 -0400

> Now, if I remove the whole body and most of the header from what I'm presenting to you for that question, you're now possibly saying "yes" to content you didn't create.  Are you OK with that?

The only thing I'm willing to say "yes" to is that I created that
identifier and nothing more.

Enhancements to my rant would be to include the To: header as well.

The point is DKIM provides a verifiable identifier. If there is
anything in the spec that leads one to believe it provides more than
that, it needs to be fixed.

But like I said, I was ranting.

-- 
Jeff Macdonald
Ayer, MA

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 15:59:27 -0400

> original entity even though it's been modified post-signature.

Right. I had understood that and then forgot.

If DKIM is just viewed as providing an identifier and nothing more,
then this is a MUA problem.

If DKIM is viewed as providing more than an identifier, then this is a
DKIM problem.

-- 
Jeff Macdonald
Ayer, MA

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Oct 2010 13:01:41 -0700

> But like I said, I was ranting.

Jeff, an identifier that's not bound to something is useless. It's
like "Mike" just bouncing around the aether. Until it binds to
something, it's not providing anything useful and certainly not
something you'd want to alter the message disposition.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 13 Oct 2010 16:09:34 -0400

> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Wednesday, October 13, 2010 3:59 PM

What is the value of "an identifier" vs "a stable identifier"? IF all you are willing to say about "an identifier" is yep, that's mine and nothing else, what is the value to an evaluator if the message body and various headers can be modified? I've always viewed DKIM as weak rather than strong but this reduces it to the edge of meaningless.

> If DKIM is viewed as providing more than an identifier, then this is a

This moves us in the direction of what is the use case for the identifier. I've said for a long time (from a phishing perspective) that if we let "bad" stuff (from a brand perspective) get to the enduser then it is game over (and yes, I realize that perfection is not necessarily achievable). This is why I am focused on the MTA rather than the MUA.

Having said that, if an MUA is going to present an indication of "DKIM PASS" to the enduser, then a reasonable person would expect some relationship between what is "passed" and what is presented to the enduser.

I understand the issues raised by Murray about the slippery slope. On the other hand, I would rather see an MUA present nothing about DKIM than give a false impression to endusers.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 16:14:55 -0400

> something you'd want to alter the message disposition.

It is bound to 3 header fields. To, Date and Message-ID. I hear some
MTA's have a feature of preventing message duplication. An enhanced
verifier could provide a "replay preventer" feature.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 13:49:38 -0700

> Sent: Wednesday, October 13, 2010 1:15 PM
> To: DKIM WG
> Subject: Re: [ietf-dkim] What DKIM provides, again
> 
> It is bound to 3 header fields. To, Date and Message-ID. 

If I can go around stamping your three signed header fields and your identifier on anything I please, I think the value of that stamp and identifier will quickly approach zero or even go negative.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Oct 2010 17:14:16 -0400

>> It is bound to 3 header fields. To, Date and Message-ID.

Folks, this thread is out of scope.  It's a horse that was beaten to
death years ago, and it left the barn door open until the cows came
home.

We are not going to change the scope of the DKIM signature, certainly
not to that extent, and it's just a waste of brain cells to think
about it.  Please don't make us waste more brain cells than we already
are.

Barry, as chair

---

From: John Levine <[email-masked]>
Date: 13 Oct 2010 21:47:27 -0000

>I'm concerned that if we name that specific check, that's all people
>will do and then think they're safe.  And later some other "attack"
>will come to light, and because we didn't just say the message has to
>be compliant overall, we've now left a hole behind.  We'll never be
>finished.

I understand your concern, but it strikes me as being at the same
level as the various arcane attacks on relaxed canonicalization, e.g.,
adding a lot of white space to make ASCII art.  There's a difference
between "do this and you're safe" and "if you don't do this, you're
not safe."  Based on an extensive two-minute survey of MUAs, I see
that if there are two subject or From lines, T'bird shows the first,
Alpine and Evolution show the second, so header stuffing is not a
purely hypothetical problem.

>DKIM simply highlights an issue that's been there for a very long time now. 

No.  No, no, no, no, no.  Malformed messages only become an issue when
someone aserts that they're not malformed.  In the absence of DKIM
signatures, the reasonable thing to do with a malformed message is to
render it.  In the presence of a DKIM signature, the reasonable thing
is something else.  That's why this is a DKIM issue.

R's,
John

---

From: "Mark Delany" <[email-masked]>
Date: 13 Oct 2010 13:59:17 -0700

On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly wrote:

> Having said that, if an MUA is going to present an indication of
> "DKIM PASS" to the enduser, then a reasonable person would expect
> some relationship between what is "passed" and what is presented to
> the enduser.

That makes sense. And at least one MUA already renders DKIM verified
mail differently. I would think such an MUA could take the additional
step of rendering verified payload differently too.

I know we're not in the MUA business, but if DKIM makes no difference
to what an end-user finally sees, then it serves a very limited
purpose indeed.

> I understand the issues raised by Murray about the slippery
> slope. On the other hand, I would rather see an MUA present nothing
> about DKIM than give a false impression to endusers.

I can understand the engineering nervousness over crossing layers, but
that seems to me to be conflating the SMTP aspects of an MTA with the
DKIM aspects of an MTA/verifier.

It strikes me that a DKIM verifier is already well into the business
of 2822 semantics as it knows about headers, header labels,
continuation syntax, header/body boundaries and so on.

In that light, taking an additional step wrt duplicate headers (or
malformed 2822 in general) is still in the same layer as the verifier.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 15:10:10 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2010 2:47 PM
> Cc: Murray S. Kucherawy

Do Alpine or Thunderbird or whatever else do anything special now when a message is signed, whether or not the signature(s) pass or fail?

Current modules that don't do the kind of enforcement people are demanding and that isn't exacerbating anything.  When they add DKIM support in some way, I imagine those MUAs will become aware of the problem and do the "something else" you're talking about.

I'm fine with providing some informative guidance about that to MUAs, but that's different than telling verifiers that they are required to enforce something that's not specifically within their scope.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Oct 2010 15:12:51 -0700

> is something else.  That's why this is a DKIM issue.

Huh? I think it's highly debatable about whether it's reasonable to just
render a malformed message, especially in this day and age. Which is why the
addition of DKIM is largely orthogonal.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 15:15:47 -0700

> Sent: Wednesday, October 13, 2010 1:59 PM

My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications.  For example, we wouldn't include in an SMTP specification some text about dealing with fuzzy TCP implementations, and what people are talking about here makes just as much sense to me.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 13 Oct 2010 15:19:07 -0700

> malformed 2822 in general) is still in the same layer as the verifier.

I'm a little leery about going that far conceptually, but I'm happy with
"any piece of code that verifies DKIM should do some basic 822
sanity checking too".

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 18:19:03 -0400

+1.

Personally, I think 5322.From is the main thing but if you wish to 
include the others, I'm good with that.

I think the main point is we have a real chance here to finally solve 
or address a long time 822/2822/5322 issue that only DKIM can claim 
today to help resolve or prevent from getting exploited in the future 
and if it help create in incentive for these checks to be done at MSA, 
MDA including when these systems use DKIM bypassing existing checks, 
the better.

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 18:26:29 -0400

> I don't understand how that follows.  I'm talking about a dual-From: message that wasn't signed at all.  An MUA will still show the "wrong" one.  So I fail to see why a DKIM specification needs to…

No one is saying that DKIM is at fault for the old problem.  But it is 
at fault when it fails to do anything about it when it can and is 
designed to do this.

The issue again is section 5.4 saying only to sign the last one when 
there are duplicates.

Well, it failed to provide the normative information that there could 
only exist one 5322.from and provide an exception rule for this.

It provided a note about the "Comment" header.  It needs to do one for 
5322.From and others.

The problem with the updated text is that it makes it sound like its 
an optional consideration to check for this because it tries to lie 
the burden on others for the problem.

Sure, the problem existed but only now is there a focus on how this 
can be a real problem because of the "trust" part the DKIM tries to 
add to the picture.

---

From: "Mark Delany" <[email-masked]>
Date: 13 Oct 2010 17:56:44 -0700

> My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications.  For example, we wouldn't include in an SMTP spec…

The problem is that I don't think we are really just talking about
getting a protocol right from a bits perspective.

If DKIM has any value it's that it ultimately affects the user mail
experience for the better. Consequently, to remain silent on matters
that we know will adversely affect that experience seems
contradictory. Similarly to not offer guidance to implementors on the
sorts of things they can do to maximize the value of DKIM seems
similarly to miss the point.

Furthermore, DKIM specifically came into existence to deal with an
adversarial environment whereas 821/822 and the like have very
specific "just get the bits right" goals.

So guiding verifiers to assume the worst seems consistent with our
intent or at least our genesis.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 21:17:31 -0400

+1, well said Mark.

Its a real potential situation that is on par, IMTO, with what the 
DKIM technology was suppose to help with.  It was unfortunate it fell 
through the cracks during the Threats Analysis RFC 5016 production. If 
it was realized back then, I don't think anyone would be debating who 
is the blame and what was needed to be done (written into the RFC 4871 
specs).

In retrospect, I recall most discussions was around multiple addresses 
possible in the single 5322.From header and how to deal with that, 
especially in regards to redundant POLICY lookups.

If I recall, the consensus was that only the first address in the 
potetial list of from addresses in the single 5322.From header was the 
only important author domain for POLICY considerations.

Mark Delany wrote:

>> Murray wrote:
>> My objection isn't so much layering within the software, 
>> because I know that gets mushy real quick, but layering among 
>> the protocol specifications.  For example, we wouldn't include 
>> in an SMTP specification some text about dealing with fuzzy 
>> TCP implementations, and what people are talking about here 
>> makes just as much sense to me.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Oct 2010 22:56:51 -0400

On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote:
> > No.  That misses the point entirely.  The problem here is that one can
> > take a DKIM signed message that is signed by any entity and add
> > additional From/Subjects and the message may still appear to be the one
> > signed by the original entity even though it's been modified
> > post-signature.
> 

The identifier only makes sense within a context.  For DKIM that context is the 
signed content.  For the identifier to be meaningful, it has to be connected to 
the actual content of the message, if not, the identifier could be arbitrarily 
reused and would serve little purpose.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 23:01:19 -0400

> it's also reasonable to put stuff in to disallow malevolent modifications.

Putting things in to be more robust against vagaries of travel is quite 
different from adding things to resist actual attack.

In particular, note that nothing being discussed, here, invalidates the 
signature.  The topics being discussed concern processing that really is outside 
of DKIM.  Therefore its discussion is outside of DKIM.

Most of the confusion is exactly the difference between DKIM as a labeling 
technology versus DKIM as a "message protection" technology.

On 10/13/2010 3:30 PM, Murray S. Kucherawy wrote:
 > I'm talking about a dual-From: message that wasn't signed at all.  An MUA
 > will still show the "wrong" one.  So I fail to see why a DKIM specification
 > needs to make a normative requirement about a problem that's been around
 > since years before the acronym "DKIM" ever appeared anywhere.

+1

On 10/13/2010 3:47 PM, Murray S. Kucherawy wrote:
 > I'm concerned that if we name that specific check, that's all people will do
 > and then think they're safe.

Exactly!  We are not tasked with dealing with the larger security issues and 
this is but a piece of it.  Tackling only this tiny piece constitutes woefully 
incomplete work and it's really out of scope.

 > DKIM simply highlights an issue that's been there for a very long time now.

Actually, no.  DKIM does not highlight this.  What is highlighting this is 
security discusses that come from wanting to apply DKIM to more than it is 
designed for.  It is the /discussions/ that highlight this, not DKIM.  (I'm not 
playing semantics here.  I'm playing scope.)

Given that DKIM's core algorithms are the same as those used for "message 
security", it's pretty easy to imagine applying DKIM to these other, larger 
issues, but that's a separate engineering effort.

On 10/13/2010 4:09 PM, MH Michael Hammer (5304) wrote:
 > I've said for a long time (from a phishing perspective) that if we let "bad"
 > stuff (from a brand perspective) get to the enduser
...
 > Having said that, if an MUA is going to present an indication of "DKIM PASS"
 > to the enduser,
...
 > I understand the issues raised by Murray about the slippery slope. On the
 > other hand, I would rather see an MUA present nothing about DKIM than give a
 > false impression to endusers.

Fundamentally, everything in your note suffers from being both valid but 
irrelevant (to the current discussion about DKIM).  It's valid and even 
essential, to a different, larger discussion.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 23:03:17 -0400

> to what an end-user finally sees, then it serves a very limited

Well, yes.  But that's a /good/ thing, as a core capability.

More importantly, we are not in the MUA business because we lack the expertise, 
as a group.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 23:11:03 -0400

> similarly to miss the point.

Mark,

First, let's be clear that no one think MUA issues are minor or irrelevant.

The question is how DKIM relates to them and what should be said about the topic 
in the DKIM Signing specification.

Everything affects the user experience.  IP interpacket arrival times.  TCP 
algorithms responding to congestion.  SMTP transaction design.  Every f'ing thing.

But this does not mean that each of them must make comments about MUA issues.

DKIM resolved a massively important problem by defining a validated 
name-affixing mechanism.  But neither Domainkeys nor DKIM specifications 
demonstrate any of the human factors or usability specialties needed to make 
serious comments -- nevermind normative directives -- about MUA design.  Nor did 
they need to.

What you are calling for would be good to have.  It should be done.  Just not in 
the signing spec.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 01:36:31 -0400

> Do Alpine or Thunderbird or whatever else do anything special now when a 
> message is signed, whether or not the signature(s) pass or fail?

For S/MIME, maybe PGP.  But of course neither does anything with message 
headers.

> Current modules that don't do the kind of enforcement people are 
> demanding and that isn't exacerbating anything.  When they add DKIM 
> support in some way, I imagine those MUAs will ....

DKIM support in an MUA?  Yuck.

It's likely to be a long time before any MUA I use does anything with 
DKIM, since I am not a fan of filtering mail while reading it.  All my 
filtering happens at delivery time, long before the MUA sees it.  Since 
mail systems tend to have a lot more control over their delivery process 
than over the MUAs their users use, I expect I am not the only one who 
would be dismayed to have to upgrade every MUA in the world to do 
filtering that could have happened during message delivery.

That's why, as I've been trying to explain, if I can't use DKIM to do 
reliable whitelisting at delivery time, its utility is vastly decreased.

Or to flip that around, anyone who uses DKIM to whitelist is going to have 
to do the multiple header check anyway, so it would be nice to have it 
specified as part of DKIM, at least as a SHOULD if not a MUST, rather than 
reinvented and glued on ad-hoc everywhere.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 01:49:16 -0400

> What you are calling for would be good to have.  It should be done. 
> Just not in the signing spec.

Correct me if I'm wrong, but I hear you saying that if one creates or 
verifies the DKIM signature on a message, one should also do the double 
header check somewhere in the mail processing path, but rather than saying 
so in the spec, it'll just be our private bit of folklore.

R's,
John

PS: I'm fine with Jim's proposed section 6.1.1.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 00:49:21 -0700

> Sent: Wednesday, October 13, 2010 10:49 PM
> To: [email-masked]
> Cc: DKIM List
> header check somewhere in the mail processing path, but rather than
> saying so in the spec, it'll just be our private bit of folklore.

I'm completely okay with providing informative guidance to signers and verifiers, or even to receivers and MUAs, maybe even right in the bis document.  But once it becomes normative, and especially if we want to put a MUST in there, we're requiring the work of enforcing the terms of a non-DKIM RFC into DKIM.  Any way you slice it, that just sounds like bad engineering to me.

If we accept the model that DKIM is a layer that sits on top of the mail layer (and by that I mean RFC5322; SMTP is a layer below that even), then what crosses the layer boundary should only be valid, in the same way that only valid IP packets get passed up to the TCP layer, or only valid and sequenced TCP packet payloads make it up into a socket's read buffer, or only a valid SMTP command sequence can cause something to land in your inbox.  The mail layer shouldn't pass crap upwards; and in this case that means an MTA shouldn't invoke a DKIM library/function/whatever unless the data it's about to pass across that line is known to be valid for that transition.  The mail layer is where RFC5322 is implemented, so it has the code to do what you called the full body cavity search already, and so any lightweight header counting is thus by definition not only cheap, but actually redundant.

It should be perfectly fine to say DKIM expects valid input, for whatever definition of that we want to invent, and also state that handing it anything else has either undefined results or specific bad results.  I can point out dozens of UNIX man pages that say the same thing.  It's not a new idea.

In a C program, if I ask you to hand me a valid string, I'm saying something that has a specific, unambiguous, well-documented meaning.  If despite that you hand me something that may or may not be a valid string, it's unreasonable for you to expect me or other possible handlers of that data to do something valid or safe with it every time.  Indeed, the result could often be catastrophic.

That MUAs or post-DKIM filtering agents might make weak, lazy or foolish rendering decisions is certainly unfortunate, perhaps even terrible, but I'm not convinced that all (or any) of the layers below that need to do normative things that compensate for, accommodate, or fix everything that might make it up that far, protecting them from themselves, only to have them come up with yet another new way to be vulnerable later.

As I said in another message, I realize once you're actually writing an application to do all of this then the interface lines can get quite mushy.  But I don't believe the IETF should be in the business of producing standards track protocol specifications that define interface lines which are intentionally mushy.

-MSK

---

From: Graham Murray <[email-masked]>
Date: Thu, 14 Oct 2010 10:38:24 +0100

"John R. Levine" <[email-masked]> writes:
> DKIM, since I am not a fan of filtering mail while reading it. 

An MUA does not have to do filtering in order to support DKIM. It could
display the Authentication Results header, or take some action depending
on whether there is a valid DKIM signature - in a similar way that some
web browsers will turn the URL bar green when the site presents a valid
'extended validation' certificate.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 14 Oct 2010 13:06:23 +0100

> 'extended validation' certificate.

I think this is a very bad idea. Many people with quite a bit of technical knowledge struggle to grasp what DKIM really does (I am, or used to be, among them). What is really does (cryptographically attach a domain name to an email) is of little value to the end user.

Worse, there are plentiful examples where this may be misleading to the end user. Think of a phish with a valid DKIM signature (of the phisher's domain). Or an email DKIM-signed by Gmail from your friend who "is in London, had all his possessions stolen and asks if he can borrow $2000 ASAP"; the fact that Gmail signed the message doesn't make it any less likely that your friend's account hasn't been hacked into. I am not a psychologist, but I believe that to many an end user a valid signature will suggest the email should somehow be trusted.

(Taking some action, such as putting a messages in an appropriate folder, or giving it a blue background, based on a valid DKIM signature of a valid domain is a different matter.)

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 10:17:15 -0400

> It should be perfectly fine to say DKIM expects valid input, for 
> whatever definition of that we want to invent, and also state that 
> handing it anything else has either undefined results or specific bad 
> results.

We seem to be talking past each other here.

I don't see anyone proposing a deep dive into 5322 validation.  But 4871 
already says you MUST sign the From: header.  Why is that OK, but saying 
you MUST NOT sign or validate something with two From: headers is not? 
We're not suggesting anything that would invalidate existing bits on the 
wire, after all.

DKIM is full of layer violations where it tells people how to sign and 
verify robustly. Sec. 5.3 tells signers to downcode 8-bit MIME, 6.1.2 has 
some fairly dubious assumptions about the structure of the DNS, 6.1.3 even 
tells verifiers to rewrite MIME separators.

This seems an odd place to draw a line in the sand, and an unfortunate one 
if you believe that an important use of DKIM should be to whitelist mail 
from trusted signers.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Oct 2010 15:21:46 +0100

> a little more, but not worry about the more obscure checks such as LFCR

On further thought, I would make that:

          CHECK DKIM && CHECK RFC5322 headers included in h= tag --> ACCEPT
          ELSE CHECK FOR ADSP DISCARDABLE (maybe for ALL)
where the ADSP should check ALL the From headers that are found (so I  
guess we need an RFC5617-bis too, since 5617 takes no account of multiple  
 From headers.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 14 Oct 2010 10:31:27 -0400

On 10/14/2010 10:17 AM, John R. Levine wrote:
> verify robustly.

Protocol specifications should require all of that actions that are essential to 
correct operation and none of the actions that are not.

A DKIM signature verifies or it doesn't.  It delivers a signing domain or it 
doesn't.

What is essential is that it perform the task of validating and delivering a 
signing domain that is associated with a collection of bits.  Anything that 
defines how to do this is essential.  Anything that can make this break needs to 
be covered, especially if there are ways to protect against the breakage.

Perhaps surprisingly, having redundant header fields does not make DKIM break. 
And it is an issue outside of DKIM and, therefore, need not be "protected 
against" by DKIM.

Also surprisingly, the same holds for more general message conformance checking. 
  The checking does not make DKIM work, and it does not make it work better or 
worse.

So it isn't needed.

d/
-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Oct 2010 15:31:38 +0100

On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> are

But if there is no valid DKIM signature, the verifier will proceed to do  
ADSP checks, and will reject the message if it sees that ebay.com is  
'discardable'.

Note that RFC5617 is ambiguous as to which of the two From headers it will  
use to establish the Author Domain, so we are going to need a 5617-bis to  
fix that.
> remains, how is it a DKIM problem?

Since the phisher is trying to bypass that ADSP 'discardable' for ebay.com  
(and he thinks ADSP checkers might use the first address), it is in his  
interest to DKIM-sign the message himself (so that ADSP is never  
consulted). And that is why it is a DKIM problem, and why the loophole  
must be closed.

---

From: "Mark Delany" <[email-masked]>
Date: 14 Oct 2010 07:38:13 -0700

> be covered, especially if there are ways to protect against the breakage.

But isn't the problem that the signing domain is being incorrectly
associated with a different collection of bits?

Mark.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Oct 2010 15:51:22 +0100

> which should cause it to go into the SPAM folder, with a large

No, the Bad Guy has used a throwaway domain which has not yet made its way  
into any blacklist the SPAM checker might have been using.

> hash that. That way most folks would understand DKIM is just providing

I have much sympathy with this rant; I think the body could have been  
handled much better. But it ain't going to change, and Barry has now  
declared it OT.

---

From: "Mark Delany" <[email-masked]>
Date: 14 Oct 2010 07:56:31 -0700

> associated with a different collection of bits?

And just to elaborate on my own point. We went thru a lot of
hand-wringing over canonicalization and the l= tag and so forth
precisely because we were concerned about associating a signing domain
with the wrong bits.

But now it seems that making the wrong association is not treated with
as much concern.

If it is true that the DKIM effort is about associating an identifier
with a collection of bits, it equally must be true that we want to
make a similar effort to ensure that identifier is not associated with
an unrelated collection of bits.

Mark.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 10:58:35 -0400

> Perhaps surprisingly, having redundant header fields does not make DKIM 

We must have some vastly different definition of "break".

If allowing through modified messages that render very differently isn't 
broken, shouldn't we remove the advice against signing with l=0?  The 
advice in favor of signing Subject: and To: fields?  None of those has any 
technical effect on the ability of a verifier to compute and compare 
hashes.

If not, what's the difference, other than the fact that we thought of some 
of them several years ago and just noticed these last week?

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 08:11:31 -0700

On 10/14/2010 07:58 AM, John R. Levine wrote:
> advice in favor of signing Subject: and To: fields? None of those has
> any technical effect on the ability of a verifier to compute and compare
> hashes.

There is an enormous difference between the situations with DKIM and,
say, TLS+X509. With TLS, you take the output of the checks and use
THAT ALONE to decide to deliver the bits or not. DKIM has *never*
been such a protocol: there is a vast backstop of security infrastructure
where DKIM is a just helper.

Like I said, give spam/phishing filter writers some credit. They
are not idiots.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:30:42 -0700

> Sent: Thursday, October 14, 2010 7:32 AM
> To: DKIM

ADSP is a completely separate discussion.  We're talking about advancing DKIM here, not both of them.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:31:17 -0700

> Sent: Thursday, October 14, 2010 7:38 AM
> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> 

By the verifier, or by the MUA?

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 12:45:39 -0400

> Unless there's *really* something they can't figure out without protocol
> help, I'm not sure what the point of this is. This double added From thing
> is trivial to detect with the current spec.

Well, yeah.  That's why I don't understand why people are so opposed to a 
SHOULD saying they should.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 09:49:43 -0700

> Sent: Thursday, October 14, 2010 7:59 AM
> To: [email-masked]
> Cc: DKIM List
> If allowing through modified messages that render very differently
> isn't broken, shouldn't we remove the advice against signing with l=0?
> The advice in favor of signing Subject: and To: fields?  None of those
> has any technical effect on the ability of a verifier to compute and
> compare hashes.
> 
> If not, what's the difference, other than the fact that we thought of
> some of them several years ago and just noticed these last week?

The difference is that the Subject:, To: and l= advice don't dabble in the area of having to tell a DKIM implementer to enforce parts of other protocols.

Adding a second From: makes the message format illegal.  The other ones don't.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 10:01:25 -0700

> SHOULD saying they should.

Because the audience who ought to be dealing with the larger problem has little to
nothing to do with the audience that would have to deal with that MUST/SHOULD.
It's a useless requirement to put on DKIM.

If you really think this is such a great big problem, maybe you should be
banging the drums at MAAWG or other venues where the correct set of ears
is potentially listening.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 13:07:18 -0400

> Adding a second From: makes the message format illegal.  The other ones don't.

We're still talking past each other.  You're right, it makes the message 
format illegal, but so what?

Historically, there has been no reason for MUAs to enforce format 
compliance on incoming messages.  I get the impression that people expect 
that to change.  But why would it?  "To catch stuff that DKIM chose not 
to" isn't very compelling.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 13:15:15 -0400

> is potentially listening.

I would rather not have to run a session at MAAWG entitled "How to fix the 
security holes in DKIM", but I certainly could.

Am I really the only person who wants to be able to whitelist mail signed 
with known good signatures, drop it into user inboxes and expect 
reasonable results with existing MUAs?

This is basically the same model as X509, except that X509 builds the 
credibity test into the protocol via CAs, rather than externally via 
something like VBR.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 09:27:35 -0700

> an unrelated collection of bits.

Mark, with a signed bunch of bits you get two prizes for the price
of one: you know which bits are signed, and then you know which bits
aren't. There is no ambiguity in the spec about which bits are signed,
so we're quibbling about the ones that aren't. Isn't this where we
want to have people's secret sauce take over? That is, we want MTA,
MDA, and MUA's to take those two piece of information and make better
decisions about, oh say, rendering? We already know that the DKIM
spec alone is not going to force the hand of recalcitrant or uncaring
MUA's, but it is potentially quite helpful to ones that are receptive.
Unless there's *really* something they can't figure out without protocol
help, I'm not sure what the point of this is. This double added From thing
is trivial to detect with the current spec.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 10:21:45 -0700

> Sent: Thursday, October 14, 2010 10:07 AM
> To: Murray S. Kucherawy
> Cc: DKIM List
> We're still talking past each other.  You're right, it makes the
> message format illegal, but so what?

That makes it invalid input to any module that requires input to comply with RFC5322, pure and simple.

> to" isn't very compelling.

I think if it becomes well-known that users of MUA 1 are easier to phish than users of MUA 2, a lot of people will gravitate to the safer implementation, don't you?  I sure would.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 10:23:21 -0700

> reasonable results with existing MUAs?

I would hope so because this would be a really stupid thing to do.
Without the next line of defense -- virus, malware, spam, phishing --
you'd be setting your users up for big problems. Just because it's
DKIM signed from a good source doesn't mean it's not still evil.

That's why all of this hand wringing is silly.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 10:30:38 -0700

> Sent: Thursday, October 14, 2010 10:15 AM
> To: DKIM List

Not only do I want that, I did that.  But the DKIM/ADSP module of that system is purely DKIM/ADSP.  The module that sits between the MTA and the DKIM/ADSP module does the header count enforcement we're talking about, knowing there's the potential for invalid mush in there.

You don't have to do it that way in the source code to make it work properly if some other design makes sense for you, but that is the delineation that should appear in the normative parts of protocol specifications.

I'm talking purely about specification here.  I'm totally fine with one omnibus implementation that does everything from SMTP server right up to a webmail rendering if that's what you want to do.

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 13:44:40 -0400

> That makes it invalid input to any module that requires input to comply with RFC5322, pure and simple.

Well, OK, with the stipulation that no existing MUA I have ever seen is 
such a module.

> I think if it becomes well-known that users of MUA 1 are easier to phish 
than users of MUA 2, a lot of people will gravitate to the safer 
implementation, don't you?  I sure would.

Aw, come on.  How many millions of people still use Outlook Express on 
Windows XP?  Switching MUAs is painful, people rarely do it.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 10:47:43 -0700

> Sent: Thursday, October 14, 2010 10:45 AM
> To: Murray S. Kucherawy
> Cc: DKIM List

...meaning MUA developers won't bother to do something about it once the attack is plainly visible and they're used as examples, because since users won't switch anyway, there's no motivation?

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 13:49:40 -0400

> Not only do I want that, I did that.  But the DKIM/ADSP module of that 
> system is purely DKIM/ADSP.  The module that sits between the MTA and 
> the DKIM/ADSP module does the header count enforcement we're talking about, 
> knowing there's the potential for invalid mush in there.

Well, now we're back to my question to Dave, what's the advantage of 
leaving that as folklore rather than putting it in the spec other than the 
warm theological feeling of somewhat preserving layer distinctions, except 
for all the places we already didn't?

We're still not talking about changing the bits on the wire, nor of the 
handling of any valid 5322 message.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Oct 2010 20:01:17 +0200

> If the DKIM signature doesn't verify after signed headers have been altered,

Correct.  And the way that it fails to verify is h=from:from.

The only way that DKIM can consistently account for this exploit is by 
amending section 5.5 "Recommended Signature Content", and spell what 
fields MUST/SHOULD be duplicated in the h= tag.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Oct 2010 11:01:58 -0700

> Sent: Thursday, October 14, 2010 10:50 AM
> To: Murray S. Kucherawy
> Cc: DKIM List

Why does it have to be normative?  Authentication-Results has no normative "watch out for weird input" SHOULDs or MUSTs, but instead has an extensive discussion of possible issues in its Security Considerations section.  That's what secdir asked for, and I was fine with that.

(It actually does have some normative MUA advice.  Wonder how that happened.)

Nobody's saying this has to be relegated to "folklore".  We can put a gigantic treatise on this in an informative appendix making this the biggest RFC ever if it will make people feel better.  I just don't think it can be reasonably made normative.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Oct 2010 11:03:04 -0700

> ...meaning MUA developers won't bother to do something about it once the attack is plainly visible and they're used as examples, because since users won't switch anyway, there's no motivation?

Not to mention the false dilemma that this needs to be handled in the
MUA exclusively. It doesn't.

Mike

---

From: "Mark Delany" <[email-masked]>
Date: 14 Oct 2010 11:09:08 -0700

> Correct.  And the way that it fails to verify is h=from:from.

Which strikes me as an ugly hack. Given that most headers should only
occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to
h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?

Mark.

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Oct 2010 14:33:35 -0400

> fields MUST/SHOULD be duplicated in the h= tag.

-0.5.

This is a kludge.  Its good to help, possibly, existing systems that 
is capable of defining the N+1 h=from values in their setup.  The 
problem is you don't know if they can.

The real solution is to fix up section 5.4 general paragraph regarding 
signing and
verifying the last header because it ignored the exception in regards 
to 5322.From which fundamentally there can only be one.

It needs to add the exception clause to that paragraph or in a follow 
up paragraph.

Both verifiers and signers MUST make sure its DKIM input, especially 
the headers it will bind, are technically correct.

Only DKIM can do that to close legacy loopholes.

The h=from:from "kludge" should be seen as a temporary solution until 
verifiers and signers catch up with the Double From problem.  It can't 
depend on other mail bots to do this.

-- 
HLS

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 14 Oct 2010 12:19:04 -0700

> to what an end-user finally sees, then it serves a very limited

I'm looking forward to a draft on MUA considerations for DKIM.  With all these opinions on the matter being expressed so adamantly, somebody must have already started one...right?

---

From: "John R. Levine" <[email-masked]>
Date: 14 Oct 2010 18:24:30 -0400

> Why does it have to be normative?

I'd be perfectly happy with Jim's language which as I recall says 
something like signers SHOULD decline to sign messages with redundant 
headers and verifiers SHOULD decline to verify messages with unsigned 
redundant headers.

This is an attack on DKIM, not on MUAs, so it's reasonable for DKIM to at 
least take a crack at dealing with it.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 15 Oct 2010 09:53:34 +0100

> is trivial to detect with the current spec.

Well, it took us a few years to spot the problem, and that's because some 
MUA exhibits it. Surely a little guidance wouldn't go amiss?

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 15 Oct 2010 10:00:27 +0100

--On 14 October 2010 10:23:21 -0700 Michael Thomas <[email-masked]> wrote:

>>> If you really think this is such a great big problem, maybe you should
>>> be banging the drums at MAAWG or other venues where the correct set of
>>> ears is potentially listening.
>>
>> I would rather not have to run a session at MAAWG entitled "How to fix
>> the security holes in DKIM", but I certainly could.
>>

I think the emphasis in John's email was on "expect reasonable results with 
existing MUAs" If DKIM is any part of the evaluation process, then that's 
all thrown away if MUAs are showing the wrong email address as 
authenticated.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 15 Oct 2010 10:16:56 +0100

> Well, OK, with the stipulation that no existing MUA I have ever seen is

Nor MTA, either. Exim has a "verify = header_syntax" ACL option, which 
checks the syntax of headers that contain addresses, but it doesn't count 
headers, so it doesn't spot this problem. A bug report has been filed, so 
this conversation has helped there.

> Windows XP?  Switching MUAs is painful, people rarely do it.

Too true. When I started working here in 1999, Siren Mail had just ceased 
development. We've only just (in the last few months) got Siren Mail out of 
the hands of the last user hanging on. And the motivation there was that 
Siren Mail didn't do authenticated SMTP!

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 05:54:34 -0400

> all thrown away if MUAs are showing the wrong email address as 

MUAs are like children. They eat what we feed them and they can't 
exist without a backend.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 06:13:30 -0400

Murray S. Kucherawy wrote:

>> Levine wrote:

> ...meaning MUA developers won't bother to do something about 
> it once the attack is plainly visible and they're used as 
> examples, because since users won't switch anyway, there's no motivation?

The backend will address it first before the MUA needs too.

Murray, most people are not haters and don't draw a line between good 
and bad because one isn't perfect and therefore begin to "switch" 
software like cheap wine.

Since DKIM is betting its future on increase mail integrity and 
verified identities, it is a fundamental requirement that it checks 
key parts to make sure the integrity stays in tack.   Passing the buck 
(or assuming others are better suited to deal with it) is not 
practical and bad PR for DKIM.

In reality, all parts need to check for this, the MUAs, the backends 
and above all because of the extra special needs for trust - DKIM.

The backends can't presume all the different MUAs used will address 
this, so it needs to address it.

The DKIM components can't assume the backend or MUAs will address it, 
so it needs to address it itself.

-- 
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:27:32 +0100

+1

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:34:12 +0100

> SHOULD saying they should.

Or even a MUST saying they must.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:38:37 +0100

> It's a useless requirement to put on DKIM.

So which two audiences do you have in mind?

The primary audience is the people who write verifiers for boundaries.

The end users are hardly an audience at all since they are not listening  
directly to us, and they are likely using software that is 10 years old,  
and are unlikely to change.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:51:48 +0100

> DKIM signed from a good source doesn't mean it's not still evil.

Have you ever seen an evil message from Ebay?

And yet the current protocol will allow an evil mail _apparently_ from  
Ebay to appear, with no means for the recipient to detect the difference.

And as regards using current malware detection software, can you please  
explain to us how that is supposed to catch an eveil mail signed by a  
brand-new throwaway domain that has not yet had time to acquire any  
reputation, good or bad?
> That's why all of this hand wringing is silly.

We are not hand wringing. We are pointing out a protocol that, when  
applied in the current (and likely future) Real World, fails to deliver  
what it was intended to deliver.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:58:16 +0100

On Thu, 14 Oct 2010 18:30:38 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> [mailto:[email-masked]] On Behalf Of John R. Levine
> the DKIM/ADSP module does the header count enforcement we're talking  
> about, knowing there's the potential for invalid mush in there.

Which module does which bit of the counting/DKIM/ADSP is a minor  
implemention detail. Any DKIM verifier MUST be associated with a counting  
mechanism, and whether this is done within itself or by some other module  
within the overall MTA is neither here nor there.

And ADSP also needs to make it clear which From header it needs to look  
at; and until that is fixed we MUST assume that it will look at whichever  
 From header gives the worst outcome.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 15:18:00 +0100

On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely <[email-masked]>  
wrote:

>>>  If we can extract DKIM from the equation entirely and the problem  
>>> remains,
>>>  how is it a DKIM problem?
>>
>> altered,

That only works when the signature is created by the Good Guys.

When the Bad Guys create signatures (using a throwaway domain), they will  
conveniently "forget" to do h=from:from.
> fields MUST/SHOULD be duplicated in the h= tag.

No, the only way is to amend DKIM so that the verifiers MUST/SHOULD take  
the right action.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 15:29:55 +0100

> DKIM here, not both of them.

ADSP is largely the cause of our troubles. But since we are not going to  
change it (just yet), we have to make DKIM work as well as it can with the  
current ADSP.

And the Bad Guys are perfectly well aware of what ADSP does and how it is  
deployed by the Good Guys. And so if they find they can circumvent ADSP by  
signing messages with their own throwaway domains, then they will do so.

And if we are not going to fix ADSP (yet), then the only way we can stop  
that particular exploit is to fix DKIM.

Arguing that "ADSP is a completely separate discussion" will achieve  
nothing.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Oct 2010 17:22:19 +0200

> h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?

Yes, it does.  The only question is to devise normative statements 
correctly, e.g. MUST duplicate "From", SHOULD duplicate the rest.

This is _not_ a kludge.  It is how DKIM signing works (Section 5.4).

Are we worried about wasting 100~200 bytes per signature?  (I get ~4Kb 
headers nowadays, so that is about 3% of it.)  Introducing an 
abbreviation --e.g. an h2 tag-- is considerably clearer from an 
algorithm developer's POV.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 15 Oct 2010 08:40:37 -0700

> algorithm developer's POV.

Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to be semantically identical to
h=from:from:to:to:

Old verifiers still work as well as they do today, new verifiers work
better and virtually all existing signers still work (excepting those
that sign a subset of legitimately repeating headers - which must be
rare).

In either cases, the implementation changes are about the same, but
the spec is simpler.

Mark.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Oct 2010 11:53:51 -0400

> the meaning of h=from:to: to be semantically identical to

This would mean that it is /never/ ok to add a listed header field after 
signing.  Adding would /always/ break the signature.

That's a very powerful semantic change.

I've no idea that it's completely safe.  It seems like it ought to be, but I 
worry about corner cases.

d/

ps.  I would expect such a semantic change to require re-cycling the spec at 
Proposed.
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Oct 2010 09:45:22 -0700

On 10/15/2010 06:51 AM, Charles Lindsey wrote:
> On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas<[email-masked]>  wrote:
>

s/Ebay/Yahoo!, etc, yes.

> Ebay to appear, with no means for the recipient to detect the difference.

They're not apparently from them. They *are* from them.

DKIM is not any indication of whether the content is evil or not,
per se. It just says who to complain to if it is evil.

> brand-new throwaway domain that has not yet had time to acquire any

Irrelevant for the current discussion.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 09:46:56 -0700

> Sent: Friday, October 15, 2010 6:58 AM
> To: DKIM

This continues to conflate specification with implementation.  You're talking about the latter, I'm talking about the former.

>  From header gives the worst outcome.

The current effort has everything to do with moving DKIM to draft standard, and nothing at all to do with handling ADSP issues.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 09:50:33 -0700

> Sent: Friday, October 15, 2010 7:30 AM
> To: DKIM

If that's consensus, then we're on the slippery slope of "fixing" DKIM to deal with flaws at all layers above it.  And we'll never be done.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 10:04:22 -0700

> Sent: Friday, October 15, 2010 6:52 AM
> To: DKIM

This to me says you still believe DKIM's ultimate payload is something other than a validated identifier, in this case a domain name.  We're thus not on the same page.

If instead we do agree that that's its sole intended purpose (and consensus on the errata RFC was achieved, thus confirming this), then you also have to agree that DKIM already does that.  The MUAs simply fail to make use of it, and that's the real problem.

DKIM does not purport to guarantee delivery of something that an MUA is incapable of misrepresenting.  The proposed changes don't improve this.

And since we're all insisting MUA developer and user inertia is here to stay, then even all the fixes we're talking about aren't going to make the enforcement of header field counts visible to end users; the sum and substance of the impact will be that the Authentication-Results header field (or other annotation) will change from "fail" to "pass", but this is rarely rendered to end users, and so the problem remains.

RFC5451 says an Authentication-Results field shouldn't include in its authentication summary any data that wasn't authenticated.  Blocking presentation of unauthenticated data, or highlighting it as dubious, or outright obstruction of its delivery, are the right ways to deal with this.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Oct 2010 10:04:26 -0700

+1.

Any bug fixes for ADSP need to be done at the ADSP level.

If there's a bug that needs fixing at the DKIM level then if
should be something that clearly needs fixing based on
DKIM usage. (And I think that the very narrow case of
messages that violate 5322 through multiple headers
*may* be such, but any justification of that relying on ADSP
isn't helpful).

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 10:12:44 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, October 15, 2010 10:04 AM
> To: DKIM
> And since we're all insisting MUA developer and user inertia is here to
> stay, then even all the fixes we're talking about aren't going to make
> the enforcement of header field counts visible to end users; the sum
> and substance of the impact will be that the Authentication-Results
> header field (or other annotation) will change from "fail" to "pass",
> but this is rarely rendered to end users, and so the problem remains.

That should be "pass" to "fail", of course.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 13:25:10 -0400

Steve,

I believe its about protocol consistency.  While the main focus is 
DKIM progress, its issues and resolutions are related to ADSP as well 
as its a WG product as well.

For example, ADSP implementations now know that they need to make 
there is only one 5322.From as well. Like most software, when it has a

      header = GetMailHeader("From:")

it is not expected to return a list of headers, but a single entry and 
that generally done by finding the first one.

In short, we have "marked this on the WG to-do" list for ADSP 
"updates" if any, and implementations now know what they need to add 
to their ADSP support.

Its all about synergism.  We can't just completely ignore it and then 
miss something that needs to be done later.

-- 
HLS

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 11:59:27 -0400

Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm...

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 15 Oct 2010 16:51:45 -0400

> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, October 15, 2010 11:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Well a broken signature is morally equivalent to unsigned so Im not
sure
> of the potential harm...

And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust has been that it was
likely broken in transit. We failed to have the discussion of it being
intentionally broken in transit as an attempt to game the system. For
header mutations after signing (which are likely to be a malicious
attempt in the specific cases we have been discussing) I feel that
treating it as simply the same as unsigned is ignoring the potential
maliciousness.

I recognize what Murray and Dave have said on this point but it grates.
The reason we are going through the exercise of creating a stable
identifier associated with a signing domain is because we perceive some
value whether it be policy associated with the stable identifier or
reputation associated with the stable identifier. 

To simply ignore this and say it is the same as if it wasn't signed is
kind of like saying 0=1.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 13:58:35 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of MH Michael Hammer (5304)
> Sent: Friday, October 15, 2010 1:52 PM
> To: Bill Oxley @ Cox; [email-masked]

I think the problem is it's hard to tell using an algorithm.  A human can perhaps look at a modification and qualify it as an operational side-effect or something deliberate intending to deceive, but it's pretty hard to codify that kind of logic, especially without some foreknowledge about what downstream agents are going to do with the message (which would make such an algorithm heinously big).

> I recognize what Murray and Dave have said on this point but it grates.

I think it's an unfortunate reality as well; absent a way to tell the difference, it seems the best option is to act like there isn't any difference.

Interestingly, I think the same logic applies to domain reputation: It's easy to shed a bad reputation by changing domains, so in the end I expect a bad reputation will be the same as no reputation.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Oct 2010 14:00:04 -0700

On Oct 15, 2010, at 1:51 PM, MH Michael Hammer (5304) wrote:

> intentionally broken in transit as an attempt to game the system.

How can the system be gamed by breaking a signature in a way
that it can't be by removing the signature? A concrete example
might make it clearer what the concern is.

> For

Nobody is saying it should be ignored, I don't think. Rather the
bit of code that should be objecting to it is not the DKIM verifier.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Oct 2010 14:30:26 -0700

On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote:
> >
> > On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To:
> > [email-masked] Cc: [email-masked] Subject: Re:
> > [ietf-dkim] detecting header mutations after signing
> >
>  And this is where I angst. In all the discussions of a broken
>  signature being morally equivalent to unsigned, the thrust has been
>  that it was likely broken in transit. We failed to have the
>  discussion of it being intentionally broken in transit as an attempt
>  to game the system. For header mutations after signing (which are
>  likely to be a malicious attempt in the specific cases we have been
>  discussing) I feel that treating it as simply the same as unsigned is
>  ignoring the potential maliciousness.
>
>  I recognize what Murray and Dave have said on this point but it
>  grates. The reason we are going through the exercise of creating a
>  stable identifier associated with a signing domain is because we
>  perceive some value whether it be policy associated with the stable
>  identifier or reputation associated with the stable identifier.
>
>  To simply ignore this and say it is the same as if it wasn't signed
>  is kind of like saying 0=1.

Agreed.  Having the specification suggest multiple From header fields 
should not report a valid signature is not enough.  It will be years 
before software will reliably deal with the resulting exploits.  The 
best method to handle DKIM related exploits at the MTA would be to 
recommend message refusal.  It is hard to understand the reluctance in 
having a SHOULD refuse.

Citing a layer violation makes little sense.  With DKIM, the message 
body does not stand on its own.  DKIM binds elements related to the 
RFC5322 header fields with the message body, for the purpose of 
extending favorable message handling, such as white-listing.   Since 
DKIM has this property, citing layer violations lacks any basis.

The h=from:from is also not an effective solution, as this only deals 
with one mode of exploitation!  There are two.

John and Mark are right.  It is wrong to consider the DKIM signature 
some type of academic exercise devoid of how DKIM might be exploited.  
The WG should step up and deal with this assumed compliance 
vulnerability.  Without DKIM, this vulnerability would not exist.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 15 Oct 2010 23:33:53 +0200

>> intentionally broken in transit as an attempt to game the system.

The problem is: when is a broken signature an intentionally broken 
signature and how do we detect that at the verifier side?

>> treating it as simply the same as unsigned is ignoring the potential

-1. At the end of the day, giving a negative score to an invalidated 
signature will/may affect the reputation of the owner of the domainname 
or better said: it will influence the way the assessor will interpret 
the authentication results provided by the verifier. Apart from the 
problem of how to determine the 'nature of the invalidation'.

+1

Like DNSBLs and IPv6: at some point it will be more effective to 
whitelist known 'good' IP addresses than to blacklist the ever changing 
IP addresses of the bad guys.

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Oct 2010 14:40:18 -0700

> In either cases, the implementation changes are about the same, but
Agreed.  But use of the h=from:from prevents one mode of exploitation, 
because this requirement until now had not been made explicit.

-Doug

---

From: Wietse Venema <[email-masked]>
Date: Fri, 15 Oct 2010 17:10:28 -0400 (EDT)

> treating it as simply the same as unsigned is ignoring the potential

I'm sure this was discussed before, but perhaps a refresher helps.
How would the DKIM validator know the difference between:

A: The message had a valid signature, but it was broken after
signing.

B: The message is a forgery with a bogus signature.

If the DKIM validator cannot make that distinction, then the bad
guys will do B and the validator will treat it as A.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Oct 2010 15:39:25 -0700

On 10/15/10 2:10 PM, Wietse Venema wrote:
> >> On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote:
> >>
> > discussion of it being intentionally broken in transit as an
> > attempt to game the system. For header mutations after signing
> > (which are likely to be a malicious attempt in the specific cases
> > we have been discussing) I feel that treating it as simply the same
> > as unsigned is ignoring the potential maliciousness.
>
>  If the DKIM validator cannot make that distinction, then the bad guys
>  will do B and the validator will treat it as A.

Email is not handled in one step.  Upstream processes may improperly 
handle messages on the basis of DKIM where a signature might be 
improperly considered valid with an unsigned pre-pended From header 
field.  This would be due to the verification process not being 
explicit.  Had the process been explicit, it is likely the message would 
have been refused.  It is not safe to assume prior processing would have 
considered such a message to have had an invalid signature.  The best 
method to handle this situation would be to refuse the message.  An 
invalid signature without multiple From header fields is considerably 
different and has many innocuous causes.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 19:12:33 -0400

> To simply ignore this and say it is the same as if it wasn't signed is

I view this from a Fault Analysis standpoint and the first thing to 
establish are your boundary conditions and it is difficult to have 
boundary conditions without a policy framework (or process expectations).

Part of the modeling do include invalid signatures and we have shown 
that you can fold many of these invalid signature conditions into a 
single "never signed" condition.

This why I continue to have a problem with the 4871 "policy" of 
transforming an invalid state point to never signed state point.  It 
was fine when POLICY was still part of the framework. When we insisted 
on separating the two, that 4871 inherent policy should of been removed.

This is not the first time, but I would love to re-issue the 
suggestion to remove that statement from 4871 iff we want to continue 
to separate policy into another layer.  In that case, the higher layer 
needs all trace information available.

The difference is that there is higher weight with deterministic 
boundary conditions when there is no real signature vs the 
indeterminate conditions with failed signatures.  But depending on the 
domain expectation, these failed conditions can be folder to the no 
signature condition.

I always come back to an image of an old patented idea of using a 
perfect circle to represent the optimal boundary conditions for a 
process.  When that circle is skewed, you are off the optimal plane. 
It may not represent an emergency, but there is a "shape" or limits 
that tells you something is not right and alerts need to be signaled.

For DKIM, we can only do this with Domain Expectations to help 
verifiers and local policy be molded.

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 19:19:03 -0400

Okay, we could put policy back in and state a malformed signature cannot pass and assign a weight higher than an unsigned message. Then the problem remains the same, is it error or malice. A dkim verifier is the wrong tool to do that particular job

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 16:50:36 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Friday, October 15, 2010 2:30 PM

I thought the "What DKIM does" thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more.  That makes this assertion inapposite.

I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to "protect" the body.  So I propose this be added to 4871bis:

> > 1.4 Data Integrity
> >
> > A DKIM signature associates the d= name with the computed hash of 
> > some or all of the message (see Section 3.7) in order to prevent the 
> > re-use of the signature with different messages.  Verifying the 
> > signature asserts that the hashed content has not changed since it 
> > was signed, and asserts nothing else about "protecting" the end-to-end
> > integrity of the message.

I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle.  And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified.

> vulnerability.  Without DKIM, this vulnerability would not exist.

Can someone name a current MUA that treats a DKIM-signed, malformed message differently from an unsigned one in terms of what it renders?  If not, that last assertion is also false.

And if the response to that is "MUAs can change to show what was validated and what wasn't", then they can also change to handle the malformations we're talking about.  And, in fact, that's probably easier to implement.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 19:55:55 -0400

Bill,

First, lets kill this seed, I wasn't suggesting to put policy back into
the DKIM spec.

What I speak of is that before you can do any DKIM Fault Analysis you must
first establish the DKIM boundary conditions for 100% failure and 100% 
success.

That has to do done first and if we can't do that, then it will be 
very difficult to get a payoff for DKIM.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 Oct 2010 20:08:34 -0400

On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote:
> > [mailto:[email-masked]] On Behalf Of Douglas Otis Sent:
> > Friday, October 15, 2010 2:30 PM
> I thought the "What DKIM does" thing was a long-dead horse, as we'd long
> ago reached consensus that what DKIM does is provide a stable identifier
> on the message, and nothing more.  That makes this assertion inapposite.

Does it?  If the identifier is bound to the hashed information, I think it 
makes complete sense to believe one can make something of that content and 
it's relation to the identifier.  It provides a stable identifier, but that 
identifier is inextricably tied to the signed content.

> I think perhaps now would be a good time to make that explicit, since a lot 
of people (including some in here) are continuing to infer that DKIM should be 
used to "protect" the body.  So I propose this be added to 4871bis:
> I apologize in advance if that causes yet another traffic maelstrom, but
> it's something we need to settle.  And since the discontinuous expectation
> of DKIM exists outside the working group as well as inside it, that means
> consensus needs to be codified.

Your proposed wording sounds a lot to me like what I think of as "protecting" 
the end-to-end content.  I feel there's a lot of talking past each other here.

If we were doing what you think of as "protecting", what would be different?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 17:14:26 -0700

> Sent: Friday, October 15, 2010 5:09 PM
> Subject: Re: [ietf-dkim] Data integrity claims
> 

There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name.  Reputation, for example, would be checked against that, and not against the body hash or some other part of the message.

The claim that it "binds elements related to the RFC5322 header fields with the message body" is the means of the algorithm, not the end.

---

From: "Mark Delany" <[email-masked]>
Date: 15 Oct 2010 17:32:53 -0700

> I thought the "What DKIM does" thing was a long-dead horse, as we'd
> long ago reached consensus that what DKIM does is provide a stable
> identifier on the message, and nothing more.  That makes this
> assertion inapposite.

> I think perhaps now would be a good time to make that explicit,
> since a lot of people (including some in here) are continuing to
> infer that DKIM should be used to "protect" the body.  So I propose
> this be added to 4871bis:

(I don't know what "inapposite" is, but I like it!)

To your point, the identifier and the message must go together to be
meaningful. One without the other is meaningless. Therefore one could
argue that DKIM is "protecting" that relationship between the message
and identifier.

Or put another way, if a DKIM signer is taking responsibility for the
message, then DKIM should also protect the original assertion of the
signer - which again includes the message as well as the identifier.

I don't think you can disconnect the two and retain value. Maybe
that's what folk mean when they say "protect the body"?

Mark.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Oct 2010 21:03:20 -0400

> There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is…

That does not exclude any other functionalities.

> The claim that it "binds elements related to the RFC5322 header fields with the message body" is the means of the algorithm, not the end.

But the associations are still binding.  They are direct associations, 
especially 5322.FROM hence why author policy is still of interest for 
the framework (and a WG work product).

I think these discussions get a little lost of how "applications" 
should be applied.   The out of scope Reputation Application is just 
one of them, but it is not the only one.  We got policy to work out at 
some point and thats a WG item.

I posted this a while back but you will have input of various kinds 
for the various "evaluators":

     DKIM_RESULT    =  DKIM_VERIFY(MSG)
     REP_RESULT     =  DKIM_REPUTATION(DKIM_RESULT, DKIM.D)
     POLICY_RESULT  =  DKIM_POLICY(DKIM_RESULT, MSG.FROM, DKIM.D)

But these are not the only ones.  You will see Expert System like 
designs take place or systems with flexible rule based scripting 
available to allow for local policy to be molded.

For example, an expert rule can be:

    if a signature fails and has TESTING flag enabled,
       then see if he stilling testing after __12__ months
       then if so, negative classify this signer domain.

I indicated a long time ago that we be careful with t=y flag and add 
guidelines track the usage.  It was added.

Note, I think the focus with signer domain is fine for "trust" but it 
must be recognize that there are other associations and efforts to 
minimize it, I don't think will be well accepted to the layman market 
place.  Most will see what they see and DKIM signatures are passive 
"extra" information.

All I like to distinguish is that attempting to only extract the valid 
signer domain as good useful information must be mirrored with its faults.

-- 
HLS

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Oct 2010 00:10:48 -0400

On 10/15/2010 8:32 PM, Mark Delany wrote:
> Therefore one could

Clever phrasing.  Might be too subtle for general use, but I think it offers a 
perspective that could be useful.

I think the issue here is that when people talk about protecting a message, they 
tend to have in mind all sorts of attacks designed to trick users.  DKIM 
actually does not have much to say about such things.

Yes, it ties an identifier to a bag of bits, and yes it specifies what those 
bits are, but it really does deal only with those bits and not (necessarily) the 
entire message.  And its protection of those bits is quite limited, relative to 
various important assertions that might be made about those bits (and/or the 
entire message) but which DKIM does not know or care about.

d/
-- 

   Dave Crocker

---

From: "Mark Delany" <[email-masked]>
Date: 15 Oct 2010 23:39:26 -0700

On Sat, Oct 16, 2010 at 12:10:48AM -0400, Dave CROCKER allegedly wrote:
> entire message.

I have a problem with this approach and I don't pretend to know the
right answer.

My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I "see" are the
ones that paypal sent. No more, no less.

To murder another idiom: "What you see is what they sent" is I believe
the ultimate goal of DKIM. Or, "what you complain about is what they
sent". Whatever.

So anything that circumvents "what you see is what they sent" I think
is in scope for DKIM to eliminate or mitigate.

Is that requirement solved in the verification protocol of DKIM or is
that solved in advice to MTAs/MUAs?  I don't know. But I am sure that
if we don't end up with that guarantee, then I do wonder what we are
offering.

Mark.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Oct 2010 10:16:35 -0400

> the ultimate goal of DKIM. Or, "what you complain about is what they

My point is that DKIM is used within an environment that has a wide range of 
attacks, such as including social.  While it's of course fair to say that DKIM 
"protects" the bits it covers, there are two lines of potential misunderstanding.

The first is, of course, the bits not covered.

The second is that DKIM provides certain kinds of protection, for the bits it 
protects, and not others.

So when we say that DKIM protects some bits, we need to be clear what it is 
/not/ doing for those bits and what, associated /other/ bits are still subject 
to attack.

My own observation is that nearly all discussions about DKIM do not reflect care 
-- and often don't reflect understanding -- about these constraints.  This leads 
to overly ambitious expectations for what DKIM can do.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2010 10:26:51 -0400

> Yes, it ties an identifier to a bag of bits, and yes it specifies what 
> those bits are, but it really does deal only with those bits and not 
> (necessarily) the entire message.

Technically. you are correct.  Semantically, that's silly.

We went through backflips trying to figure out how to design the 
signatures so that the message modifications they allowed would preserve 
the same message, for an ill defined but I think well understood version 
of the same.  While it's always been possible to sign messages in ways 
that allow gross changes, e.g. don't sign the subject or MIME headers, set 
l=0, if you sign a message using a normal set of options, the idea was 
always that the message the recipient saw would be the one you signed. 
Throwing up our hands at the double header trick is, one might say, 
ahistoric.  Claiming it's an MUA problem is simply wrong.

For the umpteenth time, we don't need to change the bits on the wire for a 
valid signed RFC 5322 message.  But we really need to give some advice 
about how to defend against it.  Jim's proposed language with SHOULD seems 
right to me.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Oct 2010 10:50:25 -0400

On 10/16/2010 10:26 AM, John R. Levine wrote:
> of the same.

Yes that was the goal.  No that was not the result.

Which header fields are essential to protect?  How much of the message body is 
essential to protect?

The current DKIM spec does not answer these questions and easily permits 
protecting very little of the message.  Almost certainly too little to ensure 
the protection you assert.

That's an example of what I mean when I says that there are assumptions about 
DKIM that go beyond what it (always) delivers.

I guess I should thank you for demonstrating my point.

> While it's always been possible to sign messages in ways

1. Your first sentence concedes my basic point

2. There is no commonly-agreed upon and documented concept of "normal set of 
options" that I'm aware of.  What is normal for you might or might not be normal 
for the next person configuring DKIM.

d/
-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 16 Oct 2010 17:53:54 +0200

> DKIM that go beyond what it (always) delivers.

I see your point. But there is a big difference between

a) the assumption that DKIM always protect an entire message (which it 
obviously does NOT) and
b) the assertion that DKIM delivers some basic functionality + can be 
used in different modi operandi

These modi operandi, which probably need to be worked out in the 
deployment documents (not in 4871bis) enable organizations to use DKIM 
(among others) to protect specific parts of a message, which can be very 
interesting for some organizations, as it won't require a complex PKI to 
deploy. Another (important) use case will be using DKIM as an enabler 
for reputation services. And there will probably be more use cases for DKIM.

> for the next person configuring DKIM.

Right, this is in line with what I wrote above, about different kinds of 
DKIM use. So let's not confuse things: DKIM itself does not provide a 
useful minimum protection but can be used by applying the right 
parameters and configuration to protect specific parts of a message 
(after all, S/MIME and PGP also provide only protection of part of a 
message).

/rolf

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sat, 16 Oct 2010 12:56:14 -0400

> Sent: Saturday, October 16, 2010 2:39 AM
> > Clever phrasing.  Might be too subtle for general use, but I think
it
> offers a
> those

Mark is more clearly articulating what I have been struggling with. 

This is also one of the reasons I have always felt that 1st party
signatures are inherently a different value proposition from 3rd party
signatures.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sat, 16 Oct 2010 13:07:15 -0400

> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Saturday, October 16, 2010 10:50 AM
> To: John R. Levine
> Cc: DKIM List
> Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims
> 
> 
> 
> That's an example of what I mean when I says that there are
assumptions
> about
> > that allow gross changes, e.g. don't sign the subject or MIME
headers,
> set
> 2. There is no commonly-agreed upon and documented concept of "normal
set
> of
> options" that I'm aware of.  What is normal for you might or might not
be
> normal

Dave,

This is disingenuous on your part. It is akin to saying that although
the common usage of hammers is to hit nails, we must accept within the
definition of normal the usage of beating people on the head with a
hammer.... simply because some people do and it is not documented
through warnings on hammers that this is not normal.

There is a subset of headers that the vast majority of informed (even
semi-informed) implementers would agree on. Perhaps we need to reach a
consensus and document this to protect the children.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sat, 16 Oct 2010 13:43:29 -0400

> Sent: Friday, October 15, 2010 5:10 PM
signature
For
> guys will do B and the validator will treat it as A.

Multiple headers are a specific class of problem. The signature is not,
in fact, broken. It validates. The described attack actually leverages
this.

We are left in the realm of "the operation was a success but the patient
died". If this where we want to be?

How often do we see multiple From headers where the From was added (as
opposed to the original From was modified) after the message was signed?
How often do we see this without malicious intent in the wild? Same
question for other headers?

What is the value proposition that DKIM offers that incentivizes people
to adopt it?

I remember similar discussions back in the 2004 timeframe when we didn't
have practical experience with DKIM. This theme was in fact touched on
at the "Marketing DKIM" dinner that Dave organized after the FTC
workshop in DC.

I am not suggesting that we boil the ocean. I am suggesting that we can
realistically address this class of problem without having to "fix" the
world. Failure to address it significantly alters the value proposition
of DKIM..... in a negative manner.

I've never been happy with the choice to have "fails to validate" == "no
signature". This is what invites your question about "A" or "B". Your
question "A" begs the question of how the signature was broken. If we
never see a certain type of brokenness in the wild in normal usage but
only (potentially) see it in abusive usage, why would we not recognize
and address this?

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Oct 2010 14:16:23 -0400

> consensus and document this to protect the children.

Wow. From sophistry to disingenuous.  Today seems to be when people think that 
tossing in slams at motives, legitimacy and style somehow facilitates 
discussion.  It invites all sorts of responses in kind, none of which would be 
constructive.  And I've tossed in this comment merely to note how irritating 
today's vocabulary choices are and suggest folks make more judicious choices. 
My postings have constructive intent and serious thought behind them.  The might 
be wrong, but they are not naive, frivolous, poorly intentioned, or any of the 
other things that permit superficial dismissal.  Please debate them on 
substance; if you've missed the substance, please show the courtesy of simply 
asking for clarification.

In any event, it's clear that at least two of you have entirely missed my point. 
  So let's try this again, more carefully:

There is a fundamental difference between saying "something bad might happen" 
versus "do this specific thing to provide this specific protection".  One is a 
generic warning.  The other is a spec.  The difference is not subtle.

Re-read my questions.  They werequite precise.  The text in the spec does not 
provide precise answers; when it appears to provide precise answers, they were 
not the result of informed thought:

      "Which header fields are essential to protect?
       How much of the message body is essential to protect?"

Let me emphasize:  Most of the advice in the spec is not useful, except as basic 
reminders to an already-knowledgeable reader.  "Useful" means that someone who 
does not already knows the answer is able to figure out the answer from the 
guidance that is given or the guidance tells them how to go about finding out 
the answer.  They can't do that with what is in the spec.

I don't mean we should rip out all the advice, merely that we need to 
distinguish between soft advice and serious, technical specification.

d/

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 Oct 2010 14:56:20 -0400

> Yes that was the goal.  No that was not the result.

-1.  I think we did that just fine.

> Which header fields are essential to protect?  How much of the message body
> is essential to protect?

This is completely orthogonal to the question.  As long as a receiver can 
reliably determine what is protected and what is not, then the protection goal 
is achieved.  It does not require that there is agreement on what that should 
be.

> protecting very little of the message.  Almost certainly too little to
> ensure the protection you assert.

One can also point a gun at ones own head.  That doesn't make a gun a suicide 
device of no value for anything else.  The spec does permit people to do silly 
things, but so what.

> That's an example of what I mean when I says that there are assumptions
> about DKIM that go beyond what it (always) delivers.

Saying it's possible to use DKIM in ways that doesn't support this is not the 
same as saying DKIM doesn't support it.

It's possible to operate any modern MTA as an open relay, but it doesn't 
follow that all MTAs are open relays or that they fail to protect against open 
relaying.

> I guess I should thank you for demonstrating my point.

If you had one that relevant to the discussion, it's not at all clear to me 
what it was or how it was demonstrated.

> > that allow gross changes, e.g. don't sign the subject or MIME headers,
> > set l=0, if you sign a message using a normal set of options, the idea
> > was always that the message the recipient saw would be the one you
> > signed. Throwing up our hands at the double header trick is, one might
> > say, ahistoric.  Claiming it's an MUA problem is simply wrong.
> 
> 2. There is no commonly-agreed upon and documented concept of "normal set
> of options" that I'm aware of.  What is normal for you might or might not
> be normal for the next person configuring DKIM.

True, but irrelevant.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Sat, 16 Oct 2010 12:03:21 -0700

Far be it for me to defend Dave, but I think you two are in
violent agreement. I think you misread some of Dave's comment
because they were posed as rhetorical.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2010 15:24:30 -0400

>      How much of the message body is essential to protect?"

Your questions are noted.  Other than the MUST to sign the From: header, 
the DKIM spec offers the technical latitide to create a totally worthless 
signature.  I don't know anyone who disagrees with that.

Since I think we're only proposing some more SHOULD advice on how to 
create robust signatures, I don't really see how they're relevant to the 
question of double signing.

> distinguish between soft advice and serious, technical specification.

Sorry, we also need specificity.  Since we are in the process of preparing 
4871bis, precisely which soft advice in 4871 should we remove?

Section 1, on page 4, includes an attempt to distinguish DKIM from S/MIME. 
That doesn't affect signing or verification, so should we remove it?

Section 1.1 has an INFORMATIVE RATIONALE saying what the signing identity 
doesn't mean. That doesn't affect signing or verification, so should 
we remove it?

Section 1.2 is non-operational history about intended scaling.  That 
doesn't affect signing or verification, so should we remove it?

In section 2.6, in item 2 on page 8, the last two sentences describe a 
putative motivation for the first sentence.  That doesn't affect signing 
or verification, so should we remove it?

I'll let you go through the rest of the spec.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 16 Oct 2010 16:26:21 -0700

On 10/16/10 7:16 AM, Dave CROCKER wrote:
> > bunch of bits that I or my MUA or my MTA ties to paypal.com then
> > the end goal of DKIM is, IMO, that those bunch of bits I "see" are
> > the ones that paypal sent. No more, no less.
> >
> > To murder another idiom: "What you see is what they sent" is I
> > believe the ultimate goal of DKIM. Or, "what you complain about is
> > what they sent". Whatever.

Agreed.  When used properly, DKIM should be able to offer this 
assurance.   DKIM makes an assessment that neither an MUA or MTA can make.

>  My point is that DKIM is used within an environment that has a wide
>  range of attacks, such as including social. While it's of course
>  fair to say that DKIM "protects" the bits it covers, there are two
>  lines of potential misunderstanding.
>
>  The second is that DKIM provides certain kinds of protection, for
>  the bits it protects, and not others.
>
>  So when we say that DKIM protects some bits, we need to be clear
>  what it is /not/ doing for those bits and what, associated /other/
>  bits are still subject to attack.
>
>  My own observation is that nearly all discussions about DKIM do not
>  reflect care -- and often don't reflect understanding -- about these
>  constraints. This leads to overly ambitious expectations for what
>  DKIM can do.

Only DKIM can defend against DKIM exploitations involving elements 
handled by this protocol.   Inadequately defined DKIM specifications, 
that when implemented, now fail to prevent signatures from mistakenly 
being considered valid and then exploited.  This represents a failure to 
adequately defined the DKIM process.

Informative advice given in Section 6.2 of RFC 4871 was largely limited 
to ensuring results headers are not spoofed, while DKIM also failed to 
consider the impact of duplicate header fields that might be relied upon 
for acceptance, or might be inappropriately selected for display.  This 
issue is not resolved by suggesting a domain being exploited in a 
spoofed From header field should include double From values in the h 
parameter :^(

DKIM's advice lacked useful specifics in light of discovered exploits of 
DKIM's poorly defined process.  A process where invalid signatures might 
be considered valid whenever RFC5322 compliance is presumed.  Only DKIM 
is able to correct these errors! Neither the MTA nor the MUA can ensure 
RFC5322 compliance, nor should they.  The MTA's role is a best effort 
delivery of accepted messages.  The MUA role is to display content 
relevant to users.

When DKIM assurance by a domain affects message acceptance by the MTA 
and/or changes how the message is displayed, then the process creating 
this assurance MUST also guard against spoofed headers in the same 
manner as MUAs have been advised with respect to result header fields.

It would be wrong to expect MTAs or MUAs to always validate RFC5322 
compliance.  If there is some other mandatory process offering this 
protection it should have been included within the DKIM specifications.  
Please don't suggest RFC5322 compliance assessment is the role of an 
undefined message filtering process.  DKIM should not use that excuse.

From: [email-masked]
From: [email-masked]
dkim-signature: d=big-isp.com; h=from; ...
dkim results: big-isp.com=pass  (DKIM should ensure this results in a 
PERMFAIL)

While many may consider DKIM a method to ensure deliverance of bulk 
email, without an adequately defined DKIM process, senders also run a 
risk of their users not trusting a process offering bad assurances.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 17 Oct 2010 18:04:40 -0700

On 10/15/10 4:50 PM, Murray S. Kucherawy wrote:
>> On Friday, October 15, 2010 2:30 PM, Douglas Otis wrote:
>>
DKIM mandates inclusion of the From header field and recommends 
validating DKIM signatures related to this field first.  Why?

DKIM failed to include fundamental aspects of RFC5322 compliance, that 
when not followed, permits the exploitation of message handling on the 
basis of mistaken DKIM PASS results when there are multiple From header 
fields, for example.  The verification process MUST explicitly 
disqualify such messages from ever receiving a PASS verification.

RFC5322 compliance is neither an assured function of SMTP nor MUAs.  As 
such, DKIM has a serious process flaw when verification fails to ensure 
normally singular headers have not been pre-pended.  Their display or 
assumed relationship with a DKIM PASS may enable methods to exploit 
either what is displayed or associated with DKIM results.  Clearly, 
Section 6.2 was short sighted in the advice given.
> I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle.  And since the discontinuous expectation of DKIM exists outside the working group as well…
Not being explicit with respect to important aspects of RFC5322 
compliance in the DKIM verification process represents an error that can 
be remedied ONLY by changing the DKIM verification process.  A few minor 
changes to this process would ensure these types of exploits are 
thwarted.  If or when some other exploit is discovered, the process may 
need further adjustment.

There is an expectation in the integrity of the DKIM process.  Few 
security related protocols don't require adjustments to mitigate various 
types of newly discovered exploitations.  Isn't this why specifications 
aren't advanced until there is greater confidence in the integrity of 
the process?

Systems discovered having defective capacitors should be recalled and 
have the defective devices replaced.  Toys for children removing fingers 
should be recalled and modified.  Otherwise, manufacturers risk a class 
action suit.   There is no reason not to repair DKIM when its 
verification process fails to offer the expected protections being 
sought.  Please, don't blame the short-comings on the MUA.
> And if the response to that is "MUAs can change to show what was validated and what wasn't", then they can also change to handle the malformations we're talking about.  And, in fact, that's probabl…
There are millions of MUAs that are unlikely to be updated anytime 
soon.  Even so, the error clearly rests with the DKIM verification 
process.   Why not fix the problem without requiring all MUAs to change, 
where non-compliance with RFC5322 only becomes a problem in conjunction 
with message handling and displays based upon DKIM results.  Had the 
DKIM verification results not been in error, there would not be a problem.

Don't think of DKIM as being inviolate offering only a disjointed 
sacrosanct identifier.  DKIM process must also guard against the 
exploitation of its results, with goes back the first question asked.

-Doug

---

From: "Mark Delany" <[email-masked]>
Date: 17 Oct 2010 18:22:54 -0700

> exploitation of its results

+1

By DKIM process, I would include anything cognizant of DKIM upto but
not including the MUA. Mike's secret sauce would count here, eg.

I for one would have dumb sauce. Perhap prefixing unsigned headers
with "DKIM-hidden-" such that only DKIM aware MUAs will render
original unsigned content.

As others have said, there is nothing between DKIM and the MUA that
prevent DKIM exploitation so who is going to solve that problem if not
us?

Mark.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Oct 2010 11:42:46 +0200

On 16/Oct/10 21:24, John R. Levine wrote:
> Your questions are noted. Other than the MUST to sign the From: 
> header, the DKIM spec offers the technical latitide to create a 
> totally worthless signature. I don't know anyone who disagrees with that.

The spec preludes to a policy in various parts.  Another one is in
section 6.3 (page 51) where it says

 If the SDID is not the same as the address in the From: header
 field, the mail system SHOULD take pains to ensure that the actual
 SDID is clear to the reader.

IMHO, this sentence can be safely dropped.

A couple of paragraphs below that, one reads

 The verifier MAY treat unsigned header fields with extreme
 skepticism, including marking them as untrusted or even deleting them
 before display to the end user.

This does not specify whether such fields break RFC 5322 compliance.
Mark's suggestion to suitably prefix them can be added here, as an
explicit indication of /how/ to mark them.  IMHO, rising that MAY to
a SHOULD or MUST would not be very effective in practice, though.

> In section 2.6, in item 2 on page 8 [...]
I couldn't locate this.  For a trivial note, tools.ietf.org doesn't
seem to respond properly.  It does:

 # curl -vO http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis
 * About to connect() to tools.ietf.org port 80 (#0)
 *   Trying 194.146.105.14... connected
 * Connected to tools.ietf.org (194.146.105.14) port 80 (#0)
 > GET /html/draft-ietf-dkim-rfc4871bis HTTP/1.1
 > User-Agent: curl/7.17.1 (i586-pc-mingw32msvc) libcurl/7.17.1 OpenSSL/0.9.8b zlib/1.2.3
 > Host: tools.ietf.org
 > Accept: */*
 >
 < HTTP/1.1 302 Found
 < Date: Mon, 18 Oct 2010 08:43:09 GMT
 < Server: Apache/2.2.16 (Debian)
 < Location: http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-02

But then it delivers an empty document for that location:

 # curl -vO http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-02
 * About to connect() to tools.ietf.org port 80 (#0)
 *   Trying 194.146.105.14... connected
 * Connected to tools.ietf.org (194.146.105.14) port 80 (#0)
 > GET /html/draft-ietf-dkim-rfc4871bis-02 HTTP/1.1
 > User-Agent: curl/7.17.1 (i586-pc-mingw32msvc) libcurl/7.17.1 OpenSSL/0.9.8b zlib/1.2.3
 > Host: tools.ietf.org
 > Accept: */*
 >
 < HTTP/1.1 200 OK
 < Date: Mon, 18 Oct 2010 08:43:25 GMT
 < Server: Apache/2.2.16 (Debian)
 < Content-Location: draft-ietf-dkim-rfc4871bis-02.html
 < Vary: negotiate
 < TCN: choice
 < Last-Modified: Mon, 11 Oct 2010 22:32:20 GMT
 < ETag: "15d10aa-0-4925eeeee0500;492e02b528300"
 < Accept-Ranges: bytes
 < Content-Length: 0
 < Content-Type: text/html; charset=UTF-8

And in http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-01 there
is no mention at all of -02.  Why?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 18 Oct 2010 11:31:52 +0100

> signing.  Adding would /always/ break the signature.

I assumed that the proposal applied only to headers rfc5322 says cannot be 
duplicated. This is almost the same as saying that non-compliant messages 
MUST not verify, but more explicit, and therefore more helpful to 
implementers of verification code.

> That's a very powerful semantic change.

Not particularly, if these messages are already not supposed to verify.

> I've no idea that it's completely safe.  It seems like it ought to be,
> but I  worry about corner cases.
>
> d/
>
> ps.  I would expect such a semantic change to require re-cycling the spec
> at  Proposed.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:43:21 +0100

On Fri, 15 Oct 2010 17:50:33 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> If that's consensus, then we're on the slippery slope of "fixing" DKIM  
> to deal with flaws at all layers above it.  And we'll never be done.

If you want to fix ADSP first, then let us hear your proposals, and when  
we have fixed it we can then go back to finalizing 4871-bis.

But may I ramind you that you alreade said:

On Fri, 15 Oct 2010 17:46:56 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> The current effort has everything to do with moving DKIM to draft  
> standard, and nothing at all to do with handling ADSP issues.

In which case we have no option but to fix it in DKIM.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:23:44 +0100

> They're not apparently from them. They *are* from them.

No they are not. Clearly you have  failed to understand the scam that I am  
concerned about, though I have explained in often enough.

> Irrelevant for the current discussion.

On the contrary, that is precisely the attack of interest, so it is  
supremely relevant. You claim it can be thwarted by other means, but have  
failed to explain exactly how those "other means" would work.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:29:12 +0100

On Fri, 15 Oct 2010 18:04:22 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> This to me says you still believe DKIM's ultimate payload is something  
> other than a validated identifier, in this case a domain name.  We're  
> thus not on the same page.
>
> If instead we do agree that that's its sole intended purpose (and  
> consensus on the errata RFC was achieved, thus confirming this), then  
> you also have to agree that DKIM already does that.  The MUAs simply  
> fail to make use of it, and that's the real problem.

But we DON'T agree that. It may have been a commonly held opinion at some  
time, but recent contributions to these threads indicate a considerable  
opinion otherwise.

The best opinion seems to be Mark's "What you see is what they sent".

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 18 Oct 2010 06:07:15 -0700

On 10/18/2010 3:31 AM, Ian Eiloart wrote:
> --On 15 October 2010 11:53:51 -0400 Dave CROCKER<[email-masked]>  wrote:
> duplicated.

That is a constraint that was not stated.  Specifications do not allow assuming. 
  As offered, the modification would have the effect that I stated and /not/ the 
one you state.

d/
-- 

   Dave Crocker

---

From: "Mark Delany" <[email-masked]>
Date: 18 Oct 2010 06:19:28 -0700

On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote:
> That is a constraint that was not stated.

It is now.

Mark.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 18 Oct 2010 06:28:13 -0700

...
>> That is a constraint that was not stated.

This probably requires a substantive change to the specification.  I'm not clear 
whether it would force the spec to re-cycle at Proposed.

d/

-- 

   Dave Crocker

---

From: Wietse Venema <[email-masked]>
Date: Mon, 18 Oct 2010 09:49:43 -0400 (EDT)

> ones that paypal sent. No more, no less.

But the user does not see a bunch of bits. The user sees the combined
result of software layers that render those bits.  DKIM has no
control over that rendering process.

DKIM can only guarantee that "what you RECEIVED is what I signed".
To get "what you SEE is what I signed" semantics, one could do the
following:

a) Exchange all email as static image files.

b) Make DKIM verifiers aware of all possible ways to exploit the
   message rendering process without breaking the DKIM signature.
   For example, prepend extra Subject: etc.  header; add message
   header with JAVASCRIPT that overlays part of the message display;
   add other out-of-spec content, or corner-case within-spec content.

c) Recommend that MUAs make it easy for users to recognize which
   parts of a message display are covered by whose (DKIM) signature.

d) Go back to non-MIME ASCII-only email, use fixed-width fonts
   on 80-character displays and only mandatory, single-instance,
   non-folding headers.

Of these, a) and d) solve the problem but are unlikely to happen,
while b) and c) address the same problems in different places and
will need to be revisited every time some new exploitable MUA
feature is introduced. Option b) is called layering violation and
c) is called kicking the can down the street.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 10:23:21 -0400

> control over that rendering process.

Well, not widely yet, but you do have Gmail and Yahoo Online MUA show
info regarding valid signatures.  That is a DKIM controlled input bit.

We are almost ready to begin similar MUA changes as well starting with
our Online MUA. But before we do that, we need to get a 100% clear
indication of the expectations.  Right now, it seems to be a low key item.

> [SNIP] [SNIP]

I see you have a funny bone in you. :)

---

From: "Mark Delany" <[email-masked]>
Date: 18 Oct 2010 09:27:17 -0700

> control over that rendering process.

Really? Do you mean doesn't or shouldn't or can't?

Apropos layering violations: are we saying that having a UA inject
message 'A' via a DKIM layer into the mail stream, and then having
some random/malicious goop cause message 'B' to pop out of the DKIM
rabbit hole at the other end is less of a layer violation than
ensuring that message 'A' comes out that rabbit hole?

That seems odd.

Even if layer-violation is viewed by some as an immutable law, there
is some argument that allow the 'B' rabbit to pop out is failing that
law.

Mark.

---

From: Wietse Venema <[email-masked]>
Date: Mon, 18 Oct 2010 14:01:28 -0400 (EDT)

> Really? Do you mean doesn't or shouldn't or can't?

Does DKIM control text-to-voice conversion, or text-to-text language
translation? These are just two ways of presenting email to a user
that I could come up with.

Obviously these two are among the more lossy transformations. But
even text-to-screen conversion, without language translation, can
produce different results with different MUAs as discussed at the
beginning of this family of ietf-dkim threads.

> ensuring that message 'A' comes out that rabbit hole?

Bad guys don't have to play by the rules. For example, message A
is sent by the signer, and comes out of the verifier as A++.  The
++ stands for extra content that does not break the DKIM signature,
but that changes the way the message content is presented to the
user. This is one of the problems that this family of ietf-dkim
threads is concerned with.

	Wietse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:11:20 -0700

> Sent: Friday, October 15, 2010 11:39 PM

We either believe MUAs suffer from inertia and won't in any reasonable timeframe be able to show the good vs. bad parts of a message, or we think this work can provoke such evolution.  So let's look at those two possibilities specifically.

If we claim MUAs will grow to embrace DKIM, then by definition they will be able to show the parts of the message that were covered by the signature hashes and those that were not.  For the double-From case, this would mean one of them (the "good" one) is rendered differently than the other (the "bad" one).  If that's the case, DKIM doesn't need to worry about it beyond providing advice for MUAs that they should do so because they're already going to do that.  There's no need for normative language in this case.

If on the other hand we believe they won't change in a reasonable timeframe, then we appear to be asserting that is incumbent on a complete/safe/useful DKIM verifier to take corrective action so that the MUA's DKIM-ignorance can't be exploited.  That means a DKIM implementation has to be integrated into the MTA enough that it can cause alteration or removal of suspect header fields or even block message delivery entirely.  Merely detecting that an incoming message is malformed (e.g. two From: fields, whether or not either was signed) and refusing to verify it is insufficient, because that has the net effect of setting a bit that the MUA likely won't even check, whether that's the Boolean result of a library function or an Authentication-Results field that few people are actually seeing or checking.  So adding these enforcement requirements with an essentially invisible impact when errors are found adds dull teeth and useless complexity to the document.  Instead, this makes D!
 KIM verification a required MTA function even though we specifically said we were trying to create a layer that had no such capabilities (as reflected in RFC4871, Section 1).  That makes it bigger than what this group was ever scoped to do.  Maybe that means in retrospect that our scope was too small, but that's a different issue.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:17:48 -0700

> Sent: Saturday, October 16, 2010 10:43 AM
> To: Wietse Venema; [email-masked]

That's a pretty neat framing of the question.

> What is the value proposition that DKIM offers that incentivizes people

I'll take a crack at that: DKIM offers the MUA enough data to know what parts of a message to be rendered can be considered "valid" inasmuch as someone (the signer) took responsibility for it.  How it's rendered is up to the MUA.  We certainly, and probably should, provide some advice in this area to MUA implementations, but we haven't the teeth to demand it.

> of DKIM..... in a negative manner.

Since we're all big on analogies, how about:

Experian can give you the rating of someone applying for credit.  Whether or not you pay attention to that information in making your credit decision is entirely up to you.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:19:06 -0700

> Sent: Saturday, October 16, 2010 11:56 AM

Doesn't this statement advocate for informative advice rather than normative requirements?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:25:31 -0700

> Sent: Sunday, October 17, 2010 6:23 PM

Current implementations, especially the two library ones that are referenced most often in here, haven't the functionality to cause header fields to be removed, prefixed, reordered, modified, etc.  This change would require them to be overhauled to extend their reach into what the MTA can do.  That expansion of scope of "DKIM process" to me requires a recycle at Proposed Standard.

> prevent DKIM exploitation so who is going to solve that problem if not

There's nothing between an MTA and an MUA that prevents this attack in the non-DKIM case at all.  Whose place is it to fix that?

I can't get my head around how that case is irrelevant here.  This is not a new problem, but somehow we're being called upon to deal with it.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 18 Oct 2010 14:44:27 -0400

> Sent: Monday, October 18, 2010 2:26 PM
> Current implementations, especially the two library ones that are
> referenced most often in here, haven't the functionality to cause
header
> fields to be removed, prefixed, reordered, modified, etc.  This change
> would require them to be overhauled to extend their reach into what
the
> MTA can do.  That expansion of scope of "DKIM process" to me requires
a
> recycle at Proposed Standard.
> 

Assuming that is the consensus solution to the perceived problem.

> There's nothing between an MTA and an MUA that prevents this attack in
the
> non-DKIM case at all.  Whose place is it to fix that?
> 
> I can't get my head around how that case is irrelevant here.  This is
not
> a new problem, but somehow we're being called upon to deal with it.
> 

The non-DKIM case makes no assertion with regard to authentication (I
exclude PGP and S/MIME from the non-DKIM case I think you refer to). If
DKIM made no assertion regarding validation of headers + the body length
hash then we would almost certainly not be having this discussion in the
first place. To the extent that DKIM makes such claims then it is a
different case and needs to be considered separately from the non-DKIM
case.

I'm going to go back to the question I asked Wietse... Do we see double
headers (one signed and one unsigned one added later) in the normal
course of things in the wild? If not then rather than getting into the
MUA territory and fixing it, I say let's fix DKIM. If we only see this
type of behavior where there is potential non-good activity (I was going
to use malicious), we output a "warn" addition to a pass/fail/none. It's
not a huge check to look for the double headers and we aren't boiling
the ocean.

This leaves it to the MUAs to implement based on the DKIM output but it
addresses the DKIM related case.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 18 Oct 2010 11:50:03 -0700

On 10/18/2010 11:01 AM, Wietse Venema wrote:
> Does DKIM control text-to-voice conversion,
...
> even text-to-screen conversion,
...

Folks,

This is all slightly surreal.

There is a premise that is motivating the proponents of giving instructions to 
MUA designers about DKIM outcomes.  The premise is that providing DKIM 
information will be useful, and possibly that providing /more/ DKIM information 
will be more useful.  (There is also some unfortunate vagueness about the actual 
meaning of some of this information.)

This has nothing to do with layer violations, architectural purity or even the 
intractability of gaining change to MUAs.  It has to do with the cognitive 
models employed for MUA design.

The premise is wrong.

Or rather, the premise is naive and probably wrong.

The premise is based on a model of typical users that has nothing to do with 
/actual/ typical users.

Folks making assertions about what MUAs should do need to gain some background 
in UXE and usability design, starting with cognitive models for UIs.  They 
should pay particular attention to the repeated observation that users 
understand little of what they see from the system and care about understanding 
it little.  (This observation is not specific to MUAs or even computer interface 
design.  The design of control environments often is more a task of /reducing/ 
information than of increasing it, due to limitations of human processing, 
especially in real time.)

This working group can, at best, recite a list of information that is available 
to MUAs.  The instant this group starts to make normative statements about the 
use of that information, it is entering into territory about which it lacks 
sufficient expertise.

Moving from the slightly cautious "probably wrong" above, I'll revert to the 
sentence before it, concerning the idea that marking validated versus 
invalidated information will somehow be useful for typical users."  It's simply 
and plainly wrong.

As a small example of how peculiar the current line of advocacy is, I'll suggest 
a simple example:

    Alice sends Bob a message.

    Alice diligently signs all the right header fields and all of the body.

    Bob's MUA is sophisticated and up to date, so it displays the message with 
this extra information about the "validity" of the message.

    What is the actual value of this marking, given that Alice is really a spammer?

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:50:46 -0700

> Sent: Monday, October 18, 2010 11:44 AM
> Subject: RE: [ietf-dkim] Data integrity claims
> 
> > There's nothing between an MTA and an MUA that prevents this attack in the
> > I can't get my head around how that case is irrelevant here.  This is not

DKIM doesn't claim the value in From: was valid, only that it was unchanged.

If the MUA is DKIM-aware, then it will render the From: field covered by the signature, even though the value that field could be completely bogus.  If the MUA is DKIM-ignorant, it renders the "first" one, for some search order.

In neither case is there an assertion of validity of the content.

> type of behavior where there is potential non-good activity (I was
> going to use malicious), we output a "warn" addition to a pass/fail/none. It's

If we can output a "warn" bit in addition to pass/fail/none, we're also presuming the MUAs will adapt to consume it.  But then the MUAs can just as easily adapt to show you what parts of the message were signed and which were not, and that is in fact the more complete solution.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 11:59:26 -0700

> Sent: Monday, October 18, 2010 11:50 AM
> Subject: Re: [ietf-dkim] How MUAs render mail
> 

I would go one step further and suggest that we should give MUA designers credit that they have done this research.  If we find that to be too generous, then I will joyfully concede that at least I have not done, and do not wish to do, that kind of research; I'm happy to leave it to them to do or not do.

This only reinforces my desire to treat DKIM like an API; export all the information we get from the verification process and let other components deal with filtering or rendering.  It's outside of our purview.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Oct 2010 15:02:49 -0400

On Monday, October 18, 2010 02:19:06 pm Murray S. Kucherawy wrote:
> > > The current DKIM spec does not answer these questions and easily
> > > permits protecting very little of the message.  Almost certainly too
> > > little to ensure the protection you assert.
> > 
> > One can also point a gun at ones own head.  That doesn't make a gun a
> > suicide device of no value for anything else.  The spec does permit
> > people to do silly things, but so what.
> 

I'm OK with that, but the informative advice needs to be in security 
considerations, IMO.

Scott K

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 18 Oct 2010 15:10:59 -0400

> Sent: Monday, October 18, 2010 2:51 PM

I said validation, not valid. That is in line with the 4871 text that
uses  "validate" or some variation 22 times. That is, what was signed is
what was validated on the receiving/verifying side.

> If the MUA is DKIM-aware, then it will render the From: field covered
by
> the signature, even though the value that field could be completely
bogus.
> If the MUA is DKIM-ignorant, it renders the "first" one, for some
search
> order.

See above. This leads me to believe that you might be amenable to
informative text rather than normative text.  

> If we can output a "warn" bit in addition to pass/fail/none, we're
also
> presuming the MUAs will adapt to consume it.  But then the MUAs can
just
> as easily adapt to show you what parts of the message were signed and
> which were not, and that is in fact the more complete solution.
> 
> 

This is no more presumptuous than expecting that MUAs will adapt to
consume the output of DKIM as it stands now. The question is the value
equation. I'm not in a position to answer that question. Perhaps we
should try to get some of the MUA folks to join the conversation. It may
be that some of the well known ones go... "hey, never thought about this
issue and yeah, we will look into fixing it based on the wider scope".
On the other hand they might inquire if we are smoking crack (Just
trying to give the two extremes of responses).

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 12:18:16 -0700

> Sent: Monday, October 18, 2010 12:11 PM

Yes, I'm in favour of the most amazing Security Considerations addendum you could ever imagine to cover this, and not in favour of normative text.

> > If we can output a "warn" bit in addition to pass/fail/none, we're also
> > presuming the MUAs will adapt to consume it.  But then the MUAs can just
> consume the output of DKIM as it stands now.

In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't.  If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way.
 
I'm fine with accepting either model, but we have to understand the implications of picking one.  The latter, in particular, involves some major scope creep.

> Perhaps we should try to get some of the MUA folks to join the conversation.

That's a novel idea!  I'll poll some other lists I'm on (and you're also on, so you can make sure my wording isn't leading) and see if I can get any feedback.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 18 Oct 2010 15:23:43 -0400

I'm trying to find a way for us to build a consensus on how to move
forward. 

While I have tended towards favoring a normative approach, you are
swaying me with this "amazing Security Considerations addendum".

Mike

> Sent: Monday, October 18, 2010 3:18 PM
> Yes, I'm in favour of the most amazing Security Considerations
addendum
> you could ever imagine to cover this, and not in favour of normative
text.
> In another message I indicated that I don't presume either, but assert
> that there's no middle ground; they will or they won't.  If they will,
> informative text is sufficient; if they won't, then we have to start
> hardening MTAs to defend against MUA attacks because that's where
header
> changes and other enforcements are possible since, by definition, any
> current annotations are invisible and will stay that way.
> 
> I'm fine with accepting either model, but we have to understand the
> implications of picking one.  The latter, in particular, involves some
> major scope creep.
> 
> That's a novel idea!  I'll poll some other lists I'm on (and you're
also
> on, so you can make sure my wording isn't leading) and see if I can
get
> any feedback.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Oct 2010 12:35:35 -0700

>> ones that paypal sent. No more, no less.
Be careful not to limit concerns to what is displayed, since DKIM 
results also affect how mail might be sorted or filtered.
> control over that rendering process.
DKIM never controls the rendering process.  DKIM only controls the 
verification results being reported.
> a) Exchange all email as static image files.
Static image files would not correct the mistaken application of DKIM 
results on illegally pre-pended From header fields used for sorting, for 
example.  The only sure method to deal with these types of exploits 
would be to prohibit such messages from receiving a DKIM PASS.
>     add other out-of-spec content, or corner-case within-spec content.
Close.  By now few MUAs permit scripts to automatically run.  Some make 
handling exceptions when the From email address is found in their 
contact list, which can also be conditioned upon obtaining a DKIM PASS.
>     parts of a message display are covered by whose (DKIM) signature.
The DKIM l= parameter makes displaying results of multiple signatures 
problematic.  Clearly, DKIM did not consider how partial signature 
coverage might be conveyed.  Only the From header field stands out as an 
exception for DKIM and ADSP.
>     on 80-character displays and only mandatory, single-instance,
DKIM does not need to limit email in this manner to provide reasonable 
protections, which is still not afforded by ASCII-only email without 
also RFC5322 compliance.
> Of these, a) and d) solve the problem but are unlikely to happen,
Disagree.  Neither a) or d) solves the problem.

> feature is introduced.
Agreed with respect to b), however as a general rule, scripts obtained 
from unknown sources should not be executed.
> Option b) is called layering violation and
Agreed, b) would be a layering violation when it involves anything other 
than the formulation of a DKIM result.  However, unlike an MTA, DKIM is 
rightfully concerned with the proper structure of the RFC5322 message to 
prevent exploits.
> c) is called kicking the can down the street.
Fully agree.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 16:00:53 -0400

> trying to give the two extremes of responses).

I'm a MUA author of BOTH types and people forget that there are TWO 
kinds here.  We have:

    Console based Mail Reader/Writers Online Interface (Dialup/Telnet)

         telnet bbs.wisnerver.com
         or
         305-248-7815

    A Frontend Native GUI ONLINE Interface

         http://www.winserver.com/public/wcnavigator.wct

    A Frontend Web-based ONLINE Interface

         http://www.winserver.com  (you have to log in)

    Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers:

         http://www.santronics.com/products/olx/index.php
         http://www.santronics.com/products/sxpress/index.php

    Two Administrator Report Reader/Writer Online Interfaces

         http://www.santronics.com/products/pxpress/index.php

    A Outlook Exchange Component

         http://www.santronics.com/products/winserver/Exchange.php

And very important

     NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC
     based Store and forward offline mail reader/writers.

All MUAs, including are feed by the backend.  It is the BACKEND that 
feeds the children what it will eat (see).   We can ALTER and DO 
whatever we please to give whatever the ILLUSION we want the MUA to see.

This issue is a BACKEND issue whether we want to deal with it at a:

    MSA    Authenticated Submission (For Local or Remote User/Relay)
    MDA    Non-Authenticated Submission to LOCAL USER ONLY

or at some DKIM integrated component.

To assume that this is should be PUSHED first to MUAs is BAD 
engineering and NAIVE.

But that doesn't mean they don't have to look for it just in case an 
3rd party interface software (like an RFC-based mail/writer) whats to 
make sure that all backends are correct.

So as I said in an earlier post, technically, all parts need to deal 
with this but more so the DKIM API because this is part of their 
"Reason For Living" in the first place - mail integrity.

Its like a Neighborhood Watch Program vs Real Cops.  Everyone will 
need to deal with it.  But the BACKEND is the #1 place to deal with 
this especially for systems that only have Online Interface devices 
and/or Legacy Online or Offline mail readers who require (and don't 
even think about it) that the backend "mommy" give them clean food to 
eat - not poison, dirty food.

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 16:16:50 -0400

Murray S. Kucherawy wrote:

> Current implementations, especially the two library ones that 
> are referenced most often in here, haven't the functionality to 
> cause header fields to be removed, prefixed, reordered, modified, 
> etc.  This change would require them to be overhauled to extend 
> their reach into what the MTA can do.  That expansion of scope 
> of "DKIM process" to me requires a recycle at Proposed Standard.

What started all this is one of these API dealing with it with the 
verification and I pointing this out.  However, we did not know why it 
did this and we later found out.

Their solution was only on the verification side with an added 
requirement that all 5322.From be signed - the default behavior.

So any belated injection of a 5322.From header would invalidate the 
signature which I believe will cover the majority of the loophole.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 13:19:18 -0700

> Sent: Monday, October 18, 2010 4:24 AM
> To: DKIM

On the contrary, none of this is within the prescribed scope of DKIM.  ADSP and reputation (the latter of which is explicitly out of scope) are predicated on DKIM's output, not part of its input or its mechanics.

These topics are distractions from the effort of solidifying the DKIM specification for advancement along the standards track.  That's what I believe he means by "irrelevant for the current discussion".

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 16:19:12 -0400

FWIW, the telnet mail interface typo fix should be:

       telnet bbs.winserver.com

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 16:36:37 -0400

> On the contrary, none of this is within the prescribed scope of DKIM.  ADSP and reputation (the latter of which is explicitly out of scope) are predicated on DKIM's output, not part of its input or…

 From an IETF "standpoint" it might not be, but from an engineering
standpoint, I beg to differ.

> These topics are distractions from the effort of solidifying the DKIM specification for advancement along the standards track.  That's what I believe he means by "irrelevant for the current discuss…

We need to stop blaming others. Borrowing an old QA engineering motto:

      "Getting it Right..... The First Time!"

Otherwise, you get what you have today.  Note, that is not about
"perfection," but rather proper engineering to minimize customer
issues even it if means a little more upfront cost.

In my view, a good bit of the issue was manifested by the on-going out
of scope design considerations with a) defocusing of Policy and b)
greater allowance for unrestricted resigners and participants were 
providing
input that there was an engineering problem with this.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Oct 2010 15:32:33 -0700

On 10/18/10 12:18 PM, Murray S. Kucherawy wrote:
> >> This is no more presumptuous than expecting that MUAs will adapt
> >> to consume the output of DKIM as it stands now.
 >
>  In another message I indicated that I don't presume either, but
>  assert that there's no middle ground; they will or they won't. If
>  they will, informative text is sufficient; if they won't, then we
>  have to start hardening MTAs to defend against MUA attacks because
>  that's where header changes and other enforcements are possible
>  since, by definition, any current annotations are invisible and will
>  stay that way.
>
>  implications of picking one. The latter, in particular, involves
>  some major scope creep.

Should the charter of a security related protocol need to anticipate 
minor modifications to a verification process, that appears essential 
for ensuring a DKIM signature is not inappropriately associated with an 
incorrect From header field?

Rather than expecting changes to a plethora of consumers of DKIM 
results, which might be used for sorting or display, ensuring PERMFAIL 
occurs whenever replicate From header fields are detected ensures DKIM 
will not be complicit in deceiving consumers of its results.

Adding such a check represents a normative change to DKIM, since it can 
not be just advisory warnings to DKIM's consumers that suggests when 
DKIM results should be ignored.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 16:15:51 -0700

> Sent: Monday, October 18, 2010 3:33 PM

Any effort, security or otherwise, needs to scope itself correctly.  We, for very good reasons, chartered ourselves originally to come up with a system that requires minimal infrastructure changes.

I claim that inserting an Authentication-Results field is minimal, as it is incremental.  But if we also claim MUAs and users pretty much ignore that, which is the case today, then it (or any solution that is strictly an annotation of some kind) fails to have the protective impact you're seeking.  The only option then is to obstruct delivery in some way, and that is not incremental and thus not minimal, and certainly pushes the boundaries of our charter (e.g. [1]).

> will not be complicit in deceiving consumers of its results.

This, again, fails to deliver on your stated goal since the PERMFAIL result is almost completely invisible.  On the other hand, if you claim MUAs will adapt to DKIM to show what parts of a message were covered by a validated signature, then we don't really need to provide any normative requirements because MUAs have already figured out what they need to do.

[1] http://tools.ietf.org/wg/dkim/charters?item=charter-dkim-2006-07-03.txt

---

From: "John R. Levine" <[email-masked]>
Date: 18 Oct 2010 20:07:39 -0400

> Merely detecting that an incoming message is malformed (e.g. two From: 
> fields, whether or not either was signed) and refusing to verify it is 
> insufficient, because that has the net effect of setting a bit that the 
> MUA likely won't even check, ...

This is getting awfully overcomplicated. One of the key differences 
between DKIM and predecessors such as S/MIME is that it can reasonably 
operate as a layer between MTA and MTA or MTA and MUA, without requiring 
integration into either.  When we were working out relaxed 
canonicalization, it is my distinct recollection that our goal was to 
allow only changes that would make only insignficant changes to the 
message rendering in MUAs. Hence we didn't allow adding arbitrary white 
space since that would let bad guys reformat mail as ASCII art.

What I'm proposing, and am part way through implementing, is just to 
disallow a few more situations that are likely to make a large difference 
to the rendered appearance.  My current plan is to have the verifier fail 
if there are both signed and unsigned instances of any of the headers that 
are supposed to occur only once.  That's it.  If a signer wants to sign 
two Subject: headers, that's fine so long as the verifier sees the same 
two Subject: headers and no more--the message the user sees is the one the 
signer signed.

Note that this design is not in the least idiot-proof, but if a signer 
uses a normal set of options (by which I mean following the advice in 
4871), it means that if someone renders a message with a valid signature, 
it'll look like what the signer signed.

In the absence of a signature, mail systems will continue to do whatever 
they do now.  Their behavior when a message has two Subject: lines is 
pretty random, but I don't really care, since it hasn't been a problem so 
far.  What this prevents is signature based whitelisting, either absolute 
whitelisting or spam filter positive scoring, of a message that's not what 
the signer signed.

So, uh, can we agree that Jim's SHOULD language to tell people to do this 
is a good idea?

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 20:21:42 -0400

I think most people understand this:

    - DKIM "SHOULD" be checking its input,

    - With increase awareness, the backend MTA receivers "SHOULD"
      checking for these "Special RFC5322" multiple header issues.

Whether SHOULD should be changed to MUST is not a concern to me, 
either way, there is guidelines the DKIM component and the system it 
is integrated into needs to address as a new consideration to lock 
down related implementation requirements.

How this is done (written) in 4871bis, I leave the RFC doc experts to 
do this and if they need to "write" it in a way that will not slow 
down DKIM to draft standard, as long as the above semantics are 
provided, I think the job is done.

The h=from:from "kludge" I see as a temporary solution for engines 
that are able to work with that preparation and I am on the fence if 
this should be added to the 4871bis.  I see it as a short term note 
because ultimately, even will be on the same plane to understand the 
RFC 5322 mail bots need to do this, especially on the receiver side.

But more important, I think it does require code change and its not 
just an Operator DKIM options.

SSI and ALT-N has agreed that SSI can enhance the library for general 
purpose usage with the updated DKIM flexibility needs, especially on 
the ADSP extension side as it was hard coded for ADSP as it is written 
today with a subjective but hard coded rule  on how DKIM=ALL is 
interpreted.

The changes have not be submitted to the version control system yet 
and won't be until Alt-N final approval.

I changed ALT-N DKIM API (LIBDKIM) and it would able to now offer the 
h=from:from kludge but this was not the reason for the change.

I can't say how OpenDKIM does it, but the LIBDKIM default minimum API 
usage behavior is to sign all the headers and it is hard coded to skip 
these headers only:

     X-*
     Authentication-Result
     Return-Path

Howwer, the LIBDKIM API provides two application level methods on what 
headers to sign or skip:

    1) Call Back per Header with a boolean result.

       return true  - sign it
       return false - skip it (don't sign it)

    2) optional string szRequiredHeaders

For general purpose usage of the API, the callback method will not be 
possible for embedded p-code server side languages, so the only other 
way is to pass the optional szRequiredHeaders string.

However,  szRequiredHeaders only allows you to set the headers to 
include it might have skipped.  It is not a way to define the 
exclusive specific headers to sign only.

So I added a logical flag option:

    int nUseRequiredHeadersOnly; // 1 - used szRequireHeaders and
                                 // exclude the rest. 0 - fallback
                                 // to default sign all headers
                                 // behavior

that allows you use szRequiredHeader as the only headers to sign.

I did this because it was signing headers I didn't think it sign 
including Received: which 4871 recommends as a SHOULD NOT.

I wanted operator defined local policy options to specified headers it 
wanted to sign on a per DKIM author/signer domain setup basis.  From 
an product engineering standpoint, it needs this flexibility.

But the current open source version is not capable of using this 
h=from:from kludge and that probably means any implementation of this 
API can't do it as well unless it has altered it to do something like 
we did.

Anyway, my main point is that I don't think we will cover all possible 
methods to resolves without deeper working group analysis and hence 
delays.  But we can say the basic ideas as above:

    - DKIM SHOULD|MUST checks it main inputs

    - Receiver MTA SHOULD|MUST check RFC5322 more strongly with
      a specific guidance on what it should focus on in order for
      DKIM to be protected.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Oct 2010 20:25:00 -0400

> I'll take a crack at that: DKIM offers the MUA enough data to know what 
> parts of a message to be rendered can be considered "valid" inasmuch as 
> someone (the signer) took responsibility for it.

I have to disagree.  DKIM offers the ability for a domain to take 
responsibility for a message.  A signing domain with any sense will sign 
messages in a way that ensures that they don't get smashed between the 
time they're signed and the time they're rendered, so the whole thing is 
"valid".

While it's certainly possible to create signatures that don't include the 
To:, Date: or Subject: lines and have l=0, I doubt that a signer who did 
that would earn a reputation good enough for anyone to care whether they 
signed a message or not.

Also, although I certainly do not purport to be a whiz at UI design, it's 
hard to think of a more pessimal UI design than one that tries to tell 
Grandma what parts of a message to believe with changing colors or fonts 
in various parts of the message window.  She can barely grasp the 
difference between a green bar SSL page and one with no SSL.  I don't want 
to mess with the MUA at all, but rather use DKIM to help decide what 
messages to show her and which messages to consign to the junk folder.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Oct 2010 17:27:17 -0700

> Sent: Monday, October 18, 2010 5:25 PM
> To: Murray S. Kucherawy

Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks?

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Oct 2010 20:32:29 -0400

John R. Levine wrote:

> So, uh, can we agree that Jim's SHOULD language to tell people to do 
> this is a good idea?

Yes. +1.  I think I was the first to agree with Jim's input and didn't 
see much follow up except you and maybe another person.

Maybe Barry can provide a repeat of the exact change proposal and get 
a preliminary show of hands.

Personally?

I think from a reader standpoint:

   Additional 5322.From Exception Paragraph in Section 5.4 after
   the paragraph about "use the last field found"

That is where a reader/developer will begin to scratch his header on 
what headers to sign and verify.  So it needs a quick "by the way" 
paragraph regarding a special exception for 5322.From against the "use 
the last field" rule in the previous paragraph.

But in the name of moving forward, Jim's text does the job.

---

From: John Levine <[email-masked]>
Date: 19 Oct 2010 00:50:25 -0000

>Why do we think such a sorting module can't/won't have the
>intelligence to do the RFC5322 Section 3.6 checks?

Sheesh, I think I've answered this at least three times now.  In the
absence of a DKIM signature, there is no reason to worry about doubled
headers since there is no reason to think one is "real" and the other
"fake".  They're only a threat when they provide a way to make a DKIM
signed message render differently from what the signer expected.

No DKIM -> no threat -> no special treatment.  I don't know how to
make this any clearer.  That's why sorting modules don't worry about
it now.

As I've also said before, either DKIM has a SHOULD about doubled
headers, or the equivalent advice goes into the folklore about what
you have to do make DKIM useful.  Personally, I think the latter would
be a cruel joke on future implementors, but apparently other people
feel differently.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 18 Oct 2010 18:20:47 -0700

> signed message render differently from what the signer expected.

A "threat" isn't the only way to consider this.

There's a strong correlation between badly structured emails
(SMTP, MIME, HTML) and email that the recipient doesn't
want to see.

> be a cruel joke on future implementors, but apparently other people

I think even a SHOULD might be a bit strong, but it's certainly
worth mentioning as something that an architectural module
either upstream or downstream of the DKIM verifier should
be aware of.

OTOH, we already have a SHOULD that tells MUA writers
to splatter the d= field somewhere in the GUI where the user
can't ignore it, so we're a long way away from anything like a
sensible separation of responsibility in the DKIM spec already.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Oct 2010 18:35:56 -0700

On 10/18/10 4:15 PM, Murray S. Kucherawy wrote:
> > On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote:
> >
> > Should the charter of a security related protocol need to
> > anticipate minor modifications to a verification process, that
> > appears essential for ensuring a DKIM signature is not
> > inappropriately associated with an incorrect From header field?
>
>  Any effort, security or otherwise, needs to scope itself correctly.
>  We, for very good reasons, chartered ourselves originally to come up
>  with a system that requires minimal infrastructure changes.
>
>  I claim that inserting an Authentication-Results field is minimal, as
>  it is incremental. But if we also claim MUAs and users pretty much
>  ignore that, which is the case today, then it (or any solution that
>  is strictly an annotation of some kind) fails to have the protective
>  impact you're seeking. The only option then is to obstruct delivery
>  in some way, and that is not incremental and thus not minimal, and
>  certainly pushes the boundaries of our charter (e.g. [1]).

Ensuring an inappropriate DKIM PASS result is not conveyed through _any_ 
results mechanism when there are multiple From header fields is the 
_only_ means able to deal with not knowing how the information will be 
used.

For DKIM to play a role, it must affect how a message is handled, and/or 
how it is displayed.  There is no way to know which.  In either case, 
returning a DKIM PASS when there are multiple From header fields 
represents a result that is easily exploited.   Since multiple From 
header fields violate RFC5322, there should not be a problem in having 
DKIM require a MUST return PERMFAIL in such a case.

There is little to justify even checking the validity of the signature 
for multiple From header fields.  Advice indicating these messages 
should be refused seems wholly appropriate, but this might conflict with 
a desire to leave interpretations of DKIM results be defined by a policy 
layer that specifies appropriate actions.

> > results, which might be used for sorting or display, ensuring
> > PERMFAIL occurs whenever replicate From header fields are detected
> > ensures DKIM will not be complicit in deceiving consumers of its
> > results.
>
>  This, again, fails to deliver on your stated goal since the PERMFAIL
>  result is almost completely invisible. On the other hand, if you
>  claim MUAs will adapt to DKIM to show what parts of a message were
>  covered by a validated signature, then we don't really need to
>  provide any normative requirements because MUAs have already figured
>  out what they need to do.

An MUA is only one of many different DKIM results consumers.  The MUA 
may highlight a From header field when signed by an Author Domain, or 
annotate the domain offering a valid DKIM signature.  Either way, 
ensuring the DKIM result is PERMFAIL is the only sure method to ensure 
exploitation is thwarted.

Are you suggesting DKIM should advise consumers about when PASS should 
be ignored, and about critical checks that were skipped?  This of course 
would be due to DKIM's lack of format compliance checking of elements 
bound to the signature.  I too am willing to support Jim's text as being 
a reasonable alternative to kicking the can down the road.

-Doug

---

From: John Levine <[email-masked]>
Date: 19 Oct 2010 02:55:15 -0000

>There's a strong correlation between badly structured emails (SMTP,
>MIME, HTML) and email that the recipient doesn't want to see.

You're right, but I think that's largely orthogonal to DKIM.  If a
message has a good signature from a credible signer, I expect I'd want
to show it to the user even if it had structure problems.  I'd like to
make the trust model as simple as possible, preferably

  good signature -> good messsage

rather than

  good signature + tidy SMTP + correct headers + unobjectionable HTML
    + favorable phase of moon -> good message

If a message doesn't have a credible signature, then you still use the
structure heuristics.

>can't ignore it

Ugh, you're right.  Now that I look at it, I'd like to completely
delete Appendix D, since it says some things that are just wrong,
i.e. language that implies that the signature contains someone's email
address, and some stuff that hasn't been implemented and quite
possibly never will be, e.g., highlighting the signed parts of the
message.

Personally, I have no idea which signing domains are credible and
which aren't, and I have no interest in my MUA showing them to me so I
can try and guess.  That's much better handled in the MTA or MDA,
using something like VBR to check the signer's credibility.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 Oct 2010 02:10:41 -0400

> using something like VBR to check the signer's credibility.

John,

Please take a step back (into the balcony) to reflect on what you are 
saying here.  I personally appreciated your recent input in the 
threads hitting the right notes.

I think Appendix D touches base with some impractical MUA 
considerations regarding different bits - its either good or bad.

I've written several (long) drafts of a response and concluded with 
something I believe we already discussed in years past:

       MUA trust of the Backend Information provided.

Its a simplistic statement but hopefully one can see based on the 
realistic backend/MUA operations.

Overall, we have two types of MUAs:

   - Online MUA with complete backend control of what is rendered
     based on a suite of backend available information.

   - Offline MUA where the backend has to pass "information" to
     the MUA in a common standard data format we call RFC 5322.

Lets use gmail or yahoo as an example as you once reference these as 
quick ways to test verify signature generations.

These were online MUA methods and both systems had control on how to 
convey valid DKIM signatures with their online GUI display.

But as you are aware, the user can also setup his account to pick yup 
mail via POP3 (or IMAP) for users who wish to use an RFC-based offline 
mail reader (like Outlook, Thunderbird, etc).

In this case, we have yet to developed a way to convey the same online 
experience in a time-shifted offline manner.

Gmail can only pass the A-R (Authentication-Results) header. But I 
believe we concluded long ago the general MUA can not trust headers 
like A-R. The offline MUA developer is not going adding support for 
A-R unless he is 100% sure it is a trusted header generated by the 
back end host. ISP, ESP, etc.

If the offline MUA does not get what is needed from an authenticated 
mail pickup, then it may redundantly repeat the DKIM verification.  It 
might do this anyway to cover the market of non-DKIM supportive mail 
pickup host.

Overall, the point is the backend has complete control of what to 
display for its online access user interfaces. But for the offline 
MUA, there wasn't muuc we done to give them trust and avoid repeating 
the DKIM verification.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Oct 2010 09:45:38 +0200

> meaning of some of this information.)

Providing DKIM information /will/ be useful.  Only the second part is 
probably wrong, because a signature cannot do more than validate.

>      Alice diligently signs all the right header fields and all of the body.

I think Dave gave a deceptive description on purpose, to check whether 
we still confuse DKIM and S/MIME.  If we're talking DKIM, the subtle 
difference between author and author domain characterizes the signing.

>      What is the actual value of this marking, given that Alice is really a spammer?

IMHO the goal is distinguishing between two categories of spam, 
tractable and intractable.  More precisely, two categories of 
/messages/ --DKIM knows nothing about spam.  Bob knows that in case he 
complains he will probably be listened with the diligence that Alice's 
domain is reputed for:  That's the actual value of the marking.

Please reply to [domainrep].
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Oct 2010 12:30:33 +0200

On 19/Oct/10 04:55, John Levine wrote:
>    good signature ->  good message
> 
> rather than
> 

+1.  That's why I don't think much of "Jim's SHOULD language",
recommending stiff syntax validation in response to a threat whose
only known trait is technical feasibility.

Verifiers are already authorized to react "with extreme skepticism".
We can better their diagnostic capabilities, but cannot recommend a
therapy that we never tried.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 19 Oct 2010 11:15:19 +0100

> So, uh, can we agree that Jim's SHOULD language to tell people to do this

+1 Yes, please.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 19 Oct 2010 11:04:32 +0100

> using something like VBR to check the signer's credibility.

Yeah, but this is the overriding assumption for any display to the user: 
that the user is going to do the reputation assignment. Now, if the 
signature is verified, the verifying domain matches the From: header, and I 
know and trust the owner of the sending account, then I'm going to be 
fairly confident. Of course, there's always the possibility that the 
account has been compromised, though...

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 19 Oct 2010 10:58:47 +0100

--On 18 October 2010 20:25:00 -0400 "John R. Levine" <[email-masked]> wrote:

> difference between a green bar SSL page and one with no SSL.  I don't
> want  to mess with the MUA at all, but rather use DKIM to help decide
> what  messages to show her and which messages to consign to the junk
> folder.

True, but there already are UI designs that indicate when a From header is 
DKIM verified. Hopefully, the indicator will only be displayed with the 
correct From header, and only when at least a substantial part of the body 
is verified, along with the other displayed headers.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 19 Oct 2010 11:11:58 +0100

>     What is the actual value of this marking, given that Alice is really

It's that, in order to get the marking, she can't spoof a trusted person's 
sender address. That requires, of course, that the markup requires that the 
signing domain have some connection with the Author domain. I don't know if 
there's a standard for that, but some heuristics might be usefully 
implemented in the MUA. For example, it might only display the validity 
information if there's an exact match.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 19 Oct 2010 08:47:02 -0400

> [email-masked]] On Behalf Of John Levine
> Sent: Monday, October 18, 2010 10:55 PM

Look further down the email at your comment "Personally, I have no idea
which signing domains are credible and which aren't..." and then explain
the leap to

   good signature -> good message.

Don't you mean

	Good signature -> authenticated message (that is, someone
accepts responsibility)

---

From: Wietse Venema <[email-masked]>
Date: Tue, 19 Oct 2010 09:18:45 -0400 (EDT)

>   good signature -> good messsage

I agree with John's earlier message that to make DKIM useful for
automated whitelisting, we end up with something slightly more
complicated:

   valid signature + good signer 
   + no suspicious unsigned content -> good message

My preference would be to enforce this within the existing protocol
(that is: send h=from:from:subject:subject...), but I could live
with hard-coded checks for unsigned single-instance RFC 5322 and
MIME headers (that is: no DKIM PASS for unsigned "extra" From,
Subject, MIME-Version, Content-type, etc.  headers).

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Oct 2010 07:31:58 -0700

>     + no suspicious unsigned content ->  good message

Has nobody learned that "good" signers from "good" authors
can still be evil? I mean come on, people, bot'd machines? This
is horrible advice.

s/unsigned/; and this works.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 11:23:39 -0400

> 	Good signature -> authenticated message (that is, someone

When I said good, I meant credible, not just one that mechanically 
validates.  I hope that we all agree that a signature from a domain about 
which one knows nothing is not usefully different from no signature at 
all.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 11:35:53 -0400

> DKIM verified.

So you're saying that all a spammer has to do is to put on a throwaway 
domain's signature, and the MUA will highlight at least parts of the 
message with green goodness?  Surely our understanding of domain 
reputation is better than that.

Any chance you can tell me which MUAs have this misfeature, so I can tell 
people to return them and ask for a refund?

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 11:54:24 -0400

> Yeah, but this is the overriding assumption for any display to the user: that 
> the user is going to do the reputation assignment.

Systems like Goodmail suggest that this assumuption is fundamentally 
wrong.  It puts a little flag on messages that are endorsed by a vouching 
service.  Webmail providers like it, the issues that Goodmail had with 
Yahoo et al were about the implementation, not the idea.

Speaking as a user, I have better things to do than to do the mail 
filtering that my mail system can and should be doing.  Having talked to a 
lot of people who run large mail systems at MAAWG and other places, I 
think they agree.  They use feedback from Junk buttons to tune the filters 
and manage sender reputation, not to do the primary filtering.

Regards,

---

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

> Sent: Monday, October 18, 2010 5:50 PM
> Sheesh, I think I've answered this at least three times now.

Well gosh, I sure do appreciate your patience in dealing with the rest of us fools that might not share your view or have something else to offer.

> In the

But some agents, maybe even many of them, do via some mechanism decide that one is the "real" one and make a filtering decision based on it.  It might be as simple as an MUA electing to render the first one it finds, for some value of "first".

> be a cruel joke on future implementors, but apparently other people

And just like when you said it the first time, I still don't share your view that a Security Considerations section of a Draft Standard document can be classified as "folklore".

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Oct 2010 10:28:54 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 19, 2010 2:59 AM
> To: John R. Levine; Murray S. Kucherawy

Yeah.  Now if only there was a place in the RFC that would be appropriate to contain informative advice about how to process DKIM results...

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 16:33:21 -0400

> Well gosh, I sure do appreciate your patience in dealing with the rest 
> of us fools that might not share your view or have something else to 
> offer.

Sorry.  But I could swear we had this exact exchange before.

> But some agents, maybe even many of them, do via some mechanism decide 
> that one is the "real" one and make a filtering decision based on it.  It 
> might be as simple as an MUA electing to render the first one it finds, 
> for some value of "first".

Aha!  We did have this discussion.  I reported that tried a few MUAs and 
found that some MUAs render the first one, some render the last.  Each MUA 
appears to be internally consistent but there's no consistency from one 
MUA to another.

To me this says that at this point nobody's considered doubled headers to 
be other than a bug, since they haven't provided a way to do anything 
antisocial--they don't evade filters and they don't crash MUAs.  It's only 
a threat when, well, you know.

Re Security Considerations, it's better than nothing, but it would be nice 
to put in concrete advice rather than a general warning, i.e., "verifiers 
SHOULD NOT verify a signature on a message that contains a mix of signed 
and unsigned copies of a header that is supposed to occur only once", 
rather than "bad guys can do bad things by adding extra headers to signed 
messages."

I believe the SHOULD NOT plugs the hole without changing DKIM's behavior 
on any valid message, but I want to finish coding it and try it for a 
while to see what else I've missed.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 19 Oct 2010 13:45:01 -0700

On 10/19/2010 1:33 PM, John R. Levine wrote:
> Re Security Considerations, it's better than nothing,

Not necessarily.

The current issue is part of a much larger one.  We will not be dealing with 
that larger set of security details because it is out of scope.  Dealing with a 
narrow piece of it, in a very narrow specification, gives the patina of dealing 
with something, without the substance.

So it establishes a false sense of resolving a security issue.

d/
-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 13:39:34 -0400

What we have is a reproducible issue that can add "stuff" without breaking an existing signature (if I am following along correctly) so that an email CAN show up in a MUA and be heralded as a DKIM VALIDATED signature as well as promote the added "stuff"
My opinion is to look at how to not allow a signature to validate after someone has added "stuff" and making sure that the DKIM current validators are aware of this exploit until a fix is proposed
thanks,
Bill

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 17:46:54 -0400

> So it establishes a false sense of resolving a security issue.

Hmmn.  I could reiterate for a fourth time why the double header thing is 
only a security issue in the context of DKIM, but there's clearly 
something else going on that prevents people from getting it.

Here's a question: in the absence of DKIM, does anyone think that doubled 
headers present a security problem?  If so, what is the problem, and how 
has it been addressed in the past?

R's,
John

PS: For the moment, please treat "smells like spam" as not a security 
problem.  If it's a spam sign, does any spam filter currently look for it?

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Oct 2010 15:27:07 -0700

On 10/19/10 1:45 PM, Dave CROCKER wrote:
>  The current issue is part of a much larger one. We will not be
>  dealing with that larger set of security details because it is out
>  of scope. Dealing with a narrow piece of it, in a very narrow
>  specification, gives the patina of dealing with something, without
>  the substance.
>

Ignoring pre-pended From headers in DKIM's verification process has 
demonstrated trust established by a DKIM signature can then be 
exploited.  This ONLY affects the DKIM trust being established.  While 
this issue should not be resolved with /just/ changes to Security 
Considerations, any update to DKIM must correct this serious deficiency.

DKIM does not permit assignment of negative reputations for undesired 
messages when RCPT TO parameters are not apparent within the message.  
This leaves the narrow use of DKIM being for establishing trust from 
known good sources.   This trust MUST NOT be extended to messages having 
pre-pended From header fields,  where the wrong field might be selected 
for filtering or display.  After all, ONLY the From header field is 
assured by DKIM as being bound to the message.  Consumers of DKIM 
results should not need to understand the intricacies of the DKIM 
process with respect to the From header field.

In addition, the Subject of this thread is not correct.  The issue is 
not related to either header or body mutations.  The issue is related to 
a From header fields being pre-pended to a signed message, where 
evaluations of such a message can ONLY safely return PERMFAIL.  
Returning anything else is likely to provide recipients a false sense of 
security.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Oct 2010 17:08:11 -0700

> Sent: Tuesday, October 19, 2010 2:47 PM
> To: DKIM List
> Subject: [ietf-dkim] double header reality check
> 
> Hmmn.  I could reiterate for a fourth time why the double header thing
> is only a security issue in the context of DKIM, but there's clearly

Obviously you believe your view is unassailable, but please stop asserting that people who don't see it your way are automatically thick.

> Here's a question: in the absence of DKIM, does anyone think that
> doubled headers present a security problem?

I have also repeatedly said "yes" to this question.

> If so, what is the
> problem, and how has it been addressed in the past?

Any filter or agent that makes any kind of filtering, routing or sorting decision based on any header field which in turn presumes there's only one such field without actually checking is a potential security concern.  That extends not only to routing and filtering of messages, but also to their rendering.

Examples:

- procmail, which by default acts on the first match it finds without first confirming RFC5322 validity, so if I know or can figure out your rule sets I can do something that will get bad mail into a good folder or other internal mail stream, and then an MUA could render the From: or whatever field that wasn't the one subjected to filtering (as your own experiment showed)

- SpamAssassin, which can reformat possible spam by wrapping it in MIME content using new header fields extracted from the original message, but only takes one (the last) of each of the ones listed in its man page when doing so, meaning a filtering action can be taken that results in false data being rendered in the report; then the user sees that something he/she wanted was tagged as spam and complains (there may be worse exploits, that's just the most obvious one after my code review)

- Mailman authenticates postings and subscription requests based on the first instance of From or Sender it finds, but relays both so a downstream filter or MUA would see both and thus potentially make a wrong handling (rendering/filtering/routing) decision

- majordomo, same as Mailman

There were several instances I found as well in other lesser-known filtering tools, but these ones will hopefully provide some context.  And since those problems are there in the code for each I just downloaded and reviewed, I would say they have not yet been addressed.

Since the issue is an attempt to fool users, those seem to me to be in the same family as the other thing we're talking about.  And none of them have anything at all to do with DKIM.

---

From: "Mark Delany" <[email-masked]>
Date: 19 Oct 2010 17:53:11 -0700

> Any filter or agent that makes any kind of filtering, routing or
> sorting decision based on any header field which in turn presumes
> there's only one such field without actually checking is a potential
> security concern.

I think this is a subtely different problem though.

All of the examples you cite (and all other pre-DKIM examples for that
matter) are foolable with a single forged header today. That they
could be further fooled with multiple headers is not an issue.

In a future world where such tools (and UAs) could act with authority
because DKIM has assured the headers/payload is where we have the
problem.

Only once tools and UAs take advantage of DKIM, do these attacks
become relevant. That's why I think this is a DKIM problem. We are
wanting tools and UAs to take advantage of DKIM but by doing so they
are possibly making themselves more vulnerable to attackers.

A simple (but hyperthetical) example. If you unsubscribe from a list
today, most list servers typically confirm the request by emailing you
back with some nonce to ensure the unsubscribe request isn't
forged. You then hit reply or click on the link to confirm you have
access to that mailbox, etc.

In a DKIM world a list server could reasonable use DKIM to bypass this
"confirm" sequence and make your life a bit simpler. Perhaps it relies
on Authentication-Results or somesuch. In any event such a list server
is actually *more* vulnerable than it is today if we let thru bogus
payload that appear to be valid.

IOW. Asking them to rely on DKIM is a backward step.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 Oct 2010 21:09:43 -0400

These are not MSA or MDAs so its a different set of assumed preconditions.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Oct 2010 18:10:55 -0700

> Since the issue is an attempt to fool users, those seem to me to be in the same family as the other thing we're talking about.  And none of them have anything at all to do with DKIM.
Disagree.

It is TRUST being established by DKIM that is being exploited!  Messages 
lacking authenticated assertions regarding its origination is normally 
not trusted to any extent.  As such, multiple From header fields 
primarily concerns only DKIM as TRUST exploits.  Normal leniency 
provided for RFC5322 non-conformance demonstrates there is normally 
little TRUST to be exploited, and thus without DKIM there is little 
concern.

It is when a person sees a DKIM based lock-icon on their message, for 
example, is when recipients might be placed at risk by undetected 
inclusion of multiple From header fields.  That oversight in DKIM's 
validation process MUST be corrected to ensure DKIM's integrity.  DKIM 
is a security related protocol offering much more than just an 
authenticated message tag.  DKIM also binds this domain with the From 
header field.  Therefore, unlike normal email, Trust in the DKIM domain 
is extended to include the From header field.

Are you suggesting DKIM should not check for the presence of this 
multiple From header field exploit and indicate this with a PERMFAIL 
result?  Do you really think that some other component of email should 
be checking for RFC5322 compliance?

You and Dave seem determined at making this some other processes 
concern.  Which email process should be expected to alert recipients?  
What other protocols needs to be updated?

SMTP? IMAP? POP3? SIEVE?  DKIM is truly the only logical process where 
this check /MUST/ be made.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 Oct 2010 21:27:23 -0400

+1

And this is why

1) we MUST establish the DKIM boundary conditions for 100% success and 
100% failure.  You have to move all parties into the same playing 
field and those that are not compliant are pushed out.

2) the conflict in the deployment to allow for unrestrictive resigners 
with no willingness to establish 3rd party policies simply makes 
everything even more indeterminate.  How can we tell when the 
"valuable" signer identity is good, bad and/or exploiting the 
originating domain?

Unless we get an solid anchor for 100% Zero False Positive boundary 
conditions, it makes all this very hard in what is already very complex.

DKIM has the high potential to become the next relaxed "Return Path" 
dilemma the industry knew since the 80s was insecure, but not yet 
highly exploited where we didn't do much about it.

Every good idea has a solid well defined problem it solves.  DKIM was 
one suppose to be the alternative to SPF because it has the "PATH" 
problem.

By deemphasizing policy and opening the door for unrestricted 
resigners, its now become a last signer authentication protocol.

Anyway, to get back to the problem, we need to do less subjective 
analysis and just try to get the deterministic bits of DKIM well 
defined - valid input and it needs to check it probably is only thing 
left.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Oct 2010 23:10:53 -0400

Murray is of course correct that duplicated headers could be used to fool 
sorting programs like procmail or filtering programs.

I have an archive of a lot of the spam received on my system in recent 
years, so I've been grepping through it looking for duplicated from and 
subject headers.  Here's what I've found so far.

The URLs below are real, and will fetch you a copy of the spam.  Each line 
tells how many from and subject lines the message has, and "same" means 
the two subjects are the same.  In this tiny sample, every duplicated 
subject is the same, and the duplicated froms are all similar to each 
other, and appear to be due to bugs in the spamware, not malicious intent.

I dunno what that tells us, other than that whatever attack is enabled by 
duplicated headers, it doesn't appear to have happened yet.  But I do 
share Mark's concern that it would be unfortunate if there were ways to 
make significant changes to the way a message renders without breaking a 
non-silly signature, i.e., one that covers the usual headers and the whole 
body.

R's,
John

http://spample.iecc.com/uft/22579237 !!! from 2 subj 1
http://spample.iecc.com/trh/22584748 !!! from 1 subj 2 same
http://spample.iecc.com/hua/22585805 !!! from 1 subj 2 same
http://spample.iecc.com/jaw/22594898 !!! from 1 subj 2 same
http://spample.iecc.com/jcf/22594899 !!! from 1 subj 2 same
http://spample.iecc.com/kea/22594900 !!! from 1 subj 2 same
http://spample.iecc.com/kgi/22594901 !!! from 1 subj 2 same
http://spample.iecc.com/ljd/22594902 !!! from 1 subj 2 same
http://spample.iecc.com/llm/22594903 !!! from 1 subj 2 same
http://spample.iecc.com/mnh/22594904 !!! from 1 subj 2 same
http://spample.iecc.com/mpp/22594905 !!! from 1 subj 2 same
http://spample.iecc.com/nrk/22594906 !!! from 1 subj 2 same
http://spample.iecc.com/ntt/22594907 !!! from 1 subj 2 same
http://spample.iecc.com/pxx/22594909 !!! from 1 subj 2 same
http://spample.iecc.com/pzr/22594910 !!! from 1 subj 2 same
http://spample.iecc.com/qba/22594911 !!! from 1 subj 2 same
http://spample.iecc.com/qdv/22594912 !!! from 1 subj 2 same
http://spample.iecc.com/rge/22594913 !!! from 1 subj 2 same
http://spample.iecc.com/riy/22594914 !!! from 1 subj 2 same
http://spample.iecc.com/syh/22594915 !!! from 1 subj 2 same
http://spample.iecc.com/sac/22594916 !!! from 1 subj 2 same
http://spample.iecc.com/tcl/22594917 !!! from 1 subj 2 same
http://spample.iecc.com/teg/22594918 !!! from 1 subj 2 same
http://spample.iecc.com/ugo/22594919 !!! from 1 subj 2 same
http://spample.iecc.com/uij/22594920 !!! from 1 subj 2 same
http://spample.iecc.com/vks/22594921 !!! from 1 subj 2 same
http://spample.iecc.com/vmn/22594922 !!! from 1 subj 2 same
http://spample.iecc.com/wov/22594923 !!! from 1 subj 2 same
http://spample.iecc.com/xrq/22594924 !!! from 1 subj 2 same
http://spample.iecc.com/xtz/22594925 !!! from 1 subj 2 same
http://spample.iecc.com/yvu/22594926 !!! from 1 subj 2 same
http://spample.iecc.com/yxc/22594927 !!! from 1 subj 2 same
http://spample.iecc.com/zzx/22594928 !!! from 1 subj 2 same
http://spample.iecc.com/zbg/22594929 !!! from 1 subj 2 same
http://spample.iecc.com/adb/22594930 !!! from 1 subj 2 same
http://spample.iecc.com/afk/22594931 !!! from 1 subj 2 same
http://spample.iecc.com/bhe/22594932 !!! from 1 subj 2 same
http://spample.iecc.com/bjn/22594933 !!! from 1 subj 2 same
http://spample.iecc.com/cli/22594934 !!! from 1 subj 2 same
http://spample.iecc.com/cor/22594935 !!! from 1 subj 2 same
http://spample.iecc.com/dql/22594936 !!! from 1 subj 2 same
http://spample.iecc.com/dsu/22594937 !!! from 1 subj 2 same
http://spample.iecc.com/eup/22594938 !!! from 1 subj 2 same
http://spample.iecc.com/ewy/22594939 !!! from 1 subj 2 same
http://spample.iecc.com/fys/22594940 !!! from 1 subj 2 same
http://spample.iecc.com/gab/22594941 !!! from 1 subj 2 same
http://spample.iecc.com/gcw/22594942 !!! from 1 subj 2 same
http://spample.iecc.com/her/22594943 !!! from 1 subj 2 same
http://spample.iecc.com/hga/22594944 !!! from 1 subj 2 same
http://spample.iecc.com/iiu/22594945 !!! from 1 subj 2 same
http://spample.iecc.com/ild/22594946 !!! from 1 subj 2 same
http://spample.iecc.com/jph/22594948 !!! from 1 subj 2 same
http://spample.iecc.com/krb/22594949 !!! from 1 subj 2 same
http://spample.iecc.com/khk/22594950 !!! from 1 subj 2 same
http://spample.iecc.com/ljf/22594951 !!! from 1 subj 2 same
http://spample.iecc.com/llo/22594952 !!! from 1 subj 2 same
http://spample.iecc.com/mpr/22594954 !!! from 1 subj 2 same
http://spample.iecc.com/nrm/22594955 !!! from 1 subj 2 same
http://spample.iecc.com/ntv/22594956 !!! from 1 subj 2 same
http://spample.iecc.com/owq/22594957 !!! from 1 subj 2 same
http://spample.iecc.com/pyy/22594958 !!! from 1 subj 2 same
http://spample.iecc.com/pat/22594959 !!! from 1 subj 2 same
http://spample.iecc.com/qcc/22594960 !!! from 1 subj 2 same
http://spample.iecc.com/qex/22594961 !!! from 1 subj 2 same
http://spample.iecc.com/rgf/22594962 !!! from 1 subj 2 same
http://spample.iecc.com/ria/22594963 !!! from 1 subj 2 same
http://spample.iecc.com/skj/22594964 !!! from 1 subj 2 same
http://spample.iecc.com/sme/22594965 !!! from 1 subj 2 same
http://spample.iecc.com/tom/22594966 !!! from 1 subj 2 same
http://spample.iecc.com/tqh/22594967 !!! from 1 subj 2 same
http://spample.iecc.com/usq/22594968 !!! from 1 subj 2 same
http://spample.iecc.com/uvl/22594969 !!! from 1 subj 2 same
http://spample.iecc.com/vxu/22594970 !!! from 1 subj 2 same
http://spample.iecc.com/vzo/22594971 !!! from 1 subj 2 same
http://spample.iecc.com/wbx/22594972 !!! from 1 subj 2 same
http://spample.iecc.com/wds/22594973 !!! from 1 subj 2 same
http://spample.iecc.com/xfb/22594974 !!! from 1 subj 2 same
http://spample.iecc.com/yhv/22594975 !!! from 1 subj 2 same
http://spample.iecc.com/yje/22594976 !!! from 1 subj 2 same
http://spample.iecc.com/zlz/22594977 !!! from 1 subj 2 same
http://spample.iecc.com/zni/22594978 !!! from 1 subj 2 same
http://spample.iecc.com/apc/22594979 !!! from 1 subj 2 same
http://spample.iecc.com/asl/22594980 !!! from 1 subj 2 same
http://spample.iecc.com/cyk/22594983 !!! from 1 subj 2 same
http://spample.iecc.com/cas/22594984 !!! from 1 subj 2 same
http://spample.iecc.com/dcn/22594985 !!! from 1 subj 2 same
http://spample.iecc.com/dsi/22594986 !!! from 1 subj 2 same
http://spample.iecc.com/eur/22594987 !!! from 1 subj 2 same
http://spample.iecc.com/lxp/22595001 !!! from 1 subj 2 same
http://spample.iecc.com/iwr/22595338 !!! from 2 subj 1
http://spample.iecc.com/lct/22596053 !!! from 1 subj 2 same
http://spample.iecc.com/kzp/22619085 !!! from 1 subj 2 same
http://spample.iecc.com/lpk/22619086 !!! from 1 subj 2 same
http://spample.iecc.com/ypw/22622689 !!! from 2 subj 1
http://spample.iecc.com/ppv/22626347 !!! from 1 subj 2 same
http://spample.iecc.com/lna/22626634 !!! from 1 subj 2 same
http://spample.iecc.com/qsk/22626692 !!! from 2 subj 1
http://spample.iecc.com/kaa/22628715 !!! from 2 subj 1
http://spample.iecc.com/edn/22647571 !!! from 1 subj 2 same
http://spample.iecc.com/zpf/22649547 !!! from 1 subj 2 same
http://spample.iecc.com/jaa/22650694 !!! from 1 subj 2 same
http://spample.iecc.com/kps/22666352 !!! from 1 subj 2 same
http://spample.iecc.com/lvr/22666355 !!! from 1 subj 2 same
http://spample.iecc.com/vuo/22667011 !!! from 1 subj 2 same
http://spample.iecc.com/wxj/22667012 !!! from 1 subj 2 same
http://spample.iecc.com/wzr/22667013 !!! from 1 subj 2 same
http://spample.iecc.com/ubi/22667352 !!! from 1 subj 2 same
http://spample.iecc.com/lxd/22668927 !!! from 1 subj 2 same
http://spample.iecc.com/lzm/22668928 !!! from 1 subj 2 same
http://spample.iecc.com/mbh/22668929 !!! from 1 subj 2 same
http://spample.iecc.com/oqm/22674006 !!! from 1 subj 2 same
http://spample.iecc.com/ibk/22674042 !!! from 1 subj 2 same
http://spample.iecc.com/eur/22675628 !!! from 2 subj 1
http://spample.iecc.com/oxu/22678416 !!! from 2 subj 1
http://spample.iecc.com/avr/22678636 !!! from 1 subj 2 same
http://spample.iecc.com/bxm/22678637 !!! from 1 subj 2 same
http://spample.iecc.com/aci/22682408 !!! from 2 subj 1
http://spample.iecc.com/yps/22683752 !!! from 1 subj 2 same

Regards,

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Oct 2010 01:17:04 -0400

John R. Levine wrote:

> duplicated headers, it doesn't appear to have happened yet.  

Maybe it has and it is the best kept secret loophole by spammers and 
spoofers. Maybe there should be more research into the site mail 
archives to see how much of this was among us fooling users for a long 
time.

Maybe it slowed down as the larger ISPs or ESPs began to filter 
invalid RFC 822, 2822/5322 messages like gmail.com does now.  But then 
again, gmail.com is relatively new entry.

I can tell you that in our 25+ year old mail package which was the top 
5 BBS mail packages in the 80s and early 90s never looked for this as 
far as I recall and only recently I added a server script to check for 
it after discovering why Alt-N modified their API to check for the 
multiple non-hashed From: headers.

Alt-N input on this was they did not see any evidence of wide usage 
other than the fact it was a customer report and they updated their 
DKIM API to add a "new requirement" for verification - all 5322.From 
must be hashed.

That is why the President Obama message got into here.  It had two 
5322.From headers which was signed by my system when it sent the 
message to Dave's system.   Dave's system validated the double from 
and resigned without hesitation.

However when I sent the double from without a valid signature, it 
barfed the message.

What your research shows the problem is REAL.  What we don't know is 
how much it has effected the end-users as part the phishing and 
spoofing schemes because I will venture that most systems do not check 
for this.

Thanks to DKIM - now they will and for the legacy systems adding a 
DKIM standalone component, the DKIM component MUST also check for this 
loophole.

---

From: SM <[email-masked]>
Date: Wed, 20 Oct 2010 01:41:03 -0700

>payload that appear to be valid.

According to Section 7 of RFC 5672:

   "For DKIM processing, the domain name portion of the AUID has
    only basic domain name semantics; any possible owner-specific
    semantics are outside the scope of DKIM."

Furthermore, in Section 8:

   "A module that consumes DKIM's mandatory payload, which is the
    responsible Signing Domain Identifier (SDID).  The module is
    dedicated to the assessment of the delivered identifier.  Other
    DKIM (and non-DKIM) values can also be delivered to this module as
    well as to a more general message evaluation filtering engine.
    However, this additional activity is outside the scope of the DKIM
    signature specification."

Based on the above, I don't think that a list server could use DKIM 
to bypass the "confirm" sequence.

Regards,
-sm

---

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

On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> On the contrary, none of this is within the prescribed scope of DKIM.   
> ADSP and reputation (the latter of which is explicitly out of scope) are  
> predicated on DKIM's output, not part of its input or its mechanics.
>
> These topics are distractions from the effort of solidifying the DKIM  
> specification for advancement along the standards track.  That's what I  
> believe he means by "irrelevant for the current discussion".

The scam I have described involves the use, by the phisher, of a  
DKIM-signed (by himself) email with two From: headers, which is intended  
to fool verifiers into not spotting that the first signature should have  
triggered an ADSP lookup which would have revealed that the first From:  
was 'discardable'.

Naturally, the phisher signs with a throaway domain that has not yet  
acquired any reputation, good or bad.

Since the scam involves the use of DKIM, and since the only fix I am aware  
of requires a change to the DKIM standard, then it is highly relevant to  
the current discussion.

---

From: "Mark Delany" <[email-masked]>
Date: 20 Oct 2010 05:24:50 -0700

> to bypass the "confirm" sequence.

Well, that's "should". It also assumes that all subsequent users of
DKIM bother to read and obey. It also assumes that future users of
DKIM won't get inventive and use DKIM in ways that we can't even
imagine. I think that undersells DKIM and future users.

Just ask the inventors of DNS whether they thought we'd be using it
the way we are... or whether we're using it the way they intended.

Mark.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 20 Oct 2010 16:27:16 +0200

> of requires a change to the DKIM standard, then it is highly relevant to

IMHO, this issue has to be addressed refining the signing spec.  For 
example, the initial paragraph of section 5.4 could be modified so as 
to read:

   The From header field MUST be signed; that is, it MUST be included
   at least once in the "h=" tag of the resulting DKIM-Signature
   header field, and SHOULD be included twice (see Section 8.14).  In
   addition, the signer MUST ensure that at most one instance of the
   From field actually exists in the header.

The current PS silently assumes that there is a single From, and I 
guess most interoperability and testing has been done in such 
conditions.  Hence an amendment like the text above can be understood 
as a clarification --rather than a change-- of the protocol.

Verifiers would then discard any From field after the first one, 
whether signed or not.  Of course, a combo-verifier is always free to 
return some error due to bad message syntax, even if all signatures 
verify (although I'd consider it cleaner to return non-DKIM errors for 
non-DKIM failures.)

JM2C

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Oct 2010 15:12:47 +0100

>> 	Good signature -> authenticated message (that is, someone

I think it needs to mean

Good signature -> authenticated message (that is, someone accepts  
responsibility, where "someone" is identifiable at least to the extent of  
being or not being  the domain in whatever From: is shown).
> which one knows nothing is not usefully different from no signature at

A reputation service can only say that a domain is
    BAD
    GOOD
or NO EVIDENCE AVAILABLE EITHER WAY.

I think the last case has to be treated pretty much like GOOD, otherwise  
newcomers to the internet will never even get their messages accepted.

There might be some merit in a repuation service responding with
    DOMAIN CREATED WITHIN THE LAST 15 MINUTES
although even that should have been "Domain first used within the last 15  
minutes", except I cannot see how a reputation service coulr know that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Oct 2010 15:15:39 +0100

On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema <[email-masked]>  
wrote:

> (that is: send h=from:from:subject:subject...),

But that only copes with some of the scams that are possible; for full  
protection you need

> ... but I could live

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Oct 2010 15:22:36 +0100

> a preliminary show of hands.

I would say +1, but only if it was a MUST rather than a SHOULD (which I  
think it can be provided you do not ask for excessively meticulous 5322  
checks).

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Oct 2010 15:35:50 +0100

On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> hardening MTAs to defend against MUA attacks because that's where header  

No it doesn't. I believe they "won't" (at least not on any short enough  
timescale). But we are already in the "hardening" business, because the  
basic assumption made by DKIM was that the verification (and resulting  
action) could and would be done at the boundary layer as part of, or  
closely associated with, the final MTA, and without any change to existing  
MUAs.

What options for 'action' are available at that point (or were envisaged  
as being available at that point when DKIM was first written)? I can think  
of

    discarding (silently or noisily)
    increased spamassassin score
    warning to the end user (e.g. in a changed Subject header)

So all we need is to ensure that those same actions will be activated by  
this new threat; in which case the language to bring this about needs to  
be just as normative as in the rest of the DKIM specification.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Oct 2010 16:51:54 +0100

> or NO EVIDENCE AVAILABLE EITHER WAY.

Actually, a reputation service could offer a score that's more subtle than 
good/bad.

And, it could offer address reputation rather than domain reputation. That 
would be far more suitable for domains like the large email service 
providers, which have a mix of good and bad users.

<http://www.dkim-reputation.org/start/> offers address based reputation 
service. I've not used the service, so can't vouch for it.

---

From: "John R. Levine" <[email-masked]>
Date: 20 Oct 2010 11:54:38 -0400

[ I'm following this thread because it's related to advice in 4871 that we 
should probably remove from 4871bis ]

> I believe that's the basis of this whole discussion, isn't it. The point is 
> that the MUA tells you whether the header was signed, and leaves you to apply 
> the domain or address reputation. I think that's a step forward. At least, it 
> is when I know the purported author.

Hmmn.  You don't know the purported author, all you know is the actual 
signer.

We have a message offering you a job as an Internet Payment Processor. 
It's from [email-masked], and signed by 
reliable-home-work.com.  Do you paint it green and show it to your users? 
What if it was sent through gmail and had a google.com signature?  How 
many of your users even know what a money mule is?

I think that if you look through papers at CEAS and similar fora, you'll 
find that manual classification of mail is not particularly accurate, and 
is a huge waste of time.  Well tuned filters do at least as good a job 
with far less human effort, and the reasonable things for humans to do is 
to tell the filtering engine when it guessed wrong either explicitly, or 
implicitly by moving stuff between inbox and junk folder.

> And, surely I'm better at assigning reputation to -say- my brother than 
> any automated system is.

Given the number of spam complaints I get about on-topic messages to COI 
discussion lists, don't count on it.  And in any event, unless your 
brother is one of us weenies with his own vanity domain, his mail is going 
to be signed by his employer or his ISP, so he won't have his own 
mailstream reputation anyway.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Oct 2010 15:44:08 +0100

> s/unsigned/; and this works.

Well, everything's relative. If we can get to the point where a bot'd 
machine can only send email "From:" it's real owner, that'll be a huge 
improvement on the current situation. At that point, we can start to 
pressure the real owner into fixing their machine (say, by emailing them or 
their domain support, or by blacklisting their email)

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Oct 2010 16:10:55 +0100

--On 19 October 2010 11:35:53 -0400 "John R. Levine" <[email-masked]> wrote:

>> True, but there already are UI designs that indicate when a From header
>> is  DKIM verified.
>

I believe that's the basis of this whole discussion, isn't it. The point is 
that the MUA tells you whether the header was signed, and leaves you to 
apply the domain or address reputation. I think that's a step forward. At 
least, it is when I know the purported author. And, surely I'm better at 
assigning reputation to -say- my brother than any automated system is.

But, hey, I'm on your side here. I think we should put a warning in the RFC 
so that vendors are informed that they need to be sure they're highlighting 
the correct header.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Oct 2010 17:36:14 +0100

--On 20 October 2010 11:54:38 -0400 "John R. Levine" <[email-masked]> wrote:

> [ I'm following this thread because it's related to advice in 4871 that
> we should probably remove from 4871bis ]
>
>> I believe that's the basis of this whole discussion, isn't it. The point
>> is  that the MUA tells you whether the header was signed, and leaves you
>> to apply  the domain or address reputation. I think that's a step
>> forward. At least, it  is when I know the purported author.
>

I do know the *purported* author. It's right there in the From: header. 
DKIM tells me that it hasn't changed since it left the signer. My guess is 
that to get good reputation, domains won't be signing emails when that's 
spoofed. I know that we can't rely on that. YAHOO, for example, seem to be 
relaxed about their senders spoofing addresses. Hopefully they'll learn.

Even without changes in behaviour, I also know that a purported author in 
the yahoo.com domain is many times less likely to be spam if it has a valid 
DKIM signature from yahoo.com.

> reliable-home-work.com.  Do you paint it green and show it to your users?

Yes, because green doesn't mean this is a good email, it means this is 
really from that sender. You're then set to apply your personal reputation 
score to that sender.

> What if it was sent through gmail and had a google.com signature?

No, I wouldn't do that. I have no idea whether any MUAs would.

> How many of your users even know what a money mule is?

They have to be responsible for some stuff in life, but I certainly would 
not suggest that this should, would, or could replace spam filtering. All 
this has to be additional to what we already do, though it should permit 
more reliable whitelisting (say, of my brother's gmail.com address provided 
it was covered by a gmail.com signature).

> implicitly by moving stuff between inbox and junk folder.

Yes, I'm aware of all that.

> brother is one of us weenies with his own vanity domain, his mail is
> going to be signed by his employer or his ISP, so he won't have his own

---

From: "John R. Levine" <[email-masked]>
Date: 20 Oct 2010 13:32:44 -0400

> newcomers to the internet will never even get their messages accepted.

Heck, no.  Treat it like there's no signature at all, and filter it like 
one does now.

I hope the difference between whitelisting and filtering doesn't require 
further explanation.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Oct 2010 10:48:37 -0700

> verify (although I'd consider it cleaner to return non-DKIM errors for
Alessandro,

While this represents a defensive posture that might be used prior to 
DKIM reliably returning PERMFAIL when multiple From header fields are 
contained within the message,  it only thwarts half of the threat 
created by multiple From header fields.   As both Charles and I have 
illustrated:

 From [email-masked]
 From [email-masked]
Subject: Audit notification
<body of text saying anything>

This message could be sent directly, or distributed by replaying it to 
millions of recipients.

Nothing Big-Bank.com might do with their signing mitigates this variant 
of the double From header field attack.  The ONLY sure method is to 
ensure DKIM always returns PERMFAIL when multiple From header fields are 
detected, whether both or one of them are signed.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Oct 2010 10:55:19 -0700

> Sent: Tuesday, October 19, 2010 5:53 PM
> Subject: Re: [ietf-dkim] double header reality check
> 

I do understand the difference.  And I am not ignorant to the fact that any mail system component that's offered some new trust mechanism which has inherent exposure risks is not likely to adopt that mechanism anytime soon.  Plenty of examples exist, even in the email space, some of them fairly recent.

The job of a designer of such a mechanism (or any mechanism really) is twofold: (a) reduce risks as much as is practical, and (b) fully expose those that remain.  Both of these are easily accomplished by a specification that is clean and thorough.  Anyone who's shipped a product that can be tough to use knows that complete user documentation of the issues makes even a tricky product palatable to customers.  Forewarned is forearmed.

I think a lot of this discussion conflates protocol specification with implementation.  I'm focused on the former.  I maintain that including wording intimating that a DKIM implementation is non-compliant if it fails to do mail format validation prior to accepting input or returning a result causes the specification not to be clean.  It's a layering violation.  It's sloppy design.  It shouldn't be done.

The difference may be as subtle as what you're talking about above.  For example, although I am arguing that RFC4871bis shouldn't contain any kind of normative enforcement of other specifications, my own open source implementation already does it and has almost since day one.  I think that's the right thing to do, not because RFC4871 told me to, but because RFC5322 did.  And as a result, it's in the part of the code that deals with mail, not the part that deals with DKIM.

It also does all kinds of validation that the data it got back from the nameserver on a key or policy query conforms to the expected format of a DNS query described in RFC1034, because if it doesn't (which does happen sometimes, four so far today in the logs) then running with those bits can have nasty side effects.  But RFC4871 doesn't, and shouldn't, require that checking.  That syntax is defined in RFC1034.

Or are you folks also saying we should add text to RFC4871bis mandating validation of the results returned by functions like res_send()?  Suppose a chthonic hacker could send DKIM-signed mail that causes his DNS server to be queried, returning a reply that will somehow always validate (or crash).  And suppose res_send() doesn't validate the payload, only passes it through to the caller.  Isn't this just as dangerous?

We are most certainly obliged to emphasize to consumers of DKIM output the distinction between what was covered by a signature and what was not, and lay out the possibility that such consumers could be confounded in the way that's been described.  Failing to do so is a disservice.  I'm all for putting that into Security Considerations in intricate detail with lots of examples of possible exploits.  That, to me, is precisely why that section is mandated as part of all RFCs.  I will happily write a sesquipedalian treatise on this topic to be included there if it resolves this issue.

An aircraft comes with an operating handbook.  The manufacturer goes to great pains to make the aircraft as safe and secure as possible.  Ultimately, though, it's the pilot that crashes or lands, and thus learns the ins and outs of that particular aircraft by reading the ample documentation provided by the manufacturer before taking to the air.

No, Doug, I don't think these checks belong in POP3, or IMAP, or SIEVE.  They belong in whatever component is the one that decides when or whether seek or apply a DKIM result.  Like I said before, it should be perfectly reasonable for a protocol specification to require something proper from the layers below it, and to require of itself that it only hands something valid to the layers above it.

Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components.  Anything else makes as much sense to me as asserting that an MTA/MUA/whatever should only invoke a DKIM verifier after confirming that the DKIM-Signature header field conforms to what RFC4871 says.  I would find that equally incorrect, and for the very same reasons.

There has been talk of applying DKIM to technologies like Usenet and HTTP output.  Packing DKIM with mail-specific verification requirements could prevent such things from happening.  Shall we also add a "but only when used in the email context" clause?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 20 Oct 2010 15:30:19 -0400

> Sent: Wednesday, October 20, 2010 1:55 PM

<SNIP>

> 
> There has been talk of applying DKIM to technologies like Usenet and
HTTP
> output.  Packing DKIM with mail-specific verification requirements
could
> prevent such things from happening.  Shall we also add a "but only
when
> used in the email context" clause?
> 

Seeing as the M in DKIM stands for Mail, we don't have to put a "but
only when used in the email context" clause. If a DKIM like approach is
used for other protocols then we might reasonably text specific to those
protocols - DKIH (Domain Keys Identified HTML as an example). 

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Oct 2010 16:15:37 -0400

MH Michael Hammer (5304) wrote:
>> There has been talk of applying DKIM to technologies like 
>> Usenet and HTTP output.  Packing DKIM with mail-specific 
>> verification requirements could prevent such things from happening.  
>> Shall we also add a "but only when used in the email context" clause?

> protocols - DKIH (Domain Keys Identified HTML as an example). 

I guess because we are already integrated with different mail formats, 
I don't see the difference other than having implementation specific 
setup features.

For example a signing setup with a target rule

         Signer Domain::Target Domain

where the association will enforce certain headers to be signed.

In the case of usenet (or nntp specifically), the considerations might be:

    - enforce Path: header
    - enforce (maybe) Newsgroups: header
    - relaxed signing To: header (since its To: ALL for news)

But if you want to see how email is gated into public newsgroup areas, 
check out

     news://news.winserver.com

(use an anonymous account to login).

You will see how newsgroups are used for various list. One for the 
IETF-DRAFT submissions and other list areas shown as local public 
newsgroups.

One of interest where DKIM is used is the SPF-DISCUSS list/newsgroup 
where you can see the 10/17/2010 article titled:

       [spf-discuss] SPF Mail Summary Report

and if you view the message source and headers, you will see the 
Authorization-Results: header:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.i=listbox.com header.d=listbox.com header.s=launch;
   adsp=fail policy=all author.d=winserver.com asl.d=listbox.com 
(unauthorized signer);
   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com 
header.d=winserver.com header.s=tms1;
   adsp=pass policy=all author.d=winserver.com signer.d=winserver.com 
(originating signer);

When our system generated the weekly Summary Report, it was DKIM 
signed and exported  to the spf-discuss mailing list. The list server 
than broke and resigned it and when the copy came back to us, it will 
DKIM verified and put into the newsgroup area.

---

From: "John R. Levine" <[email-masked]>
Date: 20 Oct 2010 16:29:09 -0400

Here's another batch of spam with extra From or Subject
lines.  I see the same thing as last time, the extra
subjects are all the same, and the extra From lines look
like bugs, not attempts to evade filters.

The spam with 6,981 From lines is impressive in a wacky way.

R's,
John

http://spample.iecc.com/oko/13513473 !!! from 2 subj 1
http://spample.iecc.com/mai/13527118 !!! from 1 subj 2 same
http://spample.iecc.com/wnq/13527333 !!! from 2 subj 1
http://spample.iecc.com/xdg/13644660 !!! from 2 subj 1
http://spample.iecc.com/ydd/13658310 !!! from 2190 subj 1
http://spample.iecc.com/yic/13695408 !!! from 1 subj 2 same
http://spample.iecc.com/gkj/13764008 !!! from 6981 subj 1
http://spample.iecc.com/joi/13772001 !!! from 2 subj 1
http://spample.iecc.com/sxt/13794463 !!! from 840 subj 1
http://spample.iecc.com/euf/13894583 !!! from 2 subj 1
http://spample.iecc.com/gix/13906201 !!! from 1 subj 2 same
http://spample.iecc.com/bds/13961106 !!! from 2 subj 1
http://spample.iecc.com/jha/14009391 !!! from 2 subj 1
http://spample.iecc.com/ptl/14009501 !!! from 1 subj 2 same
http://spample.iecc.com/ndg/14053973 !!! from 1 subj 2 same
http://spample.iecc.com/ddz/14108277 !!! from 1 subj 2 same
http://spample.iecc.com/pes/14209695 !!! from 2 subj 1
http://spample.iecc.com/kfd/14263497 !!! from 1 subj 2 same
http://spample.iecc.com/qdg/14263705 !!! from 1 subj 2 same
http://spample.iecc.com/eyp/14268312 !!! from 1 subj 2 same
http://spample.iecc.com/uib/14277824 !!! from 1 subj 2 same
http://spample.iecc.com/mcj/14278398 !!! from 1 subj 2 same
http://spample.iecc.com/rwz/14317049 !!! from 1 subj 2 same
http://spample.iecc.com/syi/14317050 !!! from 1 subj 2 same
http://spample.iecc.com/ewh/14337217 !!! from 1 subj 2 same
http://spample.iecc.com/keh/14349846 !!! from 1 subj 2 same
http://spample.iecc.com/jtl/14351633 !!! from 1 subj 2 same
http://spample.iecc.com/hqw/14360328 !!! from 1 subj 2 same
http://spample.iecc.com/slz/14363168 !!! from 1 subj 2 same
http://spample.iecc.com/oqu/14370756 !!! from 1 subj 2 same
http://spample.iecc.com/shu/14370764 !!! from 1 subj 2 same
http://spample.iecc.com/mqz/14390820 !!! from 1 subj 2 same
http://spample.iecc.com/dxb/14392591 !!! from 1 subj 2 same
http://spample.iecc.com/vcw/14393557 !!! from 1 subj 2 same
http://spample.iecc.com/gkj/14393579 !!! from 1 subj 2 same
http://spample.iecc.com/vef/14409312 !!! from 1 subj 2 same
http://spample.iecc.com/xus/14410639 !!! from 1 subj 2 same
http://spample.iecc.com/vta/14466945 !!! from 2 subj 1
http://spample.iecc.com/tvf/14477920 !!! from 1 subj 2 same
http://spample.iecc.com/nbq/14512851 !!! from 2 subj 1
http://spample.iecc.com/wbt/14514852 !!! from 977 subj 1
http://spample.iecc.com/muf/14519415 !!! from 385 subj 1
http://spample.iecc.com/thg/14542167 !!! from 2 subj 1
http://spample.iecc.com/scg/14542263 !!! from 2 subj 1
http://spample.iecc.com/bia/14572469 !!! from 1 subj 2 same
http://spample.iecc.com/hwd/14574906 !!! from 1 subj 2 same
http://spample.iecc.com/eeu/14595557 !!! from 2 subj 1
http://spample.iecc.com/wsf/14601350 !!! from 2 subj 1
http://spample.iecc.com/kyr/14602820 !!! from 2 subj 1
http://spample.iecc.com/hsg/14607445 !!! from 2 subj 1
http://spample.iecc.com/pva/14609226 !!! from 2 subj 1
http://spample.iecc.com/mur/14632131 !!! from 1 subj 2 same
http://spample.iecc.com/mua/14644824 !!! from 2 subj 1
http://spample.iecc.com/ych/14661976 !!! from 2 subj 1
http://spample.iecc.com/fuf/14689113 !!! from 1 subj 2 same
http://spample.iecc.com/dsd/14723463 !!! from 1 subj 2 same
http://spample.iecc.com/knx/14728696 !!! from 1 subj 2 same
http://spample.iecc.com/mux/14728748 !!! from 1 subj 2 same
http://spample.iecc.com/djd/14728829 !!! from 1 subj 2 same
http://spample.iecc.com/epb/14728832 !!! from 1 subj 2 same
http://spample.iecc.com/jdy/14740113 !!! from 1 subj 2 same
http://spample.iecc.com/mxi/14750851 !!! from 2 subj 1
http://spample.iecc.com/qbm/14754069 !!! from 1 subj 2 same
http://spample.iecc.com/yhz/14763567 !!! from 2 subj 1
http://spample.iecc.com/voc/14768732 !!! from 2 subj 1
http://spample.iecc.com/sal/14778601 !!! from 1 subj 2 same
http://spample.iecc.com/snw/14800456 !!! from 2 subj 1
http://spample.iecc.com/kzw/14805611 !!! from 2 subj 1
http://spample.iecc.com/kta/14837567 !!! from 1 subj 2 same
http://spample.iecc.com/cuw/14844705 !!! from 2 subj 1
http://spample.iecc.com/cwf/14844706 !!! from 2 subj 1
http://spample.iecc.com/paf/14884768 !!! from 1 subj 2 same
http://spample.iecc.com/qcz/14884769 !!! from 1 subj 2 same
http://spample.iecc.com/fpk/14887273 !!! from 1 subj 2 same
http://spample.iecc.com/eoz/14893324 !!! from 2 subj 1
http://spample.iecc.com/aas/14935218 !!! from 1 subj 2 same
http://spample.iecc.com/wcs/14935821 !!! from 2 subj 1
http://spample.iecc.com/dbf/14943578 !!! from 1 subj 2 same
http://spample.iecc.com/ndo/14949600 !!! from 1 subj 2 same
http://spample.iecc.com/ovs/14949602 !!! from 1 subj 2 same
http://spample.iecc.com/czc/14952912 !!! from 1 subj 2 same
http://spample.iecc.com/rhh/14953432 !!! from 1 subj 2 same
http://spample.iecc.com/ldl/14958076 !!! from 1 subj 2 same
http://spample.iecc.com/jxq/14966868 !!! from 2 subj 1
http://spample.iecc.com/lhv/14986477 !!! from 1 subj 2 same
http://spample.iecc.com/mpl/14991157 !!! from 1 subj 2 same
http://spample.iecc.com/cbo/14991384 !!! from 1 subj 2 same
http://spample.iecc.com/yej/14992723 !!! from 2 subj 1
http://spample.iecc.com/wkl/15001907 !!! from 1 subj 2 same
http://spample.iecc.com/cmf/15004099 !!! from 1 subj 2 same
http://spample.iecc.com/zze/15009095 !!! from 1 subj 2 same
http://spample.iecc.com/xas/15015264 !!! from 2 subj 1
http://spample.iecc.com/prm/15019562 !!! from 2 subj 1
http://spample.iecc.com/fsi/15019593 !!! from 2 subj 1
http://spample.iecc.com/daq/15025544 !!! from 1 subj 2 same
http://spample.iecc.com/rku/15048970 !!! from 2 subj 1
http://spample.iecc.com/nsj/15049060 !!! from 2 subj 1
http://spample.iecc.com/alx/15061338 !!! from 2 subj 1
http://spample.iecc.com/zli/15063713 !!! from 1 subj 2 same
http://spample.iecc.com/znd/15063714 !!! from 1 subj 2 same
http://spample.iecc.com/qov/15066145 !!! from 1 subj 2 same
http://spample.iecc.com/udc/15066692 !!! from 1 subj 2 same
http://spample.iecc.com/uku/15068432 !!! from 1 subj 2 same
http://spample.iecc.com/wpt/15069515 !!! from 1 subj 2 same
http://spample.iecc.com/ssl/15073745 !!! from 1 subj 2 same
http://spample.iecc.com/agv/15078171 !!! from 1 subj 2 same
http://spample.iecc.com/shz/15124540 !!! from 1 subj 2 same
http://spample.iecc.com/hag/15135032 !!! from 1 subj 2 same
http://spample.iecc.com/eni/15142133 !!! from 1 subj 2 same
http://spample.iecc.com/stl/15158137 !!! from 1 subj 2 same
http://spample.iecc.com/rnh/15161025 !!! from 1 subj 2 same
http://spample.iecc.com/mzm/15208872 !!! from 1 subj 2 same
http://spample.iecc.com/xwk/15209503 !!! from 1 subj 2 same
http://spample.iecc.com/eyp/15209565 !!! from 1 subj 2 same
http://spample.iecc.com/mpq/15210807 !!! from 1 subj 2 same
http://spample.iecc.com/hyf/15223123 !!! from 1 subj 2 same
http://spample.iecc.com/jgm/15223127 !!! from 1 subj 2 same
http://spample.iecc.com/cdi/15226495 !!! from 2 subj 1
http://spample.iecc.com/koh/15231214 !!! from 1 subj 2 same
http://spample.iecc.com/vwf/15243904 !!! from 1 subj 2 same
http://spample.iecc.com/wyg/15247238 !!! from 2 subj 1
http://spample.iecc.com/gfn/15258577 !!! from 1 subj 2 same
http://spample.iecc.com/pix/15276507 !!! from 1 subj 2 same
http://spample.iecc.com/yle/15281449 !!! from 1 subj 2 same
http://spample.iecc.com/akt/15297234 !!! from 1 subj 2 same
http://spample.iecc.com/kos/15299041 !!! from 1 subj 2 same
http://spample.iecc.com/gag/15299230 !!! from 1 subj 2 same
http://spample.iecc.com/aep/15304878 !!! from 1 subj 2 same
http://spample.iecc.com/fds/15307019 !!! from 1 subj 2 same
http://spample.iecc.com/ufa/15308739 !!! from 1 subj 2 same
http://spample.iecc.com/qnw/15309025 !!! from 2 subj 1
http://spample.iecc.com/zhw/15338495 !!! from 1 subj 2 same
http://spample.iecc.com/lcn/15361699 !!! from 1 subj 2 same
http://spample.iecc.com/weo/15368973 !!! from 1 subj 2 same
http://spample.iecc.com/fqu/15387858 !!! from 2 subj 1
http://spample.iecc.com/ttm/15432135 !!! from 1 subj 2 same
http://spample.iecc.com/hpo/15444709 !!! from 1 subj 2 same
http://spample.iecc.com/etw/15463621 !!! from 1 subj 2 same
http://spample.iecc.com/khr/15468752 !!! from 2 subj 1
http://spample.iecc.com/tfs/15469506 !!! from 2 subj 1
http://spample.iecc.com/plw/15479151 !!! from 1 subj 2 same
http://spample.iecc.com/ncw/15485984 !!! from 1 subj 2 same
http://spample.iecc.com/rfn/15486090 !!! from 2 subj 1
http://spample.iecc.com/khz/15491001 !!! from 1 subj 2 same
http://spample.iecc.com/qyy/15493096 !!! from 1 subj 2 same
http://spample.iecc.com/yyr/15504873 !!! from 1 subj 2 same
http://spample.iecc.com/drz/15507380 !!! from 1 subj 2 same
http://spample.iecc.com/qmf/15511766 !!! from 1 subj 2 same
http://spample.iecc.com/mgz/15532367 !!! from 1 subj 2 same
http://spample.iecc.com/oog/15532371 !!! from 1 subj 2 same
http://spample.iecc.com/llu/15539667 !!! from 2 subj 1
http://spample.iecc.com/yfj/15566891 !!! from 2 subj 1
http://spample.iecc.com/qow/15572830 !!! from 2 subj 1
http://spample.iecc.com/qfn/15590668 !!! from 1 subj 2 same
http://spample.iecc.com/rgc/15595965 !!! from 136 subj 1
http://spample.iecc.com/sxr/15598956 !!! from 385 subj 1
http://spample.iecc.com/rjk/15601084 !!! from 1 subj 2 same
http://spample.iecc.com/jwi/15602809 !!! from 1 subj 2 same
http://spample.iecc.com/fbc/15603707 !!! from 1 subj 2 same
http://spample.iecc.com/imx/15604007 !!! from 1 subj 2 same
http://spample.iecc.com/gec/15604494 !!! from 1 subj 2 same
http://spample.iecc.com/vji/15605307 !!! from 1 subj 2 same
http://spample.iecc.com/ymy/15607297 !!! from 1 subj 2 same
http://spample.iecc.com/pny/15608040 !!! from 2 subj 1
http://spample.iecc.com/qph/15608041 !!! from 2 subj 1
http://spample.iecc.com/dbo/15611889 !!! from 1 subj 2 same
http://spample.iecc.com/igc/15615426 !!! from 1 subj 2 same
http://spample.iecc.com/gcu/15626546 !!! from 1 subj 2 same
http://spample.iecc.com/ewu/15627525 !!! from 264 subj 1
http://spample.iecc.com/ash/15627566 !!! from 707 subj 1
http://spample.iecc.com/ubu/15628460 !!! from 2 subj 2 same
http://spample.iecc.com/vdo/15628461 !!! from 2 subj 2 same
http://spample.iecc.com/wny/15630203 !!! from 2271 subj 1
http://spample.iecc.com/vpc/15632530 !!! from 1 subj 2 same
http://spample.iecc.com/wrk/15632531 !!! from 1 subj 2 same
http://spample.iecc.com/zdd/15635820 !!! from 1 subj 2 same
http://spample.iecc.com/qtf/15645973 !!! from 1 subj 2 same
http://spample.iecc.com/rqj/15647960 !!! from 2 subj 1
http://spample.iecc.com/zsz/15655228 !!! from 2 subj 1
http://spample.iecc.com/azp/15657558 !!! from 2 subj 1
http://spample.iecc.com/ddj/15698485 !!! from 2 subj 1
http://spample.iecc.com/wao/15698717 !!! from 2 subj 1
http://spample.iecc.com/ppw/15700491 !!! from 1 subj 2 same
http://spample.iecc.com/ahh/15700708 !!! from 1 subj 2 same
http://spample.iecc.com/zlc/15711929 !!! from 1 subj 2 same
http://spample.iecc.com/ank/15711930 !!! from 1 subj 2 same
http://spample.iecc.com/hhe/15714665 !!! from 1 subj 2 same
http://spample.iecc.com/sln/15730440 !!! from 1 subj 2 same
http://spample.iecc.com/bau/15735873 !!! from 1 subj 2 same
http://spample.iecc.com/hvy/15735883 !!! from 1 subj 2 same
http://spample.iecc.com/mak/15740010 !!! from 2 subj 1
http://spample.iecc.com/yfj/15748022 !!! from 1 subj 2 same
http://spample.iecc.com/zhe/15748023 !!! from 1 subj 2 same
http://spample.iecc.com/ajc/15765399 !!! from 1 subj 2 same
http://spample.iecc.com/pym/15820656 !!! from 1 subj 2 same
http://spample.iecc.com/jzv/15831600 !!! from 1 subj 2 same
http://spample.iecc.com/djs/15831905 !!! from 2 subj 1
http://spample.iecc.com/ywo/15839786 !!! from 1 subj 2 same
http://spample.iecc.com/meu/15851967 !!! from 1 subj 2 same
http://spample.iecc.com/xuc/15871762 !!! from 1 subj 2 same
http://spample.iecc.com/ovg/15873217 !!! from 1 subj 2 same
http://spample.iecc.com/xhc/15885019 !!! from 1 subj 2 same
http://spample.iecc.com/vki/15885407 !!! from 1 subj 2 same
http://spample.iecc.com/ovg/15885443 !!! from 1 subj 2 same
http://spample.iecc.com/vkf/15886340 !!! from 1 subj 2 same
http://spample.iecc.com/wma/15886341 !!! from 1 subj 2 same
http://spample.iecc.com/dtx/15887112 !!! from 1 subj 2 same
http://spample.iecc.com/frc/15896354 !!! from 1 subj 2 same
http://spample.iecc.com/iiq/15898295 !!! from 1 subj 2 same
http://spample.iecc.com/zyd/15898720 !!! from 1 subj 2 same
http://spample.iecc.com/ehj/15904879 !!! from 1 subj 2 same
http://spample.iecc.com/jgb/15919100 !!! from 1 subj 2 same
http://spample.iecc.com/jjk/15919101 !!! from 1 subj 2 same
http://spample.iecc.com/gug/15920322 !!! from 1 subj 2 same
http://spample.iecc.com/kkv/15923269 !!! from 2 subj 1
http://spample.iecc.com/cvo/15924551 !!! from 1 subj 2 same
http://spample.iecc.com/wgu/15926011 !!! from 1 subj 2 same
http://spample.iecc.com/tgy/15945338 !!! from 2 subj 1
http://spample.iecc.com/vkl/15975433 !!! from 1 subj 2 same
http://spample.iecc.com/fpr/15978467 !!! from 1 subj 2 same
http://spample.iecc.com/gsa/15978468 !!! from 1 subj 2 same
http://spample.iecc.com/nhn/15979022 !!! from 1 subj 2 same
http://spample.iecc.com/lof/15983745 !!! from 1 subj 2 same
http://spample.iecc.com/rma/15986647 !!! from 2 subj 1
http://spample.iecc.com/mui/15999675 !!! from 1 subj 2 same
http://spample.iecc.com/tfx/16026813 !!! from 2 subj 1
http://spample.iecc.com/hwp/16026938 !!! from 2 subj 1
http://spample.iecc.com/nem/16027095 !!! from 1 subj 2 same
http://spample.iecc.com/tnr/16027793 !!! from 2 subj 1
http://spample.iecc.com/udd/16028040 !!! from 2 subj 1
http://spample.iecc.com/wxs/16028215 !!! from 1 subj 2 same
http://spample.iecc.com/ogz/16030429 !!! from 2 subj 1
http://spample.iecc.com/rlq/16036145 !!! from 1 subj 2 same
http://spample.iecc.com/ymg/16036158 !!! from 1 subj 2 same
http://spample.iecc.com/yyl/16037336 !!! from 1 subj 2 same
http://spample.iecc.com/wbw/16050687 !!! from 1 subj 2 same
http://spample.iecc.com/mya/16052674 !!! from 2 subj 1
http://spample.iecc.com/gbu/16054038 !!! from 1 subj 2 same
http://spample.iecc.com/uyv/16055362 !!! from 1 subj 2 same
http://spample.iecc.com/inf/16055486 !!! from 1 subj 2 same
http://spample.iecc.com/wbe/16062127 !!! from 1 subj 2 same
http://spample.iecc.com/ejq/16071724 !!! from 1 subj 2 same
http://spample.iecc.com/keu/16072225 !!! from 2 subj 1
http://spample.iecc.com/rvt/16072239 !!! from 1 subj 2 same
http://spample.iecc.com/hwx/16078273 !!! from 1 subj 2 same
http://spample.iecc.com/iys/16078274 !!! from 1 subj 2 same
http://spample.iecc.com/pxn/16088922 !!! from 1 subj 2 same
http://spample.iecc.com/yxl/16094354 !!! from 1 subj 2 same
http://spample.iecc.com/yzg/16094355 !!! from 1 subj 2 same
http://spample.iecc.com/tbi/16098462 !!! from 1 subj 2 same
http://spample.iecc.com/ydi/16102881 !!! from 1 subj 2 same
http://spample.iecc.com/rik/16140801 !!! from 1 subj 2 same
http://spample.iecc.com/nyy/16141404 !!! from 1 subj 2 same
http://spample.iecc.com/oco/16145009 !!! from 1 subj 2 same
http://spample.iecc.com/rji/16171944 !!! from 1 subj 2 same
http://spample.iecc.com/xms/16183030 !!! from 1 subj 2 same
http://spample.iecc.com/qwd/16193088 !!! from 1 subj 2 same
http://spample.iecc.com/utx/16195376 !!! from 1 subj 2 same
http://spample.iecc.com/xos/16202535 !!! from 1 subj 2 same
http://spample.iecc.com/uaw/16206647 !!! from 1 subj 2 same
http://spample.iecc.com/zhz/16215108 !!! from 1 subj 2 same
http://spample.iecc.com/jlj/16215128 !!! from 1 subj 2 same
http://spample.iecc.com/bqs/16215603 !!! from 2 subj 1
http://spample.iecc.com/yde/16216530 !!! from 1 subj 2 same
http://spample.iecc.com/rhd/16230237 !!! from 2 subj 1
http://spample.iecc.com/wcw/16230296 !!! from 2 subj 1
http://spample.iecc.com/kex/16230518 !!! from 1 subj 2 same
http://spample.iecc.com/eal/16235604 !!! from 1 subj 2 same
http://spample.iecc.com/srz/16238521 !!! from 1 subj 2 same
http://spample.iecc.com/sda/16242099 !!! from 2 subj 1
http://spample.iecc.com/jgz/16245513 !!! from 1 subj 2 same
http://spample.iecc.com/ngr/16246894 !!! from 1 subj 2 same
http://spample.iecc.com/drf/16246973 !!! from 1 subj 2 same
http://spample.iecc.com/geq/16246979 !!! from 1 subj 2 same
http://spample.iecc.com/aif/16258851 !!! from 1 subj 2 same
http://spample.iecc.com/neq/16260003 !!! from 1 subj 2 same
http://spample.iecc.com/czr/16262775 !!! from 1 subj 2 same
http://spample.iecc.com/ofr/16267258 !!! from 1 subj 2 same
http://spample.iecc.com/ioi/16268447 !!! from 2 subj 1
http://spample.iecc.com/tkq/16270403 !!! from 2 subj 1
http://spample.iecc.com/iba/16290990 !!! from 1 subj 2 same
http://spample.iecc.com/yys/16294696 !!! from 1 subj 2 same
http://spample.iecc.com/zan/16294697 !!! from 1 subj 2 same
http://spample.iecc.com/hzo/16296501 !!! from 1 subj 2 same
http://spample.iecc.com/tfx/16297308 !!! from 2 subj 1
http://spample.iecc.com/wpe/16300988 !!! from 1 subj 2 same
http://spample.iecc.com/ats/16300996 !!! from 1 subj 2 same
http://spample.iecc.com/xgt/16303979 !!! from 1 subj 2 same
http://spample.iecc.com/xqz/16321844 !!! from 1 subj 2 same
http://spample.iecc.com/sdn/16339060 !!! from 1 subj 2 same
http://spample.iecc.com/sfw/16339061 !!! from 1 subj 2 same
http://spample.iecc.com/sjy/16340947 !!! from 1 subj 2 same
http://spample.iecc.com/npj/16343681 !!! from 1 subj 2 same
http://spample.iecc.com/qbe/16344129 !!! from 1 subj 2 same
http://spample.iecc.com/uwe/16348963 !!! from 2 subj 1
http://spample.iecc.com/saq/16349155 !!! from 1 subj 2 same
http://spample.iecc.com/nrh/16349390 !!! from 1 subj 2 same
http://spample.iecc.com/knj/16358257 !!! from 1 subj 2 same
http://spample.iecc.com/zhh/16369971 !!! from 2 subj 1
http://spample.iecc.com/ckk/16375539 !!! from 1 subj 2 same
http://spample.iecc.com/lfk/16389254 !!! from 1 subj 2 same
http://spample.iecc.com/mjo/16389256 !!! from 1 subj 2 same
http://spample.iecc.com/ddc/16392058 !!! from 1 subj 2 same
http://spample.iecc.com/ots/16398498 !!! from 2 subj 1
http://spample.iecc.com/ovn/16398499 !!! from 2 subj 1
http://spample.iecc.com/hwu/16401647 !!! from 1 subj 2 same
http://spample.iecc.com/vps/16409684 !!! from 2 subj 1
http://spample.iecc.com/xyk/16410130 !!! from 1 subj 2 same
http://spample.iecc.com/pfe/16410164 !!! from 2 subj 1
http://spample.iecc.com/dfw/16410385 !!! from 2 subj 1
http://spample.iecc.com/tpl/16421100 !!! from 1 subj 2 same
http://spample.iecc.com/jfv/16439189 !!! from 1 subj 2 same
http://spample.iecc.com/chr/16441430 !!! from 1 subj 2 same
http://spample.iecc.com/fvt/16444303 !!! from 1 subj 2 same
http://spample.iecc.com/hyz/16445851 !!! from 1 subj 2 same
http://spample.iecc.com/lpd/16448529 !!! from 1 subj 2 same
http://spample.iecc.com/wqb/16448916 !!! from 1 subj 2 same
http://spample.iecc.com/mue/16450980 !!! from 1 subj 2 same
http://spample.iecc.com/elq/16451504 !!! from 1 subj 2 same
http://spample.iecc.com/djo/16451699 !!! from 1 subj 2 same
http://spample.iecc.com/qhm/16455497 !!! from 1 subj 2 same
http://spample.iecc.com/vsv/16461020 !!! from 2 subj 1
http://spample.iecc.com/boo/16461227 !!! from 1 subj 2 same
http://spample.iecc.com/bqx/16461228 !!! from 1 subj 2 same
http://spample.iecc.com/org/16466814 !!! from 2 subj 1
http://spample.iecc.com/wfx/16474965 !!! from 1 subj 2 same
http://spample.iecc.com/whf/16474966 !!! from 1 subj 2 same
http://spample.iecc.com/cav/16478848 !!! from 1 subj 2 same
http://spample.iecc.com/exc/16478852 !!! from 1 subj 2 same
http://spample.iecc.com/uft/16479298 !!! from 1 subj 2 same
http://spample.iecc.com/vvf/16479545 !!! from 1 subj 2 same
http://spample.iecc.com/wxa/16479546 !!! from 1 subj 2 same
http://spample.iecc.com/zpj/16485017 !!! from 1 subj 2 same
http://spample.iecc.com/ylm/16488323 !!! from 1 subj 2 same
http://spample.iecc.com/zbr/16491903 !!! from 1 subj 2 same
http://spample.iecc.com/dne/16492964 !!! from 1 subj 2 same
http://spample.iecc.com/oxh/16494233 !!! from 1 subj 2 same
http://spample.iecc.com/tat/16495223 !!! from 1 subj 2 same
http://spample.iecc.com/sec/16496962 !!! from 1 subj 2 same
http://spample.iecc.com/thl/16496963 !!! from 1 subj 2 same
http://spample.iecc.com/mlq/16518145 !!! from 1 subj 2 same
http://spample.iecc.com/ztr/16519861 !!! from 1 subj 2 same
http://spample.iecc.com/aoi/16528267 !!! from 1 subj 2 same
http://spample.iecc.com/bqd/16528268 !!! from 1 subj 2 same
http://spample.iecc.com/vai/16533600 !!! from 1 subj 2 same
http://spample.iecc.com/uju/16536833 !!! from 1 subj 2 same
http://spample.iecc.com/xsp/16537377 !!! from 2 subj 1
http://spample.iecc.com/ydb/16541372 !!! from 1 subj 2 same
http://spample.iecc.com/dzg/16548563 !!! from 1 subj 2 same
http://spample.iecc.com/oow/16551817 !!! from 1 subj 2 same
http://spample.iecc.com/cca/16552137 !!! from 1 subj 2 same
http://spample.iecc.com/uyo/16555161 !!! from 1 subj 2 same
http://spample.iecc.com/dnh/16557899 !!! from 1 subj 2 same
http://spample.iecc.com/gwv/16558247 !!! from 1 subj 2 same
http://spample.iecc.com/qew/16558828 !!! from 1 subj 2 same
http://spample.iecc.com/eok/16570862 !!! from 2 subj 1
http://spample.iecc.com/pka/16575709 !!! from 1 subj 2 same
http://spample.iecc.com/pmj/16575710 !!! from 1 subj 2 same
http://spample.iecc.com/ges/16578069 !!! from 1 subj 2 same
http://spample.iecc.com/iku/16595644 !!! from 1 subj 2 same
http://spample.iecc.com/uak/16596425 !!! from 1 subj 2 same
http://spample.iecc.com/psu/16596464 !!! from 1 subj 2 same
http://spample.iecc.com/mgh/16597440 !!! from 1 subj 2 same
http://spample.iecc.com/yuw/16599644 !!! from 1 subj 2 same
http://spample.iecc.com/sih/16609114 !!! from 1 subj 2 same
http://spample.iecc.com/xpj/16611916 !!! from 2 subj 1
http://spample.iecc.com/epf/16612125 !!! from 1 subj 2 same
http://spample.iecc.com/nxo/16622630 !!! from 1 subj 2 same
http://spample.iecc.com/upf/16624480 !!! from 1 subj 2 same
http://spample.iecc.com/wko/16625416 !!! from 2 subj 1
http://spample.iecc.com/tfl/16626316 !!! from 1 subj 2 same
http://spample.iecc.com/jsi/16626396 !!! from 1 subj 2 same
http://spample.iecc.com/yal/16629683 !!! from 1 subj 2 same
http://spample.iecc.com/wan/16634311 !!! from 1 subj 2 same
http://spample.iecc.com/wkl/16634506 !!! from 1 subj 2 same
http://spample.iecc.com/ehx/16640722 !!! from 1 subj 2 same
http://spample.iecc.com/swr/16643246 !!! from 1 subj 2 same
http://spample.iecc.com/gme/16643468 !!! from 1 subj 2 same
http://spample.iecc.com/oui/16643533 !!! from 1 subj 2 same
http://spample.iecc.com/tbi/16643788 !!! from 1 subj 2 same
http://spample.iecc.com/kiu/16645510 !!! from 2 subj 1
http://spample.iecc.com/kcy/16647201 !!! from 1 subj 2 same
http://spample.iecc.com/uxe/16656141 !!! from 2 subj 1
http://spample.iecc.com/tzs/16657339 !!! from 1 subj 2 same
http://spample.iecc.com/sgd/16657729 !!! from 1 subj 2 same
http://spample.iecc.com/wii/16657736 !!! from 1 subj 2 same
http://spample.iecc.com/dyk/16657848 !!! from 1 subj 2 same
http://spample.iecc.com/ect/16657997 !!! from 1 subj 2 same
http://spample.iecc.com/xcd/16658132 !!! from 1 subj 2 same
http://spample.iecc.com/vfs/16660920 !!! from 1 subj 2 same
http://spample.iecc.com/eio/16662333 !!! from 2 subj 1
http://spample.iecc.com/swz/16663537 !!! from 2 subj 1
http://spample.iecc.com/tyh/16663538 !!! from 2 subj 1
http://spample.iecc.com/cxc/16669681 !!! from 1 subj 2 same
http://spample.iecc.com/dzk/16669682 !!! from 1 subj 2 same
http://spample.iecc.com/iuj/16673000 !!! from 2 subj 1
http://spample.iecc.com/vde/16674520 !!! from 1 subj 2 same
http://spample.iecc.com/qqk/16695560 !!! from 1 subj 2 same
http://spample.iecc.com/czf/16698473 !!! from 1 subj 2 same
http://spample.iecc.com/mla/16701725 !!! from 2 subj 1
http://spample.iecc.com/nqe/16701727 !!! from 2 subj 1
http://spample.iecc.com/lkq/16704247 !!! from 1 subj 2 same
http://spample.iecc.com/oiu/16705332 !!! from 1 subj 2 same
http://spample.iecc.com/rfr/16708768 !!! from 1 subj 2 same
http://spample.iecc.com/iaa/16710883 !!! from 1 subj 2 same
http://spample.iecc.com/ehl/16711144 !!! from 1 subj 2 same
http://spample.iecc.com/ise/16711935 !!! from 2 subj 1
http://spample.iecc.com/eee/16712223 !!! from 1 subj 2 same
http://spample.iecc.com/hnh/16715658 !!! from 1 subj 2 same
http://spample.iecc.com/kbr/16715812 !!! from 1 subj 2 same
http://spample.iecc.com/adt/16717679 !!! from 1 subj 2 same
http://spample.iecc.com/uoo/16722226 !!! from 1 subj 2 same
http://spample.iecc.com/fve/16722346 !!! from 1 subj 2 same
http://spample.iecc.com/tvl/16722542 !!! from 3 subj 1
http://spample.iecc.com/zqf/16722601 !!! from 1 subj 2 same
http://spample.iecc.com/mqv/16722773 !!! from 1 subj 2 same
http://spample.iecc.com/cda/16723049 !!! from 1 subj 2 same
http://spample.iecc.com/hgq/16730753 !!! from 1 subj 2 same
http://spample.iecc.com/vwn/16731025 !!! from 1 subj 2 same
http://spample.iecc.com/xfu/16731029 !!! from 1 subj 2 same
http://spample.iecc.com/xbs/16734605 !!! from 1 subj 2 same
http://spample.iecc.com/xsx/16736737 !!! from 1 subj 2 same
http://spample.iecc.com/bli/16755122 !!! from 1 subj 2 same
http://spample.iecc.com/sic/16763486 !!! from 1 subj 2 same
http://spample.iecc.com/edx/16767430 !!! from 1 subj 2 same
http://spample.iecc.com/nzy/16767545 !!! from 1 subj 2 same
http://spample.iecc.com/qkz/16767550 !!! from 1 subj 2 same
http://spample.iecc.com/lzh/16767809 !!! from 1 subj 2 same
http://spample.iecc.com/zkp/16777149 !!! from 2 subj 1
http://spample.iecc.com/vjm/16785496 !!! from 1 subj 2 same
http://spample.iecc.com/gvn/16787404 !!! from 1 subj 2 same
http://spample.iecc.com/ptp/16792786 !!! from 1 subj 2 same
http://spample.iecc.com/ugy/16811173 !!! from 1 subj 2 same
http://spample.iecc.com/cbv/16813123 !!! from 1 subj 2 same
http://spample.iecc.com/ixl/16814115 !!! from 2 subj 1
http://spample.iecc.com/qvk/16819251 !!! from 1 subj 2 same
http://spample.iecc.com/qxf/16819252 !!! from 1 subj 2 same
http://spample.iecc.com/bes/16828462 !!! from 1 subj 2 same
http://spample.iecc.com/cgn/16828463 !!! from 1 subj 2 same
http://spample.iecc.com/jnn/16853790 !!! from 2 subj 1
http://spample.iecc.com/nvs/16864381 !!! from 2 subj 1
http://spample.iecc.com/spk/16864783 !!! from 2 subj 1
http://spample.iecc.com/cvv/16938142 !!! from 2 subj 1
http://spample.iecc.com/zxb/16950633 !!! from 2 subj 1
http://spample.iecc.com/qdh/16962696 !!! from 2 subj 1
http://spample.iecc.com/mme/16989104 !!! from 2 subj 1
http://spample.iecc.com/axq/16993590 !!! from 2 subj 1
http://spample.iecc.com/emn/17013175 !!! from 1 subj 2 same
http://spample.iecc.com/unz/17026095 !!! from 1 subj 2 same
http://spample.iecc.com/dse/17033659 !!! from 2 subj 1
http://spample.iecc.com/qnh/17033853 !!! from 2 subj 1
http://spample.iecc.com/ytb/17033868 !!! from 2 subj 1
http://spample.iecc.com/ftz/17037655 !!! from 1 subj 2 same
http://spample.iecc.com/sgo/17041356 !!! from 1 subj 2 same
http://spample.iecc.com/bau/17054727 !!! from 2 subj 1
http://spample.iecc.com/ync/17062049 !!! from 1 subj 2 same
http://spample.iecc.com/rie/17062501 !!! from 1 subj 2 same
http://spample.iecc.com/egb/17063261 !!! from 1 subj 2 same
http://spample.iecc.com/alr/17083567 !!! from 1 subj 2 same
http://spample.iecc.com/ifh/17089585 !!! from 1 subj 2 same
http://spample.iecc.com/box/17093689 !!! from 1 subj 2 same
http://spample.iecc.com/bld/17123779 !!! from 2 subj 1
http://spample.iecc.com/fup/17131333 !!! from 2 subj 1
http://spample.iecc.com/pdx/17184231 !!! from 2 subj 1
http://spample.iecc.com/ifb/17192966 !!! from 1 subj 2 same
http://spample.iecc.com/qmx/17234440 !!! from 2 subj 1
http://spample.iecc.com/txy/17234445 !!! from 2 subj 1
http://spample.iecc.com/qgg/17246154 !!! from 2 subj 1
http://spample.iecc.com/vma/17246457 !!! from 2 subj 1
http://spample.iecc.com/kti/17253003 !!! from 2 subj 1
http://spample.iecc.com/lbj/17264472 !!! from 1 subj 2 same
http://spample.iecc.com/bak/17264502 !!! from 2 subj 1
http://spample.iecc.com/uzw/17270296 !!! from 2 subj 1
http://spample.iecc.com/ijc/17276475 !!! from 2 subj 1
http://spample.iecc.com/xzh/17280521 !!! from 2 subj 1
http://spample.iecc.com/wcv/17282259 !!! from 2 subj 1
http://spample.iecc.com/eqt/17283082 !!! from 2 subj 1
http://spample.iecc.com/kjx/17303798 !!! from 2 subj 1
http://spample.iecc.com/gyt/17356767 !!! from 2 subj 1
http://spample.iecc.com/mej/17368787 !!! from 2 subj 1
http://spample.iecc.com/jrn/17371868 !!! from 2 subj 1
http://spample.iecc.com/guf/17384507 !!! from 2 subj 1
http://spample.iecc.com/qds/17404936 !!! from 1 subj 2 same
http://spample.iecc.com/lnc/17410489 !!! from 2 subj 1
http://spample.iecc.com/xjl/17410561 !!! from 2 subj 1
http://spample.iecc.com/rzb/17410599 !!! from 2 subj 1
http://spample.iecc.com/njb/17432153 !!! from 2 subj 1
http://spample.iecc.com/kzs/17435604 !!! from 2 subj 1
http://spample.iecc.com/qsj/17435883 !!! from 2 subj 1
http://spample.iecc.com/poz/17471878 !!! from 2 subj 1
http://spample.iecc.com/qqi/17471879 !!! from 2 subj 1
http://spample.iecc.com/tuh/17619740 !!! from 1 subj 2 same
http://spample.iecc.com/dnw/17675773 !!! from 2 subj 1
http://spample.iecc.com/jnc/17711536 !!! from 2 subj 1
http://spample.iecc.com/rca/17716502 !!! from 2 subj 1
http://spample.iecc.com/ifz/17718885 !!! from 2 subj 1
http://spample.iecc.com/wvt/17718911 !!! from 2 subj 1
http://spample.iecc.com/kbe/17754027 !!! from 2 subj 1
http://spample.iecc.com/hou/17767278 !!! from 2 subj 1
http://spample.iecc.com/uue/17814030 !!! from 2 subj 1
http://spample.iecc.com/xgo/17814036 !!! from 2 subj 1
http://spample.iecc.com/lxl/17814848 !!! from 1 subj 2 same
http://spample.iecc.com/dbk/17815150 !!! from 2 subj 1
http://spample.iecc.com/mfy/17842514 !!! from 2 subj 1
http://spample.iecc.com/nyy/17848028 !!! from 2 subj 1
http://spample.iecc.com/vax/17881123 !!! from 2 subj 1
http://spample.iecc.com/web/17881125 !!! from 2 subj 1
http://spample.iecc.com/afh/17904067 !!! from 2 subj 1
http://spample.iecc.com/zre/17926266 !!! from 2 subj 1
http://spample.iecc.com/lar/17926436 !!! from 2 subj 1
http://spample.iecc.com/hrf/17988888 !!! from 2 subj 1
http://spample.iecc.com/sin/18001723 !!! from 2 subj 1
http://spample.iecc.com/bvj/18027347 !!! from 1 subj 2 same
http://spample.iecc.com/czn/18027349 !!! from 1 subj 2 same
http://spample.iecc.com/yyh/18085048 !!! from 1 subj 2 same
http://spample.iecc.com/puw/18199757 !!! from 2 subj 1
http://spample.iecc.com/sre/18212822 !!! from 2 subj 1
http://spample.iecc.com/jtm/18261813 !!! from 2 subj 1
http://spample.iecc.com/mrq/18297177 !!! from 2 subj 1
http://spample.iecc.com/mwv/18334912 !!! from 2 subj 1
http://spample.iecc.com/lcn/18380536 !!! from 2 subj 1
http://spample.iecc.com/jlx/18398370 !!! from 2 subj 1
http://spample.iecc.com/yng/18422877 !!! from 2 subj 1
http://spample.iecc.com/zdi/18469193 !!! from 2 subj 1
http://spample.iecc.com/olz/18504186 !!! from 2 subj 1
http://spample.iecc.com/kbw/18621550 !!! from 1 subj 2 same
http://spample.iecc.com/kdf/18621551 !!! from 1 subj 2 same
http://spample.iecc.com/inz/18714392 !!! from 1 subj 2 same
http://spample.iecc.com/jld/18754212 !!! from 2 subj 1
http://spample.iecc.com/knx/18754213 !!! from 2 subj 1
http://spample.iecc.com/omx/19055222 !!! from 1 subj 2 same
http://spample.iecc.com/qej/19181198 !!! from 1 subj 2 same
http://spample.iecc.com/hca/19199683 !!! from 1 subj 2 same
http://spample.iecc.com/cgp/19209621 !!! from 1 subj 2 same
http://spample.iecc.com/iha/19231318 !!! from 1 subj 2 same
http://spample.iecc.com/nrt/19253381 !!! from 1 subj 2 same
http://spample.iecc.com/pij/19357599 !!! from 1 subj 2 same
http://spample.iecc.com/kri/19366091 !!! from 1 subj 2 same
http://spample.iecc.com/don/19366323 !!! from 1 subj 2 same
http://spample.iecc.com/eev/19366324 !!! from 1 subj 2 same
http://spample.iecc.com/kqs/19366533 !!! from 1 subj 2 same
http://spample.iecc.com/gdd/19414675 !!! from 1 subj 2 same
http://spample.iecc.com/bti/19475555 !!! from 1 subj 2 same
http://spample.iecc.com/bvr/19475556 !!! from 1 subj 2 same
http://spample.iecc.com/oih/19475728 !!! from 1 subj 2 same
http://spample.iecc.com/qqo/19475732 !!! from 1 subj 2 same
http://spample.iecc.com/rvs/19475734 !!! from 1 subj 2 same
http://spample.iecc.com/tyx/19521656 !!! from 1 subj 2 same
http://spample.iecc.com/myc/19547078 !!! from 1 subj 2 same
http://spample.iecc.com/uba/19547092 !!! from 1 subj 2 same
http://spample.iecc.com/gxp/19547311 !!! from 1 subj 2 same
http://spample.iecc.com/cwg/19547746 !!! from 1 subj 2 same
http://spample.iecc.com/epd/19557379 !!! from 1 subj 2 same
http://spample.iecc.com/fbs/19587471 !!! from 1 subj 2 same
http://spample.iecc.com/msh/19709634 !!! from 1 subj 2 same
http://spample.iecc.com/pls/19863205 !!! from 1 subj 2 same
http://spample.iecc.com/xkp/19867949 !!! from 1 subj 2 same
http://spample.iecc.com/dgm/19936521 !!! from 1 subj 2 same
http://spample.iecc.com/dfd/20191825 !!! from 2 subj 1
http://spample.iecc.com/qrk/20230245 !!! from 2 subj 1
http://spample.iecc.com/rte/20230246 !!! from 2 subj 1
http://spample.iecc.com/zqq/20288435 !!! from 2 subj 1
http://spample.iecc.com/jcg/20427584 !!! from 1 subj 2 same
http://spample.iecc.com/wlq/20880239 !!! from 1 subj 2 same
http://spample.iecc.com/bmn/20955375 !!! from 2 subj 1
http://spample.iecc.com/rbr/21032322 !!! from 2 subj 1
http://spample.iecc.com/wzl/21177051 !!! from 2 subj 1
http://spample.iecc.com/vnu/21180992 !!! from 2 subj 1
http://spample.iecc.com/lhg/21256591 !!! from 2 subj 1
http://spample.iecc.com/gxr/21290325 !!! from 2 subj 1
http://spample.iecc.com/omo/21300286 !!! from 2 subj 1
http://spample.iecc.com/ozk/21945514 !!! from 1 subj 2 same
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 20 Oct 2010 22:31:45 +0200

> protocols - DKIH (Domain Keys Identified HTML as an example).

Yep. Or other protocols will use parts of DKIM. Like with MIME 
(Multipurpose Internet /Mail/ Extensions); it has been used by other 
protocols as well.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Oct 2010 17:20:47 -0400

John R. Levine wrote:
> SNIP

wow!  I definitely have to pencil in time this weekend to scan the 
archives (I think I have some as far as 1998) to see how pervasive was 
this issue.

Good show john.

---
HLS

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Oct 2010 14:20:27 -0700

> (Multipurpose Internet /Mail/ Extensions); it has been used by other

Ages ago I, just for grins and giggles, implemented DKIM on SIP messages
mainly so that I could say that DKIM-on-SIP had been implemented, while
SIP-Identity (rfc 4474) had not. For all I know, that's still the case :)

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 20 Oct 2010 18:03:32 -0400

> Validating mail syntax belongs in the specification for the mail 
> components and DKIM work belongs in the DKIM components.

Yes and no.

The problem for me is that in most situations only outgoing or relaying 
MSAs do format validation, and on incoming mail, some 5322 violations are 
considerably worse than others.  I've never seen a legit message with two 
>From or Subject headers, I've gotten plenty with a message-id with an 
extra at sign or a MIME-Type but no MIME-Version.  I can somewhat see 
inisisting on validating all of that before signing, to encourage people 
to clean up their sending software, but if you're that strict on 
verification, you're going to lose signatures on valid but sloppy mail.

That's why, layer violation or no, I think it's important to distinguish 
between format errors that are likely to lead to misleading rendering in 
existing MUAs, and the much larger class that may produce nonsense but 
won't produce lies.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Oct 2010 15:19:14 -0700

> Sent: Wednesday, October 20, 2010 3:04 PM
> To: Murray S. Kucherawy

I think we're close to converging here.

I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops.  But... Does it *have* to use RFC2119 normative language?

Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality?

I'm pushing for (b), while someone who insists the text be normative is pushing for (a).

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Oct 2010 15:38:24 -0700

On 10/20/10 10:55 AM, Murray S. Kucherawy wrote:

>  I think a lot of this discussion conflates protocol specification
>  with implementation. I'm focused on the former. I maintain that
>  including wording intimating that a DKIM implementation is
>  non-compliant if it fails to do mail format validation prior to
>  accepting input or returning a result causes the specification not
>  to be clean. It's a layering violation. It's sloppy design. It
>  shouldn't be done.

Disagree.  Since DKIM /REQUIRES/, at minimum, the From header field be 
signed, are you suggesting layer violations when DKIM's verification 
process checks for non-compliant multiple From header fields?   It would 
be negligent of DKIM not to return a result of PERMFAIL when multiple 
 From header fields are detected.  Clean layering of a verification 
process is /not/ achieved when consumers of DKIM results must re-examine 
messages that receive a PASS result.

RFC5322 Section 6.4 amends the compliance required by SMTP, and removes 
strict enforcement.  There is not even a clearly defined error code to 
report non-compliance.  Since no layer below DKIM assures RFC5322 
compliance, it is negligent for the DKIM verification process to skip 
checks for multiple From header fields.   DKIM extends trust based upon 
the signing domain to include the From header field, as a minimum.  
Since normally there is no advantage obtained by introducing multiple 
 From header fields without the additional trust established by DKIM, it 
becomes fully incumbent upon DKIM to check for illegal conditions that 
might lead to erroneous placement of  trust.   Failure in this regard is 
likely to result in trust related exploitations.

>  The difference may be as subtle as what you're talking about above.
>  For example, although I am arguing that RFC4871bis shouldn't contain
>  any kind of normative enforcement of other specifications, my own
>  open source implementation already does it and has almost since day
>  one. I think that's the right thing to do, not because RFC4871 told
>  me to, but because RFC5322 did. And as a result, it's in the part
>  of the code that deals with mail, not the part that deals with DKIM.

Disagree.  DKIM MUST detect conditions that would allow trust 
established by DKIM to be exploited, where DKIM, at a minimum, includes 
the From header field.  Specifying a DKIM result for multiple From 
header fields impacts ONLY consumers of DKIM results.  This is not about 
enforcing RFC5322 compliance, this acknowledges that many processes 
assume there will be only a single From header field, as required by 
RFC5322.   Violation of this expectation prevents any DKIM status other 
than PERMFAIL to be safely returned.

>  It also does all kinds of validation that the data it got back from
>  the nameserver on a key or policy query conforms to the expected
>  format of a DNS query described in RFC1034, because if it doesn't
>  (which does happen sometimes, four so far today in the logs) then
>  running with those bits can have nasty side effects. But RFC4871
>  doesn't, and shouldn't, require that checking. That syntax is
>  defined in RFC1034.

DKIM Section 3.2 requires that tags with duplicate names *MUST NOT* 
occur within a single tag-list; if a tag name does occur more than once, 
the entire tag-list is to be considered invalid.  Because many had 
trouble with the format specified in Section 3.2 for tag values that are 
space delimited, many did not want to use the colon delimited structure 
specified in section 3.6.1.  Now many have decided to list the t= tag 
twice when adding the t=y value.  A similar problem also exists with the 
g= tag.  It is ironic that DKIM is having trouble ensuring strict format 
compliance for these unique DNS resource records.

RFC1034 clearly indicates valid results without expecting the consumers 
of DNS to second guess their validity.  However DKIM requires use of TXT 
resource records that are not required by SMTP.  An intrusion into DNS 
that is also being overlooked.  DKIM also specifies RFC3833 which warns 
against name chaining that also impacts the operation of DKIM validation.

>  Or are you folks also saying we should add text to RFC4871bis
>  mandating validation of the results returned by functions like
>  res_send()? Suppose a chthonic hacker could send DKIM-signed mail
>  that causes his DNS server to be queried, returning a reply that
>  will somehow always validate (or crash). And suppose res_send()
>  doesn't validate the payload, only passes it through to the caller.
>  Isn't this just as dangerous?

How would changing DKIM mitigate this type of threat?

>  We are most certainly obliged to emphasize to consumers of DKIM
>  output the distinction between what was covered by a signature and
>  what was not, and lay out the possibility that such consumers could
>  be confounded in the way that's been described. Failing to do so is
>  a disservice. I'm all for putting that into Security Considerations
>  in intricate detail with lots of examples of possible exploits. That,
>  to me, is precisely why that section is mandated as part of all RFCs.
>  I will happily write a sesquipedalian treatise on this topic to be
>  included there if it resolves this issue.

Disagree.  DKIM ALWAYS includes the From header field!  It would be a 
disservice to expect consumers of DKIM results to involve themselves in 
the same intricacies currently handled by the DKIM verification 
process.  By providing the correct results, no second guessing (layer 
violation) would be needed.

[]
>  No, Doug, I don't think these checks belong in POP3, or IMAP, or
>  SIEVE. They belong in whatever component is the one that decides
>  when or whether seek or apply a DKIM result.

What component?  How many of these "whatever" components need to be 
updated to mitigate use of multiple From header field exploitations of 
the trust established by DKIM?  Won't this be asking them to make the 
same checks that the DKIM verification process should have made?

>  Like I said before, it should be perfectly reasonable for a protocol
>  specification to require something proper from the layers below it,
>  and to require of itself that it only hands something valid to the
>  layers above it.

So you expect SMTP will now start strictly enforcing RFC5322 compliance 
just to retain the integrity of DKIM results?  IMHO, this would not be a 
realistic expectation.

>  components and DKIM work belongs in the DKIM components. Anything
>  else makes as much sense to me as asserting that an MTA/MUA/whatever
>  should only invoke a DKIM verifier after confirming that the
>  DKIM-Signature header field conforms to what RFC4871 says. I would
>  find that equally incorrect, and for the very same reasons.

RFC5321 does not mandate strict RFC5322 compliance!  It never has, and 
likely never will.  Since DKIM, at a minimum, binds the DKIM domain with 
the From header field, it remains critical from a security standpoint 
that DKIM not offer PASS results when there are multiple From header 
fields!

>  HTTP output. Packing DKIM with mail-specific verification
>  requirements could prevent such things from happening. Shall we
>  also add a "but only when used in the email context" clause?

Disagree.  Whenever results might be ambiguous and thus exploited, PASS 
should not be returned.  This rule would be equally true for any message 
format.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Oct 2010 15:42:32 -0700

On 10/20/10 8:10 AM, Ian Eiloart wrote:
> >> True, but there already are UI designs that indicate when a From
> >> header is DKIM verified.
> >
> > So you're saying that all a spammer has to do is to put on a
> > throwaway domain's signature, and the MUA will highlight at least
> > parts of the message with green goodness? Surely our understanding
> > of domain reputation is better than that.
>
>  I believe that's the basis of this whole discussion, isn't it. The
>  point is that the MUA tells you whether the header was signed, and
>  leaves you to apply the domain or address reputation. I think that's
>  a step forward. At least, it is when I know the purported author.
>  And, surely I'm better at assigning reputation to -say- my brother
>  than any automated system is.

DKIM does not authenticate the From header field, however it provides 
authenticated DKIM domains that are, at a minimum, bound with the From 
header field.

When the DKIM domain is "Big-Bank.com", and you or your system trusts 
this domain, there should also be less concern related to whether a From 
header field containing "[email-masked]" offers deceptive 
information.

>  But, hey, I'm on your side here. I think we should put a warning in
>  the RFC so that vendors are informed that they need to be sure
>  they're highlighting the correct header.

Why?  There would not be a problem when DKIM verification results return 
PERMFAIL when there is any doubt which From header field might be 
selected when more than one exists.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Oct 2010 16:35:46 -0700

> I'm pushing for (b), while someone who insists the text be normative is pushing for (a).
a) please.

In this case, "low quality" really means "misleading results".  Why are 
you reticent in adding obvious checks, that I am sure your code will 
include.  Not making this a MUST return PERMFAIL for multiple From 
header fields otherwise means DKIM results can never be trusted.  The 
results would not offer interchangeable implementations, since it is 
unreasonable to expect consumers of DKIM results will always make the 
relevant checks that might have been missed, or that SMTP will now 
suddenly alter its level of compliance checking.

This is really about checks that will consume only a few CPU cycles, 
since the information is already touched by the verification process.  
What is a few picoseconds between friends? :^)

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 Oct 2010 16:36:45 -0700

> I'm pushing for (b), while someone who insists the text be normative is pushing for (a).

I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that.

I do think that an informative note observing "Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already" would be reasonable.

"Somewhere in your mail handling path" might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is "non-compliant" or "low-security" or "low-quality" doesn't seem helpful.

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 20 Oct 2010 20:08:23 -0400

> Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality?

The latter.  Hey, we agree.  I think I always said SHOULD rather than 
MUST.

The DKIM spec is a peculiar combination of instructions on how to produce 
a technically valid signature along with a great deal of non-normative 
advice, some of which is good (sign all the visible headers) and some of 
which is not so good (tell MUAs to highlight the signed parts.)  If I were 
redoing it, I think I would go through all the advice and either turn it 
into a SHOULD if it tells you how to do more robust signing and 
verification, or get rid of it.  If you recall my snarky message to Dave a 
few days ago, I actually do think we should get rid of that stuff.

There are already a zillion ways to produce a technically valid but 
useless signature, so I'm not concerned about yet another one.  I'd just 
like to give people who want to do useful signing and verification the 
best shot at it we can.  Keep in mind the "as if" rule, which says that 
your code can do whatever you want so long as the results are the same as 
if you followed the spec.  So if the spec says you SHOULD NOT sign or 
verify messages that have extra headers that MUAs are likely to render 
inconsistently, it would be entirely valid to have a validation prepass 
that ensured that the DKIM module never saw those messages at all.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Oct 2010 17:13:05 -0700

> "Somewhere in your mail handling path" might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation…

I think that Steve threads this just about right. No need to cast aspersions,
or kick them off the "compliant" island. Just lay out the security consideration
and let people deal with this however makes sense. I'm still puzzled how this
tempest entered this tea pot.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 20 Oct 2010 21:08:58 -0400

>tempest entered this tea pot.
Um. That's not how I read what he wrote. He specifically said no to security considerations and I understand that's what you're in favor of.

Confusedly yours,

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 Oct 2010 19:09:56 -0700

On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote:

> Um. That's not how I read what he wrote. He specifically said no to security considerations

I don't think I did. The "informative note" would probably be something informative, rather than prescriptive, in the security considerations section.

What I wouldn't favour would be a MUST or a SHOULD or anything morally equivalent to either, as it's outside the scope of a DKIM specification to do that.

> and I understand that's what you're in favor of.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Oct 2010 21:38:04 -0700

> Sent: Wednesday, October 20, 2010 5:08 PM
> To: Murray S. Kucherawy
> > Here's maybe a better way to frame the question: Should we empower
> > ourselves to label a DKIM implementation that doesn't do format
> > enforcement as (a) non-compliant, or (b) low-security/low-quality?
> 

Damn, lost it.  I think we should talk about it, and even in detail, but without using those words.

And I'd be fine converting the MUA advice to which you refer into something more general, like hammering home the point about what exactly a validated signature is telling you, and leave it to the implementers of those modules to figure out what to do with that information.

---

From: "Mark Delany" <[email-masked]>
Date: 20 Oct 2010 23:00:41 -0700

> And I'd be fine converting the MUA advice to which you refer into
> something more general, like hammering home the point about what
> exactly a validated signature is telling you, and leave it to the
> implementers of those modules to figure out what to do with that
> information.

It's stating the obvious by now, but I'm with (a).

While it might be technically elegant to delegate (a) to another
layer or some "magic sauce", or some informative text, it misses the
bigger picture.

That bigger picture is that DKIM has no certainty of success simply by
being a technically neat and layer-compliant protocol.

DKIM will succeed only if it is picked up and used by a vibrant and
wide-spread community of DKIM consumers - MUAs, list servers,
reputation systems, email appliances, whatever.

Given the well-recognized inertia in the email biz, to maximize our
chance of success, we need to make it as easy as possible for this new
community of DKIM consumers to succeed. To my mind that means that
those consumers can write no-brainer code and reap the benefits of
DKIM.

So, every time we relegate or delegate parts of DKIM compliance to
those consumers - perhaps by way of informative text about 2822
compliance - we are simply creating barriers for the very consumers
that we need to make DKIM a success.

Are we so confident about DKIM adoption that we feel we can
effectively "order" this future community to do this sort of work?

I for one am not. I for one think that if we make DKIM as easy as
possible to consume and we market the heck out of it, we may, we just
may succeed in wide-spread adoption, maybe.

So, forget technical elegance. Forget layering violations. What are we
doing that makes DKIM compelling and easy to consume?

Mark.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 21 Oct 2010 11:02:26 +0100

> selected when more than one exists.

Well, that would be even better. But that's a change to the spec. If the 
spec were changed, I'd be happy about that. In the mean time, we need to 
warn implementers about the security risks that we've identified.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Oct 2010 12:37:10 +0100

> example, the initial paragraph of section 5.4 could be modified so as

But that does not address this particular scam (though it does address  
some other scams involving duplicated headers).

Notice that in my scam it is the Bad Guy that generates the signature, and  
you cannot assume that a Bad Guy will obey ANY requirement imposes by  
4871-bis if he believes that generating a message thsat violates that  
requirement will enable him to fool somebody of some sysyem somewhere.

........

> verify (although I'd consider it cleaner to return non-DKIM errors for

Yes, verifiers are the only place where this scam can be caught, and they  
must be mandated to catch it. The precise means of catching it can be  
discussed, and whether they catch it on the grounds that 5322 has been  
violated or on the grounds that some other provision of 4871-bis has been  
violated is just a matter of semantics. If it makes people happier to word  
it so that it is not perceived as a "layering violation" then I suppose  
making it appear as a 4871-bis violation would be better; but I do not  
really like technical solutions being dictated by purely political  
arguments.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 Oct 2010 12:49:19 +0100

> Heck, no.  Treat it like there's no signature at all, and filter it like

So if I (being a perfectly honest citizen) create some brand new internet  
service, which needs to be secure; and if I secure it by signing all  
emails sent to my clients plus declaring an ADSP policy of 'discardable',  
then you want all messages sent to my clients on day 1 of the service to  
be discarded at my clients' boundaries because, not yet having established  
any reputation, my messages are to be treated as unsigned, and hence  
discarded in accordance with my ADSP setting????

And it the reputation services discover that all mails sent from my domain  
are being discarded, they will start to create a Bad reputation for me,  
instead of the Good one that I hoped to acquire as my new service became  
known.

No, lack of reputation has to be treated as entirely neutral. Bad  
reputations have to be earned by performing Bad deeds.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Oct 2010 17:17:18 +0200

On 20/Oct/10 19:48, Douglas Otis wrote:
>> For example, the initial paragraph of section 5.4 could be
>> modified so as to read:
>>
>> whether signed or not.
     DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)...
> This message could be sent directly, or distributed by replaying it to

In my hypothesis, a verifier would discard the 2nd "From 
[email-masked]", at least for hashing purposes.  If they were 
both signed, PERMFAIL would result from a mismatch in the header-hash. 
  If Big-Bank had been added after signing, verifiers are already 
authorized to delete that field from the message, according to the 
current PS.  Isn't that enough?

Further thwarts can be specified in some ADSPbis, eventually.  In 
particular:

   DKIM-Signature: d=Big-IPS.com; h=from; ...
   From: [email-masked], [email-masked]
   Subject: Audit notification
   ... (missing Sender)

> detected, whether both or one of them are signed.

I don't think the spec should impose surplus security.  The minimal 
layer violation quoted above might be forgiven after considering the 
importance of the From field for DKIM.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 21 Oct 2010 11:47:34 -0400

> current PS.  Isn't that enough?

I don't know any DKIM verifier that modifies the message, and I doubt that 
many people would want to use one.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 21 Oct 2010 12:06:35 -0400

Having pondered the layer thing some more, it occurs to me that we have 
several decades of practice with software that validates the format of 
mail messages to a greater or lesser extent, with the emphasis on lesser. 
Different software depends on different bits of the message to be correct, 
which means that some leakage of the message validation into different 
applications is unavoidable unless you're willing to lose mail that has 
flaws that don't matter to the applications that it passes through.

In procmail, for example, doubled subjects only matter if you have a rule 
that does something depending on the subject line.  In MUAs, based on the 
random way existing MUAs handle them, they don't matter at all.

So that's where my SHOULD NOT comes from.  It leaks the bit that matters 
to DKIM.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Oct 2010 18:30:23 +0200

On 21/Oct/10 17:47, John R. Levine wrote:
> I don't know any DKIM verifier that modifies the message, and I doubt
> that many people would want to use one.

Adding and removing Authentication-Results is probably the most common 
modification.  Removing header garbage may also be fairly popular, 
dunno.  Why do you think it's bad?

At any rate, the paragraph I was referring to is

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 Oct 2010 09:53:40 -0700

> Sent: Thursday, October 21, 2010 9:07 AM
> To: Murray S. Kucherawy
> Subject: More on layer violations
> 

All true.  But those are implementations, not specifications.

You can add OpenDKIM to that list.  Like I said, it already does do the validation, but that's because RFC5322 says so, not because RFC4871 says so.  And I think that's the way it should stay.

Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C.  They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot.  But none of those sections are normative.  (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.)

That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 21 Oct 2010 10:01:24 -0700

+1

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 21 Oct 2010 13:13:48 -0400

> modification.  Removing header garbage may also be fairly popular, dunno. 
> Why do you think it's bad?

Adding A-R is fine.  Messing with the message otherwise is more help than 
I want from DKIM.

> before display to the end user.

That's an example of the bad advice that I think we should drop from 
4871bis.  It does nothing to improve robustness or interoperability, just 
offers unsolicited advice to MUA developers.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Oct 2010 15:03:24 -0400

-1.

This is not a LAYER violation.  DKIM is a  protocol for RFC 
822/2822/5322 data to:

   a) verify a message signature, and/or
   b) create a message signature.

In order to do either requires INPUT that MUST be valid for the 
protocol to be fundamentally correct with its OUTPUT.

Therefore it MUST make sure its input is 100% valid.

This is not different than any function generator that checks its 
boundary conditions.  A robust function generator MUST check its input 
otherwise you have faults, chaos, aborts, GIGO - Garbage In, Garbage Out.

DKIM is fundamentally a security protocol and it will be insane to 
believe that it should allow GIGO to occur due to not checking it 
input validity.

A Layer Violation is when you are asking for data bits that in 
821/2821/5321 (or another our feed) and/or also producing BITS that 
other layers like a MUA might use.

We are not doing the former but would be if we bind bits like a 
Return-Path. We are differently doing the latter with the creating of 
more bits for other LAYERS to use.

DKIM validating its INPUT is not a layer violation and in practice, it 
will be extremely bad product engineering. In fact, I would go as far 
to make it an ethical engineering responsibility for ALL DKIM 
components to make sure its not a GIGO engine.

Now, if that doesn't jive with the "IETF DOCS" well, thats an entirely 
different issue. Most implementators are not going to GAS (Give a 
S$$$) what that docs says or doesn't say if it not providing what is 
fundamentally necessary.

The DKIM component MUST check its input and at least one independent 
API has done so (on the verify side for 5322.From only).  It could not 
pass the buck to 822/2822/5322 message generators or verifiers.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 21 Oct 2010 13:04:29 -0600

+1

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 21 Oct 2010 13:09:54 -0600

> offers unsolicited advice to MUA developers.

As this conversation has continued, I'm increasingly convinced that the only sane path forwards is to have a separate Informational or BCP document containing MUA considerations.  The only question is whether that'd be restricted to considerations we've discovered while discussing DKIM (in which case it might fit in this WG), or open to all the stupid MUA tricks this community has seen since rfc733 (which should probably be a new WG.)

Either way, I'd be interested in participating in the effort.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 12:20:33 -0700

On 10/19/2010 3:11 AM, Ian Eiloart wrote:
> sender address.

DKIM makes no statement about the validity of a "sender" address.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Oct 2010 15:25:56 -0400

That is a different issue all together.  We are talking about a 
security threat that fell through the cracks during the RFC 5016 
production in this group.

It MUST be corrected - pronto, not later, not in another I-D, not in 
another WG.  No - in 4871bis.

It is rather tiring to seeing the rationalization on how to try to 
avoid not directly talking about the security loophole and resolution. 
  Whether its MUST, SHOULD or it should not do anything and pass the 
buck to a lower layer.  That is all nonsense.  While in an integrated 
environment, you have all sorts of ways to resolve this, a DKIM is an 
independent RFC 5322 Protocol Technology - therefore it inherent all 
the design requirements to  make sure that GIGO (Garbage In, Garbage 
Out) does not occur.

Lets fix the "DOC BUG" and be done with it - thats forward progress.

---

From: "John R. Levine" <[email-masked]>
Date: 21 Oct 2010 15:58:10 -0400

> DKIM makes no statement about the validity of a "sender" address.

Nor the validity of anything else other than the d= domain.  So I am 
having trouble figuring out how come people think we can give any advice 
to MUA developers.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 22 Oct 2010 12:14:27 +0100

--On 21 October 2010 12:20:33 -0700 Dave CROCKER <[email-masked]> wrote:

>> It's that, in order to get the marking, she can't spoof a trusted
>> person's sender address.
>
>
I guess I should have said Author address.

In practice, if I look at mail with yahoo.com author addresses for example, 
I find that with DKIM yahoo.com signatures, they're about a million times 
less likely to be forged than without those signatures. That's not to say 
that yahoo.com forbid forgery, but they may find that their mail stream 
reputation improves if they take measures to prevent forgery.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 22 Oct 2010 07:49:04 -0700

> I guess I should have said Author address.

DKIM makes no statement about the validity of an author address.

d/
-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 Oct 2010 17:06:14 +0100

> current PS.  Isn't that enough?

I am am not clear what you are suggesting here. Please clarify. Do you  
actually want to pass on to the recipient a message that was different  
(i.e. lacked a header) from what came in. If so -1.

Or if you are saying that the varifier should hash the first From:  
(contrary to 4871 with requires it to hash the second), thus triggering a  
PERMFAIL, then you are indeed getting the right answer, but by some very  
weird means.
>    Subject: Audit notification

Isn't that already required to have signatures from each, according to  
4871?

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 Oct 2010 19:08:16 +0200

On 22/Oct/10 18:06, Charles Lindsey wrote:
> On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Vesely<[email-masked]>
> wrote:
>

That's one possibility.  What I have in mind is an MTA filter, not a 
MUA extension.  The same program may be authorized to silently drop 
whole messages to honor "discardable" policies, so I don't think it is 
a desecration to drop a spoofed header field when it finds one.

I'd never mandate such behavior, though.  It may be made available as 
an option when users will solicit it, if ever.

> Or if you are saying that the verifier should hash the first From:

I mean first, second in a bottom-up sense.  Since the verifier knows 
there can only be a single From, it hashes empty strings for any 
further one.  Of course, if the verification fails, there is no way to 
try and discern signed fields...

> Isn't that already required to have signatures from each, according to

No, the signature isn't tied to the domain in the From field(s).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 23 Oct 2010 01:43:45 -0000

>I guess I should have said Author address.

DKIM makes no statement about the validity of an Author address.

>reputation improves if they take measures to prevent forgery.

Sure.  Yahoo goes to some effort to verify that its mail users control
the addresses they use, by sending a test message with a URL the user
has to click.  But that's a characteristic of what Yahoo does which
you could tie to a d=yahoo.com signature, not of DKIM in general.

I make no attempt at all to control my users' From: lines, since I
know them all and don't expect them to misbehave.  I do put in trace
info to tell who sent what, but you can't tell that from my DKIM
signatures, either.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 22 Oct 2010 22:13:13 -0400

> DKIM makes no statement about the validity of an Author address.

I keep reading this but there is no technical merit to show there is 
any truth to it, and in fact the only thing that is probably the 
strongest validity is the Author Address.

No matter how many times it is stated and repeated, it will never be 
true. If one wants this to be true, then remove the required binding 
the Author Address, A.K.A 5322.From.

I will go on to suggest that this ongoing design confusion of trying 
to water it down with unrestricted resigners is what got this WG all 
bogged down in trying to teach the world that the From really means 
nothing but only the signer does.  It even reduces the incentive for 
adopters to invest in Domain DKIM Signing because they really have no 
power over controlling who can take control of their own messages or 
those that purports to be from them.  They have really little payoff.

My point is it really hasn't help DKIM to continue to water down the 
validity of the author address.  If it wasn't a required binding, then 
there begins some truth to the statement.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 23 Oct 2010 15:25:20 -0400

> the Author Address, A.K.A 5322.From.

No, not at all.  While I think it was probably a mistake to make the
signing of ANY header fields "MUST" (we should have just put "From" in
with the other "SHOULD" fields), the fact that "From" MUST be signed
says, in itself, nothing about the *validity* of the address (nor the
display name) in that field.  That's up to the signer.

It's all a question of what the signer is willing to sign.  I have two
submission domains that I use.  One, gmail.com, which does DKIM
signing, will only allow me to use a "From" address after it has sent
a test message to that address and seen that I can access the test
message.  So it's made *some* level of confirmation that I owned the
address at the time I set it up.  But there's no confirmation that I
still own the address, and there's certainly no assessment of the
display name that I associate with it.  Gmail will sign mail that I
send with my old IBM addresses in the "From", though I have not worked
for IBM for over a year and a half, and no longer have any
authorization from IBM to use those addresses.

Is that "valid"?

The other submission domain I sometimes use, which does not currently
DKIM-sign, will let me put anything at all that I like in the "From"
field, including, say, "[email-masked]".  It doesn't check,
and it doesn't care, as long as I'm connected to their network when I
send the message.  They could start signing with DKIM tomorrow.  If
they did, would you then say that the "From" address in those messages
is "valid"?  I wouldn't.  You might say, "Well, they shouldn't oughta
do that."  Maybe wise people would advise them not to.  But maybe
they're not wise.  DKIM doesn't weigh in on that.

The fact is that probably 99% of their users just use the proper
domain in their "From" fields, and it doesn't matter.  The fact, for
John Levine's domains, is that he knows and trusts his users, so he
lets them do what he wants.  Now, if his signing domain started
developing a bad reputation because some of his users were sending
mail as "whitehouse.gov" or whatever, he might change his policy.  As
might my service provider, if they started signing and saw their
domain's reputation go south.

But that's all outside the scope of DKIM.  DKIM only provides
assurance of the *signing* domain, and that the message has arrived
substantially unchanged from when it was signed (modulo h= and c=).

Barry, as participant

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Oct 2010 05:14:42 -0400

Barry,

I think this might be a matter of definition for "validity."  I was 
not speaking of truthfulness, authentication or authorization.  I am 
stating that a valid DKIM signature is making a series of validity 
statements or correctness assertions for the various parts it binds to 
the signature. This really has nothing to do with whether the validity 
statements are actually truthful and/or authorized to be used.

See inline:

> display name) in that field.  That's up to the signer.

And it can also be up to author domain to decide what a) signer domain 
it will and b) what fields are hashed to create the DKIM signature and 
implicit statements of validity for the parts the author decides to bind.

> It's all a question of what the signer is willing to sign.  

And that could also be the author deciding who is the signer and what 
parts are signed.

Part of the on-going "usual misunderstanding" contention is the 
on-going attempts to separate the author from the picture when in 
fact, the author may very well be:

  1) the signer itself,
  2) use a different signing domain owned by the author, and//or
  3) authorized outsourced 3rd party signer.

I believe you are focused on the DKIM product implementation where the 
"3rd Party" is the decider of what parts it binds to the signature.

I believe this market has been covered and IMO, 4871bis remolding 
reflects what changes are necessary to cover this market.

However, the next frontier to increase DKIM adoption is to get private 
domains to adopt DKIM and in this case, they will desire more control 
over what is bound to the signature and what signer domain is used to 
"represent them" for some out of scope reputation engines.

> I have two

I would suggest it is not valid from a "authorization" standpoint.

Nonetheless, from the purity of a DKIM signature, your old IBM address 
would still be a statement of validity - to be authenticated at some 
later date (future DKIM results analyzer layer) perhaps.

Small point of clarification. As far as I recall (last month), the 
GMAIL 2nd account setup is:

    - STARTTLS Test
    - User ID/Password AUTH test
    - Gmail does not DKIM sign these Smart Host setup path

So yes, it is possible to use a valid but "not authorized" 2nd account 
setup. But your setup is still a "statement of validity."

I don't recall it testing the 2nd account as a MAIL FROM or RCPT TO. 
Maybe it did, but note this is a feature for outbound mail, not 
inbound.  See note below regarding MAIL FROM checking.

> send the message.  

Right, for most SMTP systems, the public port fundamental rule is:

    - Anonymous (no authentication/authorization), allow mail for
      local users only, i.e. no open relay

    - Authenticated/Authorized, allow mail for local or remote.

So as long as you are Authenticated/Authorized,  it will allow the 
transaction to be accepted and for some, if not most, it will skip all 
the "checks."   For us, we skip the 821 level checks and leave the 822 
checks to the operators.

For the private port (587), the submit protocol requires 
authentication (login) and it also provides additional enforcement 
rights to validate most or all parts of the transactions.

One pitfall we found regarding authenticated sessions is that it might 
skip checking the MAIL FROM.   The problem here is a non-delivery 
bounce to no where.  So for our system, an authenticated user MAIL 
FROM is always checked against the local user database to make sure a 
bounce is deliverable.

> They could start signing with DKIM tomorrow.  If

I will state that the DKIM process is making a series of statements of 
validity for all the parts (which includes the 5322.From) it hashes 
and binds to create and add a "purportedly" valid DKIM signature.

When the DKIM verifier reproduces a valid signature from the bound 
parts, this is implicitly making a series of validity statements for 
these parts, including 5322.From.

It is only a higher layer, i.e., POLICY and/or the out of scope 
reputation engines which take two different DKIM validated input feeds:

      POLICY_RESULT      = POLICY(Author-Domain)
      REPUTATION_RESULT  = REPUTATION(Signer-Domain)

that can do any "truth" or DKIM validity confidence related concept.

> domain's reputation go south.

I was not speaking of the invalid or unexpected or authorized usage. I 
am saying that what DKIM binds and signs are all parts of its validity 
claims.

> substantially unchanged from when it was signed (modulo h= and c=).

And IMO, these are statements of validity, and it doesn't imply they 
are actually true.

The point is that even if you wish to just use one side of the 
(market) coin where the signer is independent of the authors with a 
blind unrestricted signing practice, and your intent is to use the 
signing domain for some high layer evaluation, the validity of its 
bound parts MAY BE part or in whole of the "total assurance" the DKIM 
valid message wishes to provide, not just that of the signer 
information, but that of the authors as well.

What is not being taking into account is that the author is still a 
fundamental essential part of the message and it is these DKIM 
adopters who will decide not only what fields are hashed and bound to 
the signature, but also what domain will be used for the signer (d=).

My nit is one of a technical sales pov.

     One group is only focusing on a signer domain to satisfy
     some out of scope design goals and continues to water down
     the validity of the From that is required to be hashed bound
     to a VALID DKIM signature.

     Another group, and I believe one that most people will "better"
     understand is that DKIM will help protect the validity of the
     author address.

To help increase DKIM adoption, IMO we should not water down the 
inherent DKIM statement of validity for the hash bound 5322.From which 
is another way of saying that there is a market of originating domains 
that decide what is signed and what signer domain will be used to 
represent them in some future out of scope reputation or currently 
possible VBR feeds.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 24 Oct 2010 11:16:08 -0700

> It's all a question of what the signer is willing to sign.

It is, I think, quite easy to read that last sentence as contradicting the 
preceding paragraph.

With respect to the validity of information, it most definitely does NOT matter 
what is signed.

The choice of what to sign affects the robustness of the "tatoo" in affixing the 
d= domain.  That is, it affects how easy or difficult it is to re-purpose the 
signature with modifications to the message.

> address at the time I set it up.

Well, this is a reasonably common type of example.  I think it confuses the 
difference between a signer's policies, versus DKIM semantics.  It is certainly 
true that different signers have wildly different meanings behind their signing 
behavior.  However there is nothing in DKIM that communicates a signer's 
policies.  (Obviously, ADSP is an example of a value-added semantic, but as we 
all have been reminding ourselves, that's an additional function.)

The critical point, here, is the question:  What can the verifier know?  They 
cannot know about differential policies and in particular the choice of what 
parts of the message are covered by the signature communicates no additional 
semantics.

...
> domain in their "From" fields, and it doesn't matter.
...
> But that's all outside the scope of DKIM.

Exactly.

> DKIM only provides

It is possible to read the first clause as meaning more than you actually meant, 
so I'll suggest a slight tweak which is still what you meant:

    DKIM only provides an assurance of the valid use of the signing domain name 
(d=), and that the message...

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Oct 2010 17:52:06 -0400

> parts of the message are covered by the signature communicates no additional 

I think that is a different question but one that is based on a 
fundamental premise of having statements of validity for 
cryptographically protected parts of the message.

Does all this suggest that one must begin with a presumption of false 
information?

In other words before you can ask the question "How/what can the 
verifier know?" it has to begin with the validity claims made by the 
signature and its bound parts.

So when you sign a message with signer-domain and it has a required 
bind for a author domain, these are two minimal statements of validity 
to be verified and perhaps confirmed by some "higher power."  Perhaps 
Policy with its author-domain feed, and/or perhaps out of scope 
reputation engines with its signer-domain feed.

I think it is the latter that you are pushing for. I would like to 
keep DKIM pure  and open to not just be about the signer domain.  I 
believe that as long we continue to minimize the statement of validity 
a valid DKIM signature provides for 5322.From, the more these "usual 
misunderstandings" will persist.  There is a reason why it doesn't go 
away and might we are trying to promote an obscure and abstract 
concept of an independent signer domain that today it is still very 
hard to grasp, especially with the lack of application demonstration. 
  On the other hand, the majority of the industry can grasp and feel 
the issues regarding a 5322.From and can better understand the idea 
that DKIM might be a technology to help protect it.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Oct 2010 11:22:32 +0200

> display name) in that field.  That's up to the signer.

A way to clarify this point is to say /why/ From MUST be signed.  For 
simplicity, I restrict my guessing to two possible reasons:

A) From MUST be signed because assuming that h= is not empty may
    simplify something.  The "From" header was chosen somewhat
    randomly among fields that would have deserved a SHOULD anyway.

B) DKIM mandates signing From in order to pave the way for ADSP.
    Indeed, ADSP semantics is largely anticipated in DKIM, although
    not specified in the details.

The latter reason would require normative text to guard against double 
fields in 4871bis, for consistency with RFC 4871's implicit assumptions.

IMHO, the new text in Murray's proposal would be easier to understand 
if reason A, Barry's quoted paragraph above, or any similar informal 
explanation were also added to the draft.

> Gmail will sign mail that I send with my old IBM addresses in the
> "From", though I have not worked for IBM for over a year and a
> half, and no longer have any authorization from IBM to use those
> addresses.
>
> Is that "valid"?

Yes, in the sense that it is what the Author choose.  More precisely:

  The originator fields indicate the mailbox(es) of the source of the
  message.  The "From:" field specifies the author(s) of the message,
  that is, the mailbox(es) of the person(s) or system(s) responsible
  for the writing of the message.

It doesn't have to be a working mailbox, e.g. [email-masked].

The responsibility that a signer claims may be delegated, e.g. "I make 
no attempt at all to control my users' From: lines, since I know them 
all and don't expect them to misbehave."

Even syntactical validity checks may be delegated to the Author's 
client, according to message submission policies.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 25 Oct 2010 11:25:40 +0100

> strongest validity is the Author Address.

Actually, it depends on what one means by "validity". If one simply means 
that the author address hasn't been modified since the message was signed, 
then DKIM does speak to the validity.

If one means that the author address was used with the permission of the 
owner of the address, then a DKIM signature helps only if you know 
something about the signer. The likelihood of the author address being used 
with permission of the author will increase if signers make efforts to 
forbid domain spoofing. However, there's always the possibility that an 
account has been compromised, for example by a phisher.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Oct 2010 14:47:44 -0700

On 10/23/10 12:25 PM, Barry Leiba wrote:
> On Fri, Oct 22, 2010 at 10:13 PM, Hector Santos<[email-masked]>  wrote:
>> John Levine wrote:

Agreed, but DKIM at a minimum, requires the binding of the From header 
field with that of the signature.  Many consumers of DKIM results may 
rely upon this binding as a basis to extend trust of a signature to 
include the From header field for trustworthy sorting or display.   The 
signing domain, through an Out of Band method,  may make assurances 
about the From header field as having been authenticated to protect a 
sorting or display process.  Wherever the DKIM verification process 
occurs, it MUST ensure there is only a single From header field to 
protect these results from being trivially exploited.
> authorization from IBM to use those addresses.
At no time will the name be signed by IBM.  Identification depends upon 
each domain's name reuse policy.    Some domains do not allow names to 
be reused for this reason.  If IBM were to decide to reuse your old 
email address for a different employee, they then risk having this name 
confused with the original holder of the email address.  The same 
problem occurs for mailing-lists and other methods that depend upon 
seeing the same email-address.

> substantially unchanged from when it was signed (modulo h= and c=).
Agreed.