Subject: [ietf-dkim] Final update to 4871bis for working group review

From: Barry Leiba <[email-masked]>
Date: Sat, 2 Jul 2011 23:26:49 -0400

The 4871bis draft was on this past Thursday's IESG telechat, and
mostly passed, but for a strongly held DISCUSS position from one AD,
Pete Resnick.  Pete had particular complaints about sections 8.14 and
8.15, along with some other issues, and was willing to block the
document until they were resolved.  The editors and the AD together
worked diligently for resolution, and in the end came up with an
updated version that they can all accept, and that we think the
working group can as well -- at least to the extent that we had agreed
before; these changes will not make Charles and Doug happy, but I
think they retain the essence of the rough consensus of others.

Because of the extent of the changes, though, the chair (I) thinks it
needs to come back to the working group for another review.  So the
working group is now asked to look over the diffs, noting that in a
few cases blocks of text were moved to other sections without being
changed.  ONLY diffs are in scope for reconsideration at this point,
and we'll be looking for confirmation that the changes are acceptable,
as well as complaints about the changes.  Complaints SHOULD come with
specific suggestions for alternatives.  Pete apologizes for not having
been involved with this earlier, promises to closely follow the
mailing list thread on this, and will participate in any text
negotiation that's necessary in order to get this right.

We have a week.  Murray will be posting the update (-14) very soon.
Please review and comment by 11 July.

Barry, as chair and document shepherd
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 2 Jul 2011 21:08:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Saturday, July 02, 2011 8:27 PM
> To: DKIM Mailing List
> Subject: [ietf-dkim] Final update to 4871bis for working group review
> 

The update has been posted.  For your convenience:

http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/

You can also get the diffs here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-14

---

From: "John R. Levine" <[email-masked]>
Date: 3 Jul 2011 00:58:40 -0400

>> Please review and comment by 11 July.

I would have liked to strip even more of the cruft out of 4871bis, but 
this is considerably better than the previous draft.  Ship it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Sun, 3 Jul 2011 08:54:20 -0700

> this is considerably better than the previous draft.  Ship it.

Regardless of any remaining cruft, I'm glad to see this particular cruft removed.  I think Pete made the right call.  Ship it.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Steve Atkins <[email-masked]>
Date: Sun, 3 Jul 2011 10:50:53 -0700

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-14

Looking just at the diffs this seems to be a good improvement
in clarity, without changing the meaning significantly. 

Looks reasonable to me. Ship it.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sun, 03 Jul 2011 11:57:16 -0400

Well, I don't wish to be the pessimistic one.  The changes only makes 
us happy.  So we passed the buck to external processes to make sure a 
message is RFC5322/4409 ready.  Doesn't change the fact that 
something, someone has to do it and depending on the implementor, they 
will be proactive about it or not.    From a Product Development 
standpoint, it is prudent the standalone API vendor deals with it. The 
integrator will also be aware it needs to be dealt else where, 
especially if the API vendor is ignorant about it.

As I reflected over our lunch meeting, all this doesn't matter when 
the basic fundamentals about the overall DKIM payoff is still 
questionable.  I still have a difficulty in "selling" DKIM to our 
customers - what/how will they benefit?  All we are doing is producing 
an AuthRes - Whoopie!!

I don't think anyone can describe DKIM in lay terms in one or two 
sentence that doesn't even involve the AUTHOR DOMAIN interest or 
rather doesn't make him scratch his head about how they should use 
DKIM in a way they can "feel and touch" a payoff.

When the answer to the question, is NO:

      Does a Author Domain have an controls over who is allowed
      to sign his mail?

Its hard to see payoffs with DKIM.

Anyway, for the sake of the WG, lets get this done already. I don't 
think it will alter current implementors but I do question if future 
readers will be able to implement dkim from these specs.  Its a 
complex beast.  But completing it, at the very least, I can use the 
"official completion announcement" as part of our marketing.

PS: We resolved the overhead issues with DKIM signing so we are now 
ready to go. :)

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

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 5 Jul 2011 13:57:49 -0400

On Sat, Jul 2, 2011 at 11:26 PM, Barry Leiba <[email-masked]> wrote:
<snip>
> Please review and comment by 11 July.

+1 to -14 update.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Jul 2011 12:17:10 +0100

> Please review and comment by 11 July.

Whilst any rewriting of the old sections 8.14 and 8.15 is to be welcomed,  
the new section 8.15 does not quite fit the bill.

We may have decided that the attacks under discussion are not attacks  
against DKIM as such, but it cannot be denied that it is the advent of  
DKIM that has made them possible; and even if DKIM itself is not to  
prevent them, it is still necessary to catch them somewhere. It is  
therefore our responsibility, in our Security Considerations, to give  
sufficient indication of the nature of these attacks for others to  
understand precisely how they work, so that they can be countered in the  
proper place(s). And the new 8.15 does not give sufficient detail for that  
purpose, even though it clearly has those attacks in mind given that it is  
headed "Attacks Involving Addition of Header Fields" (though I would  
s/Addition of/Extra/ since in some attacks the extra headers were present  
 from the start).

Here, therefore, is my proposed revision of 8.15 (which still includes  
most of Pete's new text).

8.15.  Attacks Involving Extra Header Fields

    DKIM is able to sign and validate many types of messages that might
    cause problems elsewhere in the message system.  The message might
    violate some part of [RFC5322], such as by having multiple instances
    of From: header fields (or of other fields which are supposed to
    occur only once).  Equally, it might contain data that constitutes an
    attack, such as falsely indicating the name of the author (perhaps
    via such an extra From: field).  These can represent serious attacks,
    but they have nothing to do with DKIM; they are attacks on the
    recipient, or on the wrongly identified author.

    Many email components, including MTAs, MSAs, MUAs and filtering
    modules, implement message format checks only loosely.  This is done
    out of years of industry pressure to be liberal in what is accepted
    into the mail stream for the sake of reducing support costs;
    improperly formed messages are often silently fixed in transit,
    delivered unrepaired, or displayed inappropriately (e.g. by showing
    only the first of any multiple From: header fields).

    Recall that, when multiple instances of a given header field are
    present, they are signed starting with the last one and working
    upwards (section 5.4.2). A variety of attacks taking advantage of
    this feature can be envisaged. In some, the attacker is himself the
    signer, signing the second of some duplicated field on behalf of his
    own domain, whilst hoping that some lenient MUA will display only the
    first. In others, a genuine signature from the domain under attack is
    obtained by legitimate means, but extra header fields are then added,
    either by interception or by replay.

    Indeed, in the latter scenario DKIM can aid in detecting such
    addition of specific fields in transit.  This is done by having the
    signer list the field name(s) in the "h=" tag an extra time (e.g.,
    "h=from:from:..." for a message with one From: field), so that
    addition of an instance of that field downstream will render the
    signature unverifiable (see Section 3.5 for details).  This in
    essence is an explicit indication that the signer repudiates
    responsibility for any such malformed message. However, this
    technique offers no protection in the first scenario.

    DKIM signs and validates the data it is told to and works correctly.
    So in these cases, DKIM has done its job of delivering a validated
    domain (the "d=" value) and, given the semantics of a DKIM signature,
    essentially the signer has taken some responsibility for a
    problematic message.  It is up to the identity assessor (section 2.7)
    or some other subsequent agent to act on such signed but malformed
    messages as needed, such as by degrading the trust of the message
    (or, indeed, of the signer) or by warning the recipient (or even by
    refusing delivery).

    An agent consuming DKIM results needs to be aware that the validity
    of any header field, signed or otherwise, is not guaranteed by DKIM.

    All components of the mail system that perform loose enforcement of
    other mail standards will thus need to revisit that posture when
    incorporating DKIM, especially when considering matters of potential
    attacks such as those described.

-- 
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: Barry Leiba <[email-masked]>
Date: Wed, 6 Jul 2011 12:31:47 -0400

I actually like Charles's edits except for one paragraph, and, as a
participant, would be happy to change 8.15 accordingly.  The one
problem paragraph is this one:

On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey <[email-masked]> wrote:
...

As Pete has pointed out -- and has he's adamant about -- the signer
can't attack... that is, DKIM can't do anything about "attacks" by the
signer.  And that's as Charles's text itself points out.  So I'd be
happy merging just the last sentence with the next paragraph, and
eliminating the rest:

"A genuine signature from the domain under attack can be obtained by
legitimate means, but extra header fields can then be added, either by
interception or by replay.   In this scenario DKIM can aid in
detecting such addition of specific fields in transit.  This is done
by having the signer list the field name(s) in the "h=" tag an extra
time [...etc...]"

Barry, as participant

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jul 2011 11:34:43 -0700

> Sent: Wednesday, July 06, 2011 9:32 AM
> To: Charles Lindsey
> Cc: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 

Interesting side note: Given the reference to Postel's Law being not-such-a-good-idea-after-all, it would be nice if this could make a forward reference to the malformed mail BCP under development.  That can't happen, so instead, we can perhaps just refer to this text from that document.

Anyway, with a few nitty edits from me as well, here's the current 8.15 for -15 for everyone's consideration.  I concur with Barry with respect to the DISCUSS complaint about who's attacking what.  Also, the second paragraph already alludes to the fact that multiple From: fields is a problem regardless of whether or not one of them is signed.  I think it covers the bases and flows nicely.

Also, to be more precise about the deadline for this review, the cutoff for posting this is July 11th at 5pm PDT, so I would like to post it that morning if possible, giving the ADs time to look at it and bounce it to us for changes if needed.

   DKIM is able to sign and validate many types of messages that might
   cause problems elsewhere in the message system.  The message might
   violate some part of [RFC5322], such as having multiple From: fields
   (or of other fields that are supposed to occur only once), or other
   malformed fields.  Equally, it might contain data that constitutes an
   attack on the recipient, such as falsely indicating the name of the
   author.  These can represent serious attacks, but they have nothing
   to do with DKIM; they are attacks on the recipient, or on the wrongly
   identified author.

   Many email components, including MTAs, MSAs, MUAs and filtering
   modules, implement message format checks only loosely.  This is done
   out of years of industry pressure to be liberal in what is accepted
   into the mail stream for the sake of reducing support costs;
   improperly formed messages are often silently fixed in transit,
   delivered unrepaired, or displayed inappropriately (e.g., by showing
   only one of multiple From: fields).

   A genuine signature from a domain under attack can be obtained by
   legitimate means, but extra header fields can then be added, either
   by interception or by replay.  In this scenario, DKIM can aid in
   detecting addition of specific fields in transit.  This is done by
   having the signer list the field name(s) in the "h=" tag an extra
   time (e.g., "h=from:from:..." for a message with one From field), so
   that addition of an instance of that field downstream will render the
   signature unable to be verified.  (See Section 3.5 for details.)
   This in essence is an explicit indication that the signer repudiates
   responsibility for such a malformed message.

   DKIM signs and validates the data it is told to and works correctly.
   So in this case, DKIM has done its job of delivering a validated
   domain (the "d=" value) and, given the semantics of a DKIM signature,
   essentially the signer has taken some responsibility for a
   problematic message.  It is up to the identity assessor or some other
   subsequent agent to act on such messages as needed, such as degrading
   the trust of the message (or, indeed, of the signer), or by warning
   the recipient, or even refusing delivery.

   All components of the mail system that perform loose enforcement of
   other mail standards will need to revisit that posture when
   incorporating DKIM, especially when considering matters of potential
   attacks such as those described.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Jul 2011 12:29:37 -0700

On 7/6/2011 11:34 AM, Murray S. Kucherawy wrote:
>> As Pete has pointed out -- and has he's adamant about -- the signer can't
>> attack... that is, DKIM can't do anything about "attacks" by the signer.
>> And that's as Charles's text itself points out.  So I'd be

The signer can attack the receiver, of course.

The signer cannot attack the DKIM mechanism.  Attacking the mechanism has to do 
with working around the mechanism.  Semantically, that is only meaningful as 
done by independent third-parties.  Not a principal in the use of the mechanism.

> Interesting side note: Given the reference to Postel's Law being
> not-such-a-good-idea-after-all,

Postel's law is generally misapplied from what he intended.

It is mis-used as an excuse for sloppy and overly permissive specification and 
for inaccurate implementation, neither of which were what Jon intended.

He was attempting to cover only those cases in which reasonable specifications 
are subject to some variance in interpretation, resulting in a degree of 
difference in implementation.

As such, it's a dandy rule.

> Anyway, with a few nitty edits from me as well, here's the current 8.15 for
> -15 for everyone's consideration.  I concur with Barry with respect to the
> DISCUSS complaint about who's attacking what.

+1

> Also, the second paragraph
> already alludes to the fact that multiple From: fields is a problem
> regardless of whether or not one of them is signed.  I think it covers the
> bases and flows nicely.

+1

d/
-- 

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

---

From: SM <[email-masked]>
Date: Wed, 06 Jul 2011 10:21:03 -0700

Hi Charles,
>most of Pete's new text).

The text looks good.  If the AD finds the text appropriate, could 
this chapter be closed?

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jul 2011 16:51:49 -0400

My only comment is that we are making way too much out of this.

DKIM requires a From: hashing a minimum requirement and since RFC5322 
only one there are two basic fundamentals rules, together called the 
One From DKIM Rule:

One From DKIM Rule:

    Verify -  DKIM must only see one From when verifying.  If multiple
              From: headers are found, the message is automatically 
invalid
              from a valid DKIM signature standpoint.

    Signing - DKIM must only see one From when signing.  If multiple From:
              headers are found, the message is automatically invalid for
              a DKIM signature standpoint. In other words, it MUST NOT
              continue and sign the message.

Dealing with Exploits:

For the most part, we are dealing with injection of addition From: 
header(s) in an already signed message.   DKIM implementations 
following the One From DKIM Rule, will mitigate this problem.

The proposed h=from kludge, i.e. h=From:From:, has a single design 
purpose to assist LEGACY DKIM implementations that are not up-to-par 
with the One From DKIM Rule.

Some people don't like Kludges but they (DKIM signing operators) will 
add it if they are consider of this and want to "help" legacy DKIM 
verifiers.  But others will give a hoot and erroneously assume that 
ALL edges will deal with it.

What I found when I opened this issue using the fake "President Obama" 
message from me

    http://mipassoc.org/pipermail/ietf-dkim/2010q4/014680.html

was that the Dave's list server did indeed invalidate a RFC5322 
message submission IFF the message was NOT signed.

However, the problem was if the submission was DKIM signed, the Dave's 
list server/DKIM integrated implementation allowed the illegal 
submission to continue -  stripping, resigning and distribution to the 
list members.

Anyway, I think the bottom line is that the modern DKIM specification 
must make it clear about the "One From DKIM Rule" and as most systems 
upgrade, they will eventually make this issue moot.  Most likely, the 
will use the knowledge to also update their edge software, if its not 
already checking.  But as pointed out above, the Dave software already 
did check for valid RFC5322 submissions - the Loop Hole was his DKIM 
integration allow it to bypass this protection already in place.

Therefore, that means, to me, the DKIM specification MUST make it 
clear about a ONE FROM DKIM implementation as cited above.

--

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jul 2011 17:10:35 -0400

>    only one of multiple From: fields).

May only nit about this statement is that its more simple than being 
under pressure, liberal or to reduce cost - in the anals of electronic 
mail, across all networks, only ONE FROM is expected.  Therefore, I 
have my doubts any mail software was ever designed to hold a "list" or 
a collection of more than one From: header simply because it wasn't 
never expected - by design.

Now, whether software check for message validity, why they did so and 
how wide spread this checking is done, probably has to do more about 
how robust the software is to watch for illegal RFC 822/2822/5322 
messages.

The irony here is that the original issue posting was due to software 
that allowed illegal submission of a DKIM signed message but when it 
wasn't signed, the software kicked out the illegal messages.

So its more about how the current edge software deal with it.  Its how 
they integrate it with DKIM and they need to dot all the eyes, cross 
all the t's in their integration.  If they have software control of 
their DKIM stuff,  its probably a good idea to make their the Verifier 
and Signer has a One From DKIM Rule concept as cited in my previous 
post and the specs should make that very clear.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Jul 2011 14:31:04 -0700

On 7/6/11 9:31 AM, Barry Leiba wrote:
> On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey<[email-masked]>  wrote:
> ...
Barry,

When DKIM signatures serve as a basis for acceptance, the current 
verification specification will not prevent deceptive results. This is 
especially true for "too big to block" domains that nevertheless 
restrict what is allowed in the From header field.   Anti-phishing 
protections originally sought using DKIM can be lost whenever multiple 
 From header fields result in a message verified as having valid DKIM 
signatures.

While not a threat against encoding, it is a threat against validation 
that fails to ensure DKIM results are not deceptive whenever checks for 
multiple From header fields do not occur, for example.  A requirement 
absolutely essential for DKIM based acceptance.  After all, verification 
handles these headers twice and no other annotation will indicate 
whether pre-pended header field checks were made.  Without assurance a 
pre-pended From header field had not been added, there is no safe method 
to incrementally deploy DKIM, as suggested in the introduction.

It is also a mistake to suggest the "h=" tag can protect phished domains 
whenever acceptance is based upon a different domain's signature that 
does not make use of new recommendations.  Nor are results for ADSP 
defined either.  The phished domain may continue to be phished despite a 
signing domain's best efforts, where recipients are at even greater risk 
when there is any expectation of DKIM related protections.

It would be neither the signing domain nor SMTP at fault.  It would be a 
deceptive DKIM verification process.  This is not about ensuring all 
messages comply with RFC5322.  This is about preventing deceptive 
results missed in DKIM's original threat analysis.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Jul 2011 16:07:47 -0700

On 7/6/11 3:30 PM, John R. Levine wrote:
>> When DKIM signatures serve as a basis for acceptance, ...
> Since they don't, can we skip the rest of the screed?
In other words, when DKIM signatures serve a basis for acceptance, this 
would be an issue?  The statement "they don't" contradicts preceding 
work and:

Section 1.2. Signing Identity
,--
Verifiers can use the signing information to decide how they want to 
process the message. The signing identity is included as part of the 
signature header field.
'---

Section 6.3.  Interpret Results/Apply Local Policy
,---
It is beyond the scope of this specification to describe what actions
an Identity Assessor can make, but mail carrying a validated SDID
presents an opportunity to an Identity Assessor that unauthenticated
email does not.  Specifically, an authenticated email creates a
predictable identifier by which other decisions can reliably be
managed, such as trust and reputation.  Conversely, unauthenticated
email lacks a reliable identifier that can be used to assign trust
and reputation.  It is reasonable to treat unauthenticated email as
lacking any trust and having no positive reputation.
'---

Clearly, the signing identity's reputation is expected to play an 
acceptance role, otherwise what is DKIM's purpose?  When DKIM's results 
may prove misleading, invite phishing attacks, or cause harm, this 
should question the merits of the current specification.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 6 Jul 2011 18:30:06 -0400

Regards,

---

From: Tony Hansen <[email-masked]>
Date: Wed, 06 Jul 2011 23:47:14 -0400

On 7/6/2011 2:34 PM, Murray S. Kucherawy wrote:
> . Anyway, with a few nitty edits from me as well, here's the current 
> 8.15 for -15 for everyone's consideration.

WFM -- +1

     Tony Hansen

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 6 Jul 2011 22:59:17 -0700 (PDT)

On Wed, 6 Jul 2011, Barry Leiba wrote:
> signer.

Under the double-From: exploit Otis is so concerned about, one signer can
(given favorable winds) trick an end-user into thinking his message was
signed properly *by someone else*.  So indeed, a signer can attack.

Although I still don't agree with Otis' demands for extra language in the
RFC.  Really, his case would make sense if there was some squad of thugs
ready to force every mail-admin to implement DKIM, but only to the strict
letter of the final RFC.  Then putting that in might make a difference --
but so would throwing in a whole bunch of other unrelated anti-abuse best
practices.

In real life, however, if you don't have the power to demand that a
recipient mail admin block incoming double-From: messages, then you don't
have the power to demand that they deploy DKIM at all.

---- 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 Jul 2011 11:17:39 +0100

>               continue and sign the message.

I agree with the above entirely, and have proposed such wordings many  
times. But unfortunately the consensus of the WG has been to not include  
such wordings.

> following the One From DKIM Rule, will mitigate this problem.

No, I think my first scenario, where the attacker signs on behalf of his  
throwaway domain, will turn out to be the more common attack, if we do not  
fix this problem.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Jul 2011 11:08:30 +0100

> happy merging just the last sentence with the next paragraph, and

The signer most certainly CAN attack, but what he is attacking is not  
DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in  
fact, his weapon of attack.

I carefully included two scenarios in my paragraph, which you quote above,  
because they are subtly different attacks. The 1st is the more pernicious  
IMHO and the hardest to counter, since the 'h=from:from:' defence does not  
work. I therefore regard it as ESSENTIAL that our Security Considerations  
give warning of that scenario. Moreover, it is also necessary to draw  
attention to the 'working upwards' signing order, which is at the heart of  
both scenarios, since that might not otherwise be clear to the reader.

I would be happy to reword my paragraph to make it clear that these  
attacks are not against DKIM (although that point is also made strongly in  
a later paragraph). How about the following?

    Recall that, when multiple instances of a given header field are
    present, they are signed starting with the last one and working
    upwards (section 5.4.2). This DKIM feature can be deployed to mount a
    variety of attacks against the email system. In some, the attacker is
    also the signer, signing the second of some duplicated field on
    behalf of his own domain, whilst hoping that some lenient MUA will
    display only the first. In others, a genuine signature from the
    domain under attack is obtained by legitimate means, but extra header
    fields are then added, either by interception or by replay.

and then my following paragraph as they stand.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Jul 2011 13:55:59 +0200

On 06/Jul/11 20:34, Murray S. Kucherawy wrote:
> Anyway, with a few nitty edits from me as well, here's the current

A few comments:

>    [...]

I'd s/to be liberal/to be exceedingly liberal/ (we don't want to
revise Postel's statement, do we?)

>    responsibility for such a malformed message.

+1 for exemplifying "h=from:from:...", even if it's not a cure-all.

>    the recipient, or even refusing delivery.

I'd omit any allegation on what an assessor's needed actions might be.
 (Actually, we'd need yet another policy or authentication method in
order to allow the outcome of an identity assessor to be formally
expressed.  Without it, the quick-n-dirty approach of degrading the
trust of a message by tampering with its DKIM verification's results
may seem the easiest remedy --much like what Doug et al. proposed.)

>    of any header field, signed or otherwise, is not guaranteed by DKIM.

Please, s/validity/reliability/: someone might believe a field is
valid if it retains the value that was given to it originally.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Jul 2011 06:48:58 -0700

> signed properly *by someone else*.  So indeed, a signer can attack.

A signer can attack a recipient.  A signer cannot attack DKIM's mechanisms.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 06:50:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Thursday, July 07, 2011 3:09 AM
> To: DKIM

But all of those attacks exist today even without DKIM, so I don't see how DKIM becomes the weapon.  Even more simple attacks involve use of the display name, something none of this work has even tried to handle (nor should it).

It seems to me we're anticipating improper application of a DKIM "pass" here by MUAs or other agents and thus making the leap to calling DKIM a "weapon".  In that light, MIME is also a weapon.  And so is RFC5322.  And so is HTML.

The current 8.15 text explains what a DKIM "pass" does and doesn't tell us rather clearly.  I'm wary of enumerating specific "attacks" and would prefer to use more general terms, as we have done here; such an effort might be taken as exhaustive.

> both scenarios, since that might not otherwise be clear to the reader.

In your scenario, the modules that operate on the signature result are able to observe that the signer took responsibility for a malformed message and can take appropriate action, degrading the signer's reputation, interfering with inbox delivery, or both.

> a later paragraph). How about the following?

I believe the current text is adequate in that it lays out the semantics of a "pass" more clearly.  I don't think calling out the two-froms-one-signed case explicitly will improve what's there.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 06:57:46 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, July 07, 2011 4:56 AM
> To: [email-masked]

You're either liberal in your application of the RFCs, or you're not.  I don't see how adding that word improves things here.

> I'd omit any allegation on what an assessor's needed actions might be.

"Such as" makes it clear these are only possible actions (and the obvious ones).  It's not an exhaustive list.

> may seem the easiest remedy --much like what Doug et al. proposed.)

If the role of the identity assessor is reputation, and we decide later that we want reputation to be relayed to downstream agents, we can extend RFC5451 by such a registration then.  It doesn't make sense to do it here though.

> valid if it retains the value that was given to it originally.

Isn't that conclusion precisely what this sentence is countering?

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 09:31:32 -0400

On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote:
...
> have the power to demand that they deploy DKIM at all.
...
I think you are confusing protocol with implementation.  There's nothing the 
prevents receivers from ensuring messages that have been modified after signing 
with an additional From fail verification.

I'm working with someone on an implementation and I think we're going to 
assume one more From than listed in h= when verifying to ensure nothing has 
been added.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Jul 2011 07:13:11 -0700

On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
>> I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
>> Postel's statement, do we?)
>
> You're either liberal in your application of the RFCs, or you're not.  I
> don't see how adding that word improves things here.

well, it keeps the thread going...

>>> DKIM signs and validates the data it is told to and works correctly. So
>>> in this case, DKIM has done its job of delivering a validated domain (the
>>> "d=" value) and, given the semantics of a DKIM signature, essentially the
>>> signer has taken some responsibility for a problematic message.  It is up
>>> to the identity assessor or some other subsequent agent to act on such
>>> messages as needed, such as degrading the trust of the message (or,
>>> indeed, of the signer), or by warning the recipient, or even refusing
>>> delivery.
>>

Huh?  You mean that listing examples is not the same thing as specifying 
directives or even similar to implying obligation?

You mean, an example is merely and example of what is possible?  As in... example.

gosh.

>> (Actually, we'd need yet another policy or authentication method in order
>> to allow the outcome of an identity assessor to be formally expressed.
>> Without it, the quick-n-dirty approach of degrading the trust of a message
>> by tampering with its DKIM verification's results may seem the easiest
>> remedy --much like what Doug et al. proposed.)
>
> If the role of the identity assessor is reputation, and we decide later that
> we want reputation to be relayed to downstream agents, we can extend RFC5451
> by such a registration then.  It doesn't make sense to do it here though.

It might make a great deal of sense to do it here, if we were specifying a 
tightly integrated, inflexible, and self-contained end-to-end reputation service.

But since we aren't, modularity of specification scope is the norm for a reason.

>>> An agent consuming DKIM results needs to be aware that the validity of
>>> any header field, signed or otherwise, is not guaranteed by DKIM.
>>
>> Please, s/validity/reliability/: someone might believe a field is valid if
>> it retains the value that was given to it originally.
>

The word "reliability" has no meaning in this context.  On the other had, 
misunderstandings about implied or actual data validity is /exactly/ the issue 
this text is /intended/ to cover.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 7 Jul 2011 10:18:27 -0400

> A signer can attack a recipient.  A signer cannot attack DKIM's mechanisms.

I would also be interested in seeing an example of a case where adding an 
extra From: line changles the d= in a DKIM signature.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Jul 2011 07:28:01 -0700

On 7/7/2011 7:18 AM, John R. Levine wrote:
> I would also be interested in seeing an example of a case where adding an extra
> From: line changles the d= in a DKIM signature.

no you wouldn't.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jul 2011 10:28:09 -0400

> fact, his weapon of attack.

Right, but the point is that, with DKIM (as Murray says, this attack
can be mounted with or without), the signing domain is relying on its
own reputation, not that of the "fake" From.  That mitigates things in
two ways:

1. There's really no difference between using "d=badguy.com" to sign
"From: [email-masked]" and then adding "From: [email-masked]" later, and
using "d=badguy.com" to sign "From: [email-masked]" in the first place.
No advice in this regard addresses the second case anyway.

2. Signers that do this will quickly get bad reputations, and will
never have had strongly good ones in the first place.  It's never
eBay's reputation that's relevant here anyway.

Given all that, having us describe the problem is sufficient, and
that's exactly what the WG consensus has us do.

Barry, as participant

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 09:22:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, July 07, 2011 6:32 AM

This intentionally causes the verifier to assume what the signer really meant when it signed a message using a single From: field.  That may look safe but it isn't what DKIM actually says.

We might do this for libopendkim somewhere down the line, but it would default "off".

In any case, interesting idea.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 12:43:43 -0400

On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Scott Kitterman
> > assume one more From than listed in h= when verifying to ensure nothing
> > has been added.
> 
> This intentionally causes the verifier to assume what the signer really
> meant when it signed a message using a single From: field.  That may look
> safe but it isn't what DKIM actually says.
> 

It only assumes that the signer signed all the From: fields present in the 
message (note: I said one more than in h=, not two).  I think it's fair to say 
that if someone is sending messages with multiple From: fields (or 
Date:/Subject:) and trying to sign something less than all of them they are 
fairly deep into unsupported territory and shouldn't find any result 
surprising.

I agree it's not exactly what is specified in the protocol, but this is an  
implementation design issue.  I think it's safe.  If the DKIM protocol says I 
can't do something like this, then I think we have a problem with the current 
"describe it and let implementors deal with it" plan.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 13:15:08 -0400

I don't think so, but I'll definitely test it.  If it does, then we won't do it 
that way.

Scott K

On Thursday, July 07, 2011 12:51:06 PM McDowell, Brett wrote:
> Will your "assume one more From than listed in h=" lead to failed
> verifications on messages that actually follow the advice in the RFC to
> list duplicate headers in their h= values?
> 
> > From: [email-masked] [mailto:ietf-dkim-
> > [email-masked]] On Behalf Of Scott Kitterman
> > Sent: Thursday, July 07, 2011 12:44 PM
> > > > I'm working with someone on an implementation and I think we're
> > > > going to assume one more From than listed in h= when verifying to
> > > > ensure nothing has been added.
> > > 
> > > This intentionally causes the verifier to assume what the signer
> > > really meant when it signed a message using a single From: field.
> > > That may look safe but it isn't what DKIM actually says.
> > > 
> > It only assumes that the signer signed all the From: fields present in
> > the message (note: I said one more than in h=, not two).  I think it's
> > fair to say that if someone is sending messages with multiple From:
> > fields (or Date:/Subject:) and trying to sign something less than all of
> > them they are fairly deep into unsupported territory and shouldn't find
> > any result surprising.
> > 
> > I agree it's not exactly what is specified in the protocol, but this is
> > an implementation design issue.  I think it's safe.  If the DKIM
> > protocol says I can't do something like this, then I think we have a
> > problem with the current "describe it and let implementors deal with it"
> > plan.
> > 
> > Scott K
> > http://mipassoc.org/dkim/ietf-list- rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 09:47:52 -0700

> Sent: Thursday, July 07, 2011 9:44 AM

It's definitely not proscribed by DKIM.  All I meant was that you're preventing a signer from deliberately accepting responsibility for a message thus modified (by doing only one "from" in "h="), knowing the risks of doing so.

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 7 Jul 2011 10:51:06 -0600

Will your "assume one more From than listed in h=" lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values?

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 13:26:35 -0400

On Thursday, July 07, 2011 12:47:52 PM Murray S. Kucherawy wrote:
> It's definitely not proscribed by DKIM.  All I meant was that you're
> preventing a signer from deliberately accepting responsibility for a
> message thus modified (by doing only one "from" in "h="), knowing the
> risks of doing so.

Yes.  I can live with that.

Thanks,

Scott K

---

From: Pete Resnick <[email-masked]>
Date: Thu, 7 Jul 2011 12:09:14 -0500

I am perfectly happy with Murray's original (and now, revised) text. 
(Nits still being discussed are entirely up to the WG.) I am not happy 
with Charles's text. Particularly:

>      fields are then added, either by interception or by replay.

It seems like this text is tailor-made to obfuscate who is doing the 
attacking and who is being attacked. It's this distinction that I think 
is the most important to make, and the above text simply does not 
clarify; it muddies the waters. DKIM can only be "deployed to mount a 
variety of attacks" if the recipient has already made the fatal mistake 
of assuming that the existence of a cryptographically valid signature 
*means* that the message is reliable and from a known "good" sender. You 
could have a longer and more detailed discussion in the document about 
how broken it is for a recipient to do such a thing, and put *that* into 
the security consideration, but I don't think it's necessary. The above 
can only obfuscate that very important point, making it out as if it's 
something in the DKIM signing/verifying process that caused the problem.

pr

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Jul 2011 20:30:53 +0100

On Thu, 07 Jul 2011 15:28:09 +0100, Barry Leiba <[email-masked]>  
wrote:

> own reputation, not that of the "fake" From....

I think Murray is wrong. There is no benefit to the Bad Guy in using two  
From: fields if he is not going to sign one of them. By signing, he hopes  
to gain sufficient extra credibility to get through.

> ...  That mitigates things in
> two ways:
>

Oh yes there is! Because identity assessors will undoubtedly give more  
credence to messages where the signature domain is the same as the author  
(i.e.From:) domain, even if they do not go to the extent of doing full  
ADSP, and that is just what the BadGuy hopes will happen. And if  
implementors are not warned of this attack, they will tend to take a  
report of "signed by the domain that DKIM regards as the appropriate  
From:" at its face value and act accordingly.
> eBay's reputation that's relevant here anyway.

Signers who are BadGuys don't give a damn about the reputation of their  
domains. Having displatched a million or so phishes with "d=badguy.com",  
they will abandon that domain and use "d=son-of-badguy.com" for the next  
batch. All that can be said of the reputation of badguy.com is that it is  
a new domain, never seen before (but new domains are appearing all the  
time, and must be assumed more-or-less innocent until proven otherwise).
> that's exactly what the WG consensus has us do.

Yes, but you haven't described the problem. In draft-12, the old 8.14  
described this attack tolerably well (and 8.15 described my 2nd one). On  
that basis I was persuaded to let that draft go (just). But what we have  
now is worse, not better, and I regret that if that remains the case, then  
it can only lead to another appeal to the AD.

---

From: "John R. Levine" <[email-masked]>
Date: 7 Jul 2011 15:41:03 -0400

> (i.e.From:) domain, ...

My spam filters don't do that.  Can you identify specific widely used 
assessors or spam filters that do that?

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Jul 2011 12:56:25 -0700

On 7/7/2011 12:41 PM, John R. Levine wrote:
> My spam filters don't do that.

as well they shouldn't.

Somehow, validating a From: field of [email-masked] does provide 
any obvious basis for giving more 'credence' to the trustworthiness of the 
author or the message content.

but this does raise the question of how many times this point needs to be made?

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 14:06:29 -0700

> Sent: Thursday, July 07, 2011 12:31 PM
> To: DKIM

My favourite counterexample, which I've used many times already, is Mailman.  It doesn't even check DKIM signatures, but you can still fake your way through its authorization process such that a different From: is shown to the user for some MUAs.

This still supports the notion that we fear people will misapply DKIM results as the basis for the attack.  Your proposed changes here won't remedy that.

> ADSP, and that is just what the BadGuy hopes will happen.

Whose?  Mine don't, and the text doesn't support that notion either.

> And if implementors are not warned of this attack, they will tend to take a

Where in the bis document is that notion supported or even suggested?  I think the opposite is done in several places.

> time, and must be assumed more-or-less innocent until proven

Certainly true, and certainly fodder for a BCP for using DKIM or even reputation, but not for the DKIM protocol specification (especially since we declared reputation out-of-scope ages ago).

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Jul 2011 14:19:39 -0700

On 7/7/11 10:09 AM, Pete Resnick wrote:
> DKIM can only be "deployed to mount a
> *means* that the message is reliable and from a known "good" sender.
Strongly disagree!

Security must consider what is meant by verification.  The fact that a 
signature appears valid although _significant_ visible aspects of the 
message's author, subject, date, etc can be altered represents a clear 
threat and a present danger in the verification process that also 
threatens policy layers such as ADSP!

Ensuring verification is not deceptive does not represent a layer 
violation.  Expecting consumers of DKIM results to guess whether 
critical verification aspects were checked is a layer and a trust 
violation!  A layer violation since DKIM MUST understand critical 
aspects of the verification process!  A violation in trust since 
offering a verification pass for a message with multiple From header 
fields is clearly negligent.

Had the pre-pended exploit not been missed in the original threat 
review, the verification process would NOT have over looked this serious 
failing.  The expressed goal was to ensure subsequent processes not be 
DKIM "aware" for safe and incremental DKIM deployment.

While there are many ways a malefactor might attempt to deceive 
recipients, due to the verification flaw any false expectation that DKIM 
used by a phished domain offers protection places recipients in even 
greater peril.  This may even invite the phishing that DKIM was intended 
to help mitigate.  With this verification flaw, reputation CAN NOT offer 
protection when misapplied to grant acceptance of deceptive messages.

-Doug

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2011 22:21:52 -0000

>verifications on messages that actually follow the advice in the RFC
>to list duplicate headers in their h= values?

The RFC also says you shouldn't sign messages that aren't RFC 2822.  So
pick your poison.

I have to say it's a little surreal to have these arguments about what
changes to make to avoid the horrors of a duplicate From: attack that
is and likely will always be entirely hypothetical, when we can't even
get our act together to deprecate the l= option, including l=0.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Jul 2011 18:15:28 -0700

> get our act together to deprecate the l= option, including l=0.

It is. This group finds it much easier to add cruft (or argue that
cruft should be added) than to remove cruft.

But we're past the point where we can improve things on
this round of the spec. Time to move on.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jul 2011 21:57:30 -0400

> something in the DKIM signing/verifying process that caused the problem.

I don't quite follow.  There seems to be this effort to "remove a bad" 
(erroneous or not) connotation about DKIM (for some rubber stamping 
reason) when the facts are there is a strong possibility of a problem 
only because  DKIM raises the bar or something in regards to "email."

I strongly believe the mail industry never had a problem (at least I 
don't ever remember an exploit) because most, if not all, was designed 
to read mail for one FROM.  There is no need to continue reading, 
reading from the bottom either, normal sequential reading for the 
From: field found.  In other words, I doubt any software has a 
COLLECTION concept for From fields. Why when there there was no need 
for it.  So the first one read was the one shown or the one used for 
gateway transformations, which is a strong point here -  not every 
backend mail system stores mail in pure RFC x822/5322 format.

I would like to see one software, any software that holds a structure 
for multiple froms?  I doubt it exist.

Hence, that is why we never saw the problem.

But now with DKIM, it changes the issues somehow.  DKIM allows for a 
perfect cryptographic valid signature for any bits it ignorantly signs 
and that includes all headers.  In fact, I know of one API that 
without any IMPLEMENTATION controls - it will, by default, sign all 
headers, including if there exist multiple From: headers.

You MUST recode the API if you want to invalidate the signing of an 
illegal RFC5322 message with multiple froms.  Ironically, the same API 
did make a change to check for multiple froms during the verification 
process, but it did nothing on the signing side.  I guess that might 
be ok when the design presumption is that the implementation of the 
API will make sure the input is valid during signing.

In any case, I think the protocol should include both a functional and 
technical requirement for a ONE FROM criteria during the signing and 
verification process.

I agree with Doug that at some point DKIM will have some "meaning" for 
validity and I think it is best that DKIM doesn't continue signing or 
verify an illegal RFC5322 message even if the mechanism allows for a 
valid abstract signature.

Finally, in my implementation opinion, the only thing that makes me 
wonder is how far do we go to address the legacy verifiers who are not 
going to check for multi-from message.  Do we add the h=From*n+1 kludge?

Well, we decided that as long as we allow the h= setting to be 
flexible for the operator, then they can add it (we add it by default) 
as a short term solution.  In the long term, I don't think it has to 
be used, but then again, I am strongly basing that that most DKIM 
implementations will eventually use a ONE FROM RULE criteria for both 
signing and verifying.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Jul 2011 18:46:40 -0700

> get our act together to deprecate the l= option, including l=0.
John,

When a domain is found using the l=0 option, this provides a basis to 
assign the domain with no positive reputation.  In other words, this 
domain's signature can not be a basis for acceptance hence reputation is 
able to cure this ill.

The specification of SHOULD ensure messages are RFC5322 valid must not 
imply there are also valid reasons where these messages need not comply 
with checks for multiple header fields limited to single occurrences.  
There is no reason to have these checks be an optional configuration as 
they are in OpenDKIM.  In light of conversations by influential 
individuals that DKIM verifier's role is NOT to make these checks, it 
therefore becomes essential to clarify the specifics of this particular 
requirement as a MUST.

Skipping these checks invites harm.   In addition, these checks have not 
been defined as the duty of SMTP.  Also, the DKIM verifier making this 
check will not assure RFC5322 compliance, since not reporting a valid 
signature is to be considered not being signed.  The difference is that 
acceptance based upon trust given a signing domain is not easily 
exploited when these checks are made by the DKIM verifier.  
Unfortunately, the norm is not to make these checks because only DKIM 
invites the possible exploit.  DKIM MUST accept the role of preventing 
the exploit it invites.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 22:41:10 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Thursday, July 07, 2011 6:47 PM

This is logically equivalent to saying SSL or TLS has to ensure the validity of the payload it is securing, because since that payload has been secured, people will assume it's also valid.  Will you be taking your fight to the TLS working group as well, then?

Otherwise, this is merely a repetition of the same argument that got us the DISCUSS in the first place.  One might even call it a replay attack...

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jul 2011 11:52:01 +0100

> something in the DKIM signing/verifying process that caused the problem.

If you do not like the text, then please suggest an alternative. I have  
already made two attempts.

There are essentially two things that I wish to see stated. Both were  
plainly stated in 8.14 of version-12, which is what this WG originally  
submitted.

1. The fact that DKIM choose headers to sign from the bottom up (for good  
reason) facilitates certain attacks (not against DKIM, but certainly  
against somone/something) needs to be drawn to the attention of  
implementors of identity assessors, so that they can take appropriate  
action.

2. The fact that an attacker (whilst following DKIM to the letter) can use  
it, in conjunction with duplicated headers, to add credence to his message  
also needs to be drawn to their attention.

Any wording that makes those two points will be acceptable to me.

I would have much preferred normative wording to avoid this problem  
entirely, but I can acdept fixing it in the Security Considerations if it  
is done properly there. But I see that others (Doug and now Hector) are  
still pressing for that, so we may presume that they would oppose complete  
lack of mention of these two items, so that makes three of us.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jul 2011 11:59:07 +0100

On Thu, 07 Jul 2011 22:06:29 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> My favourite counterexample, which I've used many times already, is  
> Mailman.  It doesn't even check DKIM signatures, but you can still fake  
> your way through its authorization process such that a different From:  
> is shown to the user for some MUAs.

Can you please give me a pointer to that?
>
> This still supports the notion that we fear people will misapply DKIM  
> results as the basis for the attack.  Your proposed changes here won't  
> remedy that.
>

If DKIM is not intended to give added credance to messages, then what on  
earth is its purpose at all. Yes, it needs to be interpreted with care and  
understanding, and our Security Considerations are the vehicle for  
improving that understanding.

I suspect may assessors will use a scoring system (like Spamassassin),  
where a signed message, even from a totally unknown domain, will add some  
positive contribution.

> Certainly true, and certainly fodder for a BCP for using DKIM or even  
> reputation, but not for the DKIM protocol specification (especially  
> since we declared reputation out-of-scope ages ago).

Yes, it is out of scope to suggest mentioning it, but that has not stopped  
people from using it to undermine my case (which it doesn't if the badguy  
is using throwayay domains).

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 08 Jul 2011 13:43:21 +0200

> well, it keeps the thread going...

You /have/ to be liberal, but that can be limited in degree and in
time.  An app must be liberal in what it accepts, not only because a
specification is subject to some variance in interpretation, but also
because of unavoidable time differences in its adoption.  Since no RFC
can be transmitted faster than the speed of light, a host which
adopted an RFC at time t0 (see graph) has to wait at least until time
t2 before a compliant signal from a distant source may reach it.

 ^
 | time
 |             X________________t2 (RFC-compliant signals
 |             |\                   may reach the host
 |             | \                  from the distant source)
 |             |  \
 |             |   \
 |             |    \      .
 |             |     \    .
 |             |      \  .
 |     .       |       \________t1 (RFC reaches signal source)
 |      .      |       /
 |       .     |      /
 |        \    |     /
 |         \   |    /
 |          \  |   /
 |           \ |  /
 |            \| /
 |             \/_______________t0 (RFC reaches the host)
 |             /\
 |            /| \
 |           / |  \
 |\         /  |   \
 | \       /   |    \
 |  \     /    |     \
 |   \   /     |      \
 |    \ /      |       \                                space
 +-----X-------X--------X------------------------------------>
    RFC-     host     signal
    Editor            source

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 8 Jul 2011 05:46:46 -0600

I would agree with your statement if you put the word "deployers" between DKIM and MUST.

> invites the possible exploit.  DKIM MUST accept the role of preventing the
> exploit it invites.

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 8 Jul 2011 06:05:49 -0600

> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, July 07, 2011 6:22 PM
> 
> The RFC also says you shouldn't sign messages that aren't RFC 2822.  So pick
> your poison.
> 
> I have to say it's a little surreal to have these arguments about what changes

John, this particular part of the discussion is not about changing the RFC or DKIM implementations, only changing deployment configuration practices.

> to make to avoid the horrors of a duplicate From: attack that is and likely will
> always be entirely hypothetical,

Doug, has Trend Micro actually demonstrated this attack (and the recommended counter measures) on the wire?  If not, I suggest you do so.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Jul 2011 06:48:49 -0700

> Sent: Friday, July 08, 2011 3:59 AM
> To: DKIM

The source code.  I also recall looking at Spamassassin and/or procmail, and majordomo, and finding the same thing.

> earth is its purpose at all.

That question is answered numerous times in the draft, namely the Abstract and Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and other parts of 8).

> Yes, it needs to be interpreted with care and

Indeed.

> where a signed message, even from a totally unknown domain, will add some

The text in the current draft spells that out as a bad idea.  Moreover, I see on Apache's website that right now Spamassassin penalizes a message 0.001 for being signed, but removes that penalty if the signature verifies.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 06:53:22 -0700

> That question is answered numerous times in the draft, namely the Abstract and Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and other parts of 8).

Perhaps I'm missing something basic that makes clear the value of this thread?

Hashing and re-hashing first principles of DKIM hardly seems useful, at this 
stage.  If someone has trouble understanding the specification, this forum is 
not intended for tutorials, particularly not tutorials that constantly repeat 
first principles.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Jul 2011 06:54:43 -0700

> Sent: Friday, July 08, 2011 3:52 AM
> To: DKIM

That's not part of what DKIM tells an assessor, nor is the list of signed header fields, so I don't see why that would be a useful thing to highlight.  For example, if a message contains two Subject: fields, the assessor doesn't know which was signed; could be neither.  It still gets an SDID out of the verification and nothing more (possibly not even that if the signature failed).

> also needs to be drawn to their attention.

Same answer.  All you get is an SDID, if that.  The credence you add to the content comes from what you do with that value.  An assessor that gives a thumbs-up to any signed message without at least considering which SDID signed it is faulty.  But how the assessor works is not in scope here.

---

From: "John R. Levine" <[email-masked]>
Date: 8 Jul 2011 10:05:53 -0400

I'm not seeing much agreement on any changes to Murray's final draft, so 
may I suggest that it's good enough and we should ship it?  The potential 
benefit of the proposed changes doesn't impress me as worth the amount of 
argument they're provoking.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 07:20:19 -0700

> That's not part of what DKIM tells an assessor, nor is the list of signed header fields, so I don't see why that would be a useful thing to highlight.  For example, if a message contains two Subjec…

It simply is not productive to pursue terse, abstract claims of threats, absent 
detailed technical description, detailed explanation of how it is relevant to 
DKIM, and some indication of concern for that threat among a range of people

The main effect of responding to isolated, terse concerns is to create a record 
that can be read as giving credence to those threats.

d/
-- 

   Dave Crocker

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 8 Jul 2011 07:41:47 -0700

+1

Having the same argument again and again hasn't and won't convince anyone to change their minds.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jul 2011 18:06:07 +0100

On Fri, 08 Jul 2011 13:05:49 +0100, McDowell, Brett  
<[email-masked]> wrote:

> John, this particular part of the discussion is not about changing the  
> RFC or DKIM implementations, only changing deployment configuration  
> practices.

Exactly so. All I am trying to do is to ensure that those who engage in  
deployment should be warned of these particular dangers, but everyone is  
trying to shout me down.

I have posted a wording (and even a revision of same). Do you agree with  
or oppose that wording. Please say.
>> always be entirely hypothetical,

I think is is clear that these attacks will work if deployers fail to  
watch out for them. The only question is how long it will take the Bad  
Guys to spot the opportunities (and for sure they WILL spot them - sooner  
probably than later).

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jul 2011 17:58:36 +0100

On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> [mailto:[email-masked]] On Behalf Of Charles Lindsey

> That's not part of what DKIM tells an assessor, nor is the list of  
> signed header fields, so I don't see why that would be a useful thing to  
> highlight.  For example, if a message contains two Subject: fields, the  
> assessor doesn't know which was signed; could be neither.  It still gets  
> an SDID out of the verification and nothing more (possibly not even that  
> if the signature failed).

Of course that's not what  DKIM tells the assessor; it is part of what is  
written in our document. But the significance of that fact when taken in  
conjunction with non 5322-compliance is not obvious (evidently so, because  
it took several years for some member of this list to spot it). Hence the  
reason why it is essential to draw explicit attention to it.

And as for the "list of signed header fields", I expect assessors to be  
told more than that (the SDID in only the minimal reporting requirement).  
Surely we all agree that an assessor would like to know if an 'l=0' was  
given, for example. But the point is moot, since the assessor also has the  
whole message before it, and can explore it himself as needed.

> Same answer.  All you get is an SDID, if that.  The credence you add to  
> the content comes from what you do with that value.  An assessor that  
> gives a thumbs-up to any signed message without at least considering  
> which SDID signed it is faulty.  But how the assessor works is not in  
> scope here.

And the first thing an assessor is likely to do is to look whether the  
SDID bears any resemblance to the AUID. If it does not, his suspicions  
will be aroused and he will want to examine further. But if it agrees (or  
appears to), and if the SDID is from a domain that has not (yet) acquired  
a bad reputation, then he may let it go.

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Jul 2011 13:30:51 -0400

+1

To me, the protocol requires a highlighted explicit ONE FROM signing 
and verifier rule. It SHOULD NOT continue to sign a multi-from 
message, and it SHOULD invalidate the verification of a multi-from 
message.

Anything above that is SWAGGING and exploratory in nature and a 
consideration only to address legacy signers and verifiers, which 
includes receivers or internal mail creators don't allow multiple from 
headers.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 8 Jul 2011 12:51:39 -0500

I want to try to be precise, which I don't think Charles is being with 
his below two sets of "facts". Let me try to clarify:

> implementors of identity assessors, so that they can take appropriate

What Charles have written above is not true, or at the very least 
extremely imprecise and confusing. Try this:

1a. The fact that DKIM signers can (optionally) sign a message in such a 
way that header fields can be added to the top of the message by 
intermediaries without invalidating the signature means that unsigned 
header fields can appear at the top of a validly signed message needs to 
be drawn to the attention of implementors...

1b. The fact that DKIM signers can sign header fields with all manner of 
unverified data in them, including header fields that might violate the 
syntax requirements of RFC 5322, without invalidating the signature 
means that header fields with unverified data can appear in an validly 
signed message needs to be drawn to the attention of implementors...

I *believe* what I said contains all of the information that Charles 
wrote in his #1. If I missed something, please say.

But I also believe that the current security considerations section 
*says* all that. If you think it doesn't capture something in the above 
two statements, please say.

> also needs to be drawn to their attention.

That one is simply bogus. The document repeatedly (and correctly) states 
that having a DKIM signature *does not*, and *ought not*, in an of 
itself, add any credence to a message. If that needs to be made clearer, 
I'm all for it. But I think it is currently perfectly clear in the document.

In any event, neither of Charles suggested additions captured what I 
have written above. I believe the current text does.

pr

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 Jul 2011 11:26:55 -0700

> t2 before a compliant signal from a distant source may reach it.
Alessandro,

Ensuring multiple header fields stipulated as occurring once not provide 
a deceptive DKIM result does not alter the intent of DKIM validation.  
It is important for DKIM compliance to ensure deceptive and invalid 
header field instances are excluded by the verification process from 
returning valid signatures.  Clarifying this stipulation to establish 
proper verification layering will not raise interchange issues.

These checks must be part of any DKIM compliance certification program 
or recipients are at risk.  Language in the base specification must make 
this requirement clear.  After all, it was missed and exploited with 
DKIM's implementation used by the WG mailing list, if anyone needs examples.

It would be unwise to invest either trust or services in an easily 
exploited system.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Jul 2011 00:06:10 -0400

> It would be unwise to invest either trust or services in an easily 

Hi Doug,

I can imagine in the ideal DKIM integrated world where One From is 
signed and the verifier will only validate One From and the Display 
Renderer only using One From validated by DKIM, there would some 
design considerations where the all parts will eliminate or ignore any 
additional From headers, if any, that is not part of the successful 
validation.

For example:

1) The signer gets a proper RFC5322 message with only one 5322.From 
header:

    From: GoodGuy

Signs the message and its out into the mail stream.

2) Some how, one way or another, additional 5322.From headers are 
injected into the message headers, so now you have:

    From: BadGuy1
    From: BadGuy2
    From: GoodGuy
    From: BadGuy3

and it doesn't matter what order.

3) The in the ideal DKIM verifier, it will test each From:

    - Hashing From=BadGuy1, the signature fails.

    - It sees another from=BadGuy2, tries that in the hash, it fails.

    - It sees another from=GoodGuy, tries that in the hash, it validates
      and he stops here.

So the question, as I see it, is what is reported?

    - Validate, but has suspicious invalid extra From?
    - Validate, removes any invalid extra From? or,
    - Invalidates due to extra from headers?

In my view, its possible since the verification is local, if its using 
a local display renderer, it could just show the valid from and ignore 
the rest.

The problem that I see is when there is store and forward, i.e. pop3. 
  What does the POP3 server do here as it prepares the data to be 
transmitted to the pop3 client? Should it strip the invalid extra from 
headers?  Or do we assume the POP3 client or rather the offline mail 
reader will be multi-from security DKIM aware like the online system?

In short, the host system and/or verifier/receiver can do a lot here, 
but I personally don't like to be playing these games and we don't 
know how other software will behave, so I would prefer to just kick 
out damaged mail - even when its possible to validate one of the 
multiple froms.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 10 Jul 2011 13:59:35 +0100

On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick <[email-masked]>  
wrote:

> extremely imprecise and confusing....

(Note that I was not proposing a specific text for inclusion but rather  
indicating what needed to be covered somehow)

> ... Try this:

Well that's getting nearer, but it's not quite there yet. How about:

Implementors of identity assessors and other agents need to be aware that  
DKIM signers can sign a message in such a way some header field at the top  
of the message (whether present originally or added later by an  
intermediary) is unverified, even though another instance of that field  
further down is signed, and even where the presence of such multiple  
instances violates RFC 5322. This can lead to a variety of attacks which  
take advantage of lenient MUAs which neither display nor warn about the  
duplicated header field.

I hope this makes it clear that the attack is really against the lenient  
MUA (even though DKIM has provided the opportunity to mount it). But I am  
particularly concerned to be clear that is is not just intermediaries that  
are the Bad Guys - malicious signers are, if anything, a more serious  
problem. Hence my sentence in brackets. You could leave that out, but  
please do NOT suggest that it is only "added" headers that are the problem.
> two statements, please say.

The present text does not highlight the feature of section 5.4.2 that  
enables this problem, and it is far from obvious that it so enables it,  
given that DKIM was around for many years brfore someone spotted it.
> I'm all for it. But I think it is currently perfectly clear in the  

Then what on earth IS the purpose of DKIM? There is an expectation that  
identity assessors will treat properly signed messages more favourably  
than signed ones (just how thay do that, and what other information they  
take into account is carefully not said). The malicious signer is hoping  
that the treatment his scam gets is favourable enough to get past the  
assessor unscathed and so reach that lenient MUA, where the real damage  
happens.

My main concern is that malicious signers and malicious intermediaries are  
both recognized (or if not that neither is explicitly mentioned). IMHO is  
is the malicious signers that are more insidious, since the 'h=from:from:'  
offers no protection against them.

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 Jul 2011 09:55:33 -0400

Why not just keep it simple, less confusing, less challenging on 
competing mind games, that DKIM can't not fully protect again unsigned 
Author Addresses and its highly recommendation that DKIM signers, 
verifiers and Mail Readers to kick out, reject, destroy, do not pass 
on these sort of Invalid messages?

We should not leave any opening for what we don't know about.  We 
can't control it, and I doubt we would be able to address all legacy 
systems.

Use KISS:

      DKIM has no advice on how messages can be alter or viewed
      after mail is signed and transmitted but we recommend that
      you don't contribute by  making sure only one FROM
      exist during signing and verification.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jul 2011 20:39:08 -0700

> Sent: Sunday, July 10, 2011 6:00 AM
> To: DKIM
> Cc: Pete Resnick

Too specific.  All along I've been worried about naming specific attack vectors as such a list could be taken as exhaustive.  Try this:

"Agents that evaluate or apply DKIM output need to be aware that a DKIM signer can sign messages that are malformed (e.g., violate RFC5322), or become malformed in transit.  Such an action might constitute an attack against a receiver, especially where additional credence is incorrectly given to a signed message without evaluation of the signer.  Moreover, a verifier would be incorrect to infer that all instances of a header field are signed just because one is.  Agents will need to account for these issues when deciding how to apply DKIM results to message, especially when displaying them to users."

I think that covers just about everything.  I don't agree with calling out Section 5.4.2 specifically, as there could be some other way to mount a receiver attack we haven't seen yet; calling attention there might divert it from other places where it's also needed.

I also don't think this is strictly necessary because the text we've proposed for 8.15 covers it already, but I find this to be a palatable compromise.

> take into account is carefully not said).

You've answered the question yourself there (though I assume the second "signed" was supposed to be "unsigned").

> The malicious signer is hoping

I think the above text covers that as well.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jul 2011 21:53:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Sunday, July 10, 2011 8:39 PM
> To: Charles Lindsey; DKIM
> Cc: Pete Resnick
> "Agents that evaluate or apply DKIM output need to be aware that a DKIM
> signer can sign messages that are malformed (e.g., violate RFC5322), or
> become malformed in transit.  Such an action might constitute an attack
> against a receiver, especially where additional credence is incorrectly
> given to a signed message without evaluation of the signer.  Moreover,
> a verifier would be incorrect to infer that all instances of a header
> field are signed just because one is.  Agents will need to account for
> these issues when deciding how to apply DKIM results to message,
> especially when displaying them to users."

Actually, let me revise that a bit:

"Agents that evaluate or apply DKIM output need to be aware that a DKIM signer can sign messages that are malformed (e.g., violate RFC5322), or become malformed in transit, or contain content that is not true or valid.  Such an action might constitute an attack against a receiver, especially where additional credence is incorrectly given to a signed message without evaluation of the signer.  Moreover, an agent would be incorrect to infer that all instances of a header field are signed just because one is.  Agents will need to account for these issues when deciding how to apply DKIM results to message, especially when displaying them to users."

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Jul 2011 11:51:36 +0100

On Mon, 11 Jul 2011 05:53:58 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> become malformed in transit, or contain content that is not true or  
> valid.  Such an action might constitute an attack against a receiver,  
> especially where additional credence is incorrectly given to a signed  
> message without evaluation of the signer.  Moreover, an agent would be  
> incorrect to infer that all instances of a header field are signed just  
> because one is.  Agents will need to account for these issues when  
> deciding how to apply DKIM results to message, especially when  
> displaying them to users."

OK, there is much good stuff in that. In particular, it makes it clear  
that Bad Stuff can originate from the signer as well as from  
men-in-the-middle and replayers. But I am still concerned that multiple  
occurrences of "singleton" headers fields are not explicitly mentioned,  
even as just one possible example. So perhaps, just before the last  
sentence:

"... , in particular if that field was not supposed to occur more than  
once."

After all, you were seemingly happy to mention that particular trap in  
8.14 in draft-12.

Not sure about the word "incorrectly", but s/without evaluation/without  
adequate evaluation/ might make your point better. Though I expect, of the  
millions of perfectly legitimate domains that will exist without special  
recognition in any reputation system, it will be hard to spot a newly  
appearing 'badguy' one.

I still don't think that paragraph is what we really need, but I will  
withold judgement on that until I see how it gets incorporated into the  
other bits of text that are around.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Jul 2011 06:56:26 -0700

> Sent: Monday, July 11, 2011 3:52 AM
> To: DKIM
> even as just one possible example.

That's what the "violate RFC5322" and "displaying them to users" covers.  Again, I don't think it's smart to name a specific attack in case it leads one to believe that it's the only interesting one.

> After all, you were seemingly happy to mention that particular trap in

That this stuff is in there at all is compromise to me, so you're not quite accurate in your use of "happy".

> recognition in any reputation system, it will be hard to spot a newly

I don't think conversation about how reputation is applied is in scope; some systems could be used to give preferential treatment to good actors, some negative treatment to bad actors, some both.

> other bits of text that are around.

Given that today's the deadline, we will have to go with something like this or nothing at all (which in fact I would prefer because I think all of this is adequately covered by existing text, and I believe consensus and the AD concurs), so withhold judiciously.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Jul 2011 10:29:46 -0700

On Jul 11, 2011, at 6:56 AM, Murray S. Kucherawy wrote:

> Given that today's the deadline, we will have to go with something like this or nothing at all (which in fact I would prefer because I think all of this is adequately covered by existing text, and I believe consensus and the AD concurs)

+1 to letting the clock run out.  What we have is more than sufficient.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Jul 2011 20:02:30 +0100

> Given that today's the deadline, we will have to go with something like  
> this or nothing at all (which in fact I would prefer because I think all  
> of this is adequately covered by existing text, and I believe consensus  
> and the AD concurs), so withhold judiciously.

Essentially, my concern is that an implementor reading this section should  
be able to infer the nature of the particular attack I have described (the  
one where the signer is the BadGuy himself using a throwaway domain),  
including spotting how and why it worked and how to protect against it.

Having now read your paragraph in the context of the rest of the material  
in that section, I think it just about passes that test, but only by the  
thinnest of margins, so I will let it go.

But as a piece of technical writing that section is a total mess, talking  
around the problem, and seemingly more concerned with enabling timid  
implementors to pass the buck around amongst themselves that with  
protecting the ultimate users.

I see Doug has written a detailed critique of it, and I fully endorse most  
of what he has said.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Jul 2011 14:27:51 -0700

> I see Doug has written a detailed critique of it, and I fully endorse most
Charles,

IMHO, the issue was never about throw-away domains. Without universal 
adoption of the recently invented and poorly considered 'h=' double 
tagging hack, any domain reputation based upon not sending spam or 
spoofing messages place all recipients of messages from ANY domain at 
risk whenever illegal header fields are ignored during DKIM validation 
regardless of ADSP like policy being applied.

The lack of universal adoption of 'h=' double tagging hack places 
senders and recipients at risk.  This risk should be seen as an assault 
against the entire DKIM protocol.  Steps needed to mitigate the risk 
represent less process and resource overhead than the poorly considered 
double tagging hack.  The double tagging hack might assist in a 
transition toward better validation enforcement, but without invalid 
header checks made during validation, the requisite protections that 
might have been afforded through ADSP like policy or through signing 
domain reputation is lost.

-Doug