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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> 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
> 
> We have a week.  Murray will be posting the update (-14) very soon.
> Please review and comment by 11 July.

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


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

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

[John R. Levine]

>> 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, jo...@iecc.com, 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

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

[J.D. Falk]

On Jul 2, 2011, at 9:58 PM, John R. Levine wrote:

>>> 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.

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


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

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

[Steve Atkins]

On Jul 2, 2011, at 9:08 PM, Murray S. Kucherawy wrote:

>> We have a week.  Murray will be posting the update (-14) very soon.
>> Please review and comment by 11 July.
> 
> 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

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

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

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

[Hector Santos]

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




Barry Leiba wrote:
> 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
> 
> 




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

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

[Jeff Macdonald]

On Sat, Jul 2, 2011 at 11:26 PM, Barry Leiba  wrote:

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

+1 to -14 update.


-- 
Jeff Macdonald
Ayer, MA

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

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

[Charles Lindsey]

On Sun, 03 Jul 2011 04:26:49 +0100, Barry Leiba   
wrote:

> 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.

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 v

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

[Barry Leiba]

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  wrote:
...
   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.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Barry Leiba
> 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
> 
> 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:

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.


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 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.

   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 need to revisit that posture when
   incorporating DKIM, especially when considering matters of potential
   attacks such as those described.

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

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

[Dave CROCKER]

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

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

[SM]

Hi Charles,
At 04:17 06-07-2011, Charles Lindsey wrote:
>Here, therefore, is my proposed revision of 8.15 (which still includes
>most of Pete's new text).

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

Regards,
-sm 

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

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

[Hector Santos]

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.

--


Barry Leiba wrote:
> 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  wrote:
> ...
>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.
> 
> 
> 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
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

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


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

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

[Hector Santos]

Murray S. Kucherawy wrote:

> 8.15.  Attacks Involving Extra Header Fields
> 
>...
>
>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).

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.

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


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

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

[Douglas Otis]

On 7/6/11 9:31 AM, Barry Leiba wrote:
> 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  wrote:
> ...
> 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.
>
>
> 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,

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Douglas Otis]

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

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

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

[John R. Levine]

> When DKIM signatures serve as a basis for acceptance, ...

Since they don't, can we skip the rest of the screed?

Regards,
John Levine, jo...@iecc.com, 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

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

[Tony Hansen]

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Michael Deutschmann]

On Wed, 6 Jul 2011, Barry Leiba 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.

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 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Charles Lindsey]

On Wed, 06 Jul 2011 21:51:49 +0100, Hector Santos  wrote:

> 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.
>

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.

> 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.

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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Charles Lindsey]

On Wed, 06 Jul 2011 17:31:47 +0100, Barry Leiba   
wrote:

> 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   
> wrote:
> ...
>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.
>
>
> 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:

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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Alessandro Vesely]

On 06/Jul/11 20:34, 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.

A few comments:

> 8.15.  Attacks Involving Extra Header Fields
> 
>[...]
> 
>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).

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

>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.

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

>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.

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.)

>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.

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

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

[Dave CROCKER]

On 7/6/2011 10:59 PM, Michael Deutschmann wrote:
> 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.


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

d/
-- 

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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Thursday, July 07, 2011 3:09 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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.

> 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.

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.

> 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?
> [...]

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.


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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Alessandro Vesely
> Sent: Thursday, July 07, 2011 4:56 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

> >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.
> 
> 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.

>  (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.

> >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.

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

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

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

[Scott Kitterman]

On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote:
...
> 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.
...
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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Dave CROCKER]

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.
>>
>> 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.

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.
>
 > Isn't that conclusion precisely what this sentence is countering?

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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[John R. Levine]

> On 7/6/2011 10:59 PM, Michael Deutschmann wrote:
>> 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.
>
> 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,
John Levine, jo...@iecc.com, 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

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

[Dave CROCKER]

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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Barry Leiba]

> 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.

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: x...@badguy.com" and then adding "From: x...@ebay.com" later, and
using "d=badguy.com" to sign "From: x...@ebay.com" 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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Scott Kitterman
> Sent: Thursday, July 07, 2011 6:32 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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

In any case, interesting idea.

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

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

[Scott Kitterman]

On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org
> > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
> > Sent: Thursday, July 07, 2011 6:32 AM
> > To: ietf-dkim@mipassoc.org
> > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> > 
> > 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.
> 
> We might do this for libopendkim somewhere down the line, but it would
> default "off".
> 
> In any case, interesting idea.

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Scott Kitterman]

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?
> 
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> > boun...@mipassoc.org] On Behalf Of Scott Kitterman
> > Sent: Thursday, July 07, 2011 12:44 PM
> > To: ietf-dkim@mipassoc.org
> > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> > 
> > On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
> > > > -Original Message-
> > > > From: ietf-dkim-boun...@mipassoc.org
> > > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
> > > > Sent: Thursday, July 07, 2011 6:32 AM
> > > > To: ietf-dkim@mipassoc.org
> > > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group
> > > > review
> > > > 
> > > > 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.
> > > 
> > > We might do this for libopendkim somewhere down the line, but it would
> > > default "off".
> > > 
> > > In any case, interesting idea.
> > 
> > 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
> > ___
> > NOTE WELL: This list operates according to
> > http://mipassoc.org/dkim/ietf-list- rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Scott Kitterman
> Sent: Thursday, July 07, 2011 9:44 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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.


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

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

[McDowell, Brett]

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?


> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Scott Kitterman
> Sent: Thursday, July 07, 2011 12:44 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
> > > -Original Message-
> > > From: ietf-dkim-boun...@mipassoc.org
> > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
> > > Sent: Thursday, July 07, 2011 6:32 AM
> > > To: ietf-dkim@mipassoc.org
> > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group
> > > review
> > >
> > > 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.
> >
> > We might do this for libopendkim somewhere down the line, but it would
> > default "off".
> >
> > In any case, interesting idea.
> 
> 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
> ___
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-
> rules.html

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

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

[Scott Kitterman]

On Thursday, July 07, 2011 12:47:52 PM Murray S. Kucherawy wrote:
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org
> > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
> > Sent: Thursday, July 07, 2011 9:44 AM
> > To: ietf-dkim@mipassoc.org
> > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> > 
> > 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.
> 
> 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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Pete Resnick]

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:

On 7/7/11 5:08 AM, Charles Lindsey wrote:

>  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.
>

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
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

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

[Charles Lindsey]

On Thu, 07 Jul 2011 15:28:09 +0100, Barry Leiba   
wrote:

>> 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.
>
> 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

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:
>
> 1. There's really no difference between using "d=badguy.com" to sign
> "From: x...@badguy.com" and then adding "From: x...@ebay.com" later, and
> using "d=badguy.com" to sign "From: x...@ebay.com" in the first place.
> No advice in this regard addresses the second case anyway.

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.
>
> 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.

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).
>
> Given all that, having us describe the problem is sufficient, and
> 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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[John R. Levine]

> 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, ...

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

Regards,
John Levine, jo...@iecc.com, 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

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

[Dave CROCKER]

On 7/7/2011 12:41 PM, John R. Levine wrote:
>> 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, ...
>
> My spam filters don't do that.


as well they shouldn't.

Somehow, validating a From: field of bad-ac...@bad-host.example.com 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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Thursday, July 07, 2011 12:31 PM
> To: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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.

> 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.

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
> report of "signed by the domain that DKIM regards as the appropriate
> From:" at its face value and act accordingly.

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

> 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).

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).


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

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

[Douglas Otis]

On 7/7/11 10:09 AM, Pete Resnick wrote:
> 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.
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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[John Levine]

>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?

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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Steve Atkins]

On Jul 7, 2011, at 3:21 PM, John Levine 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?
> 
> 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.


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

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

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

[Hector Santos]

Pete Resnick wrote:
> 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:
> 
> On 7/7/11 5:08 AM, Charles Lindsey wrote:
> 
>>  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.
>>
> 
> 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

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.


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



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

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

[Douglas Otis]

On 7/7/11 3:21 PM, John Levine 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?
> 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.
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

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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Douglas Otis
> Sent: Thursday, July 07, 2011 6:47 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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...

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

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

[Charles Lindsey]

On Thu, 07 Jul 2011 18:09:14 +0100, Pete Resnick   
wrote:

> 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:
>
> On 7/7/11 5:08 AM, Charles Lindsey wrote:
>
>>  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.
>>
>
> 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.

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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Charles Lindsey]

On Thu, 07 Jul 2011 22:06:29 +0100, Murray S. Kucherawy  
 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.
>
>> 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.
>
> Whose?  Mine don't, and the text doesn't support that notion either.

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.

>> 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).
>
> 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).


-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Alessandro Vesely]

On 07/Jul/11 16:13, Dave CROCKER wrote:
> 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...

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
 | Xt2 (RFC-compliant signals
 | |\   may reach the host
 | | \  from the distant source)
 | |  \
 | |   \
 | |\  .
 | | \.
 | |  \  .
 | .   |   \t1 (RFC reaches signal source)
 |  .  |   /
 |   . |  /
 |\| /
 | \   |/
 |  \  |   /
 |   \ |  /
 |\| /
 | \/___t0 (RFC reaches the host)
 | /\
 |/| \
 |   / |  \
 |\ /  |   \
 | \   /   |\
 |  \ /| \
 |   \   / |  \
 |\ /  |   \space
 +-X---XX>
RFC- host signal
Editorsource

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

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

[McDowell, Brett]

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

> -Original Message-
> 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.


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

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

[McDowell, Brett]

> -Original Message-
> From: John Levine [mailto:jo...@iecc.com]
> Sent: Thursday, July 07, 2011 6:22 PM
> 
> >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?
> 
> 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.

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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Friday, July 08, 2011 3:59 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> > 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?

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

> If DKIM is not intended to give added credance to messages, then what on
> 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
> understanding, and our Security Considerations are the vehicle for
> improving that understanding.

Indeed.

> 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.

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

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

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

[Dave CROCKER]

On 7/8/2011 6:48 AM, Murray S. Kucherawy wrote:
>> If DKIM is not intended to give added credance to messages, then what on
>> 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).


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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Friday, July 08, 2011 3:52 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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).

> 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.

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.

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

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

[Dave CROCKER]

On 7/8/2011 6:54 AM, Murray S. Kucherawy wrote:
> 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).


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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Charles Lindsey]

On Fri, 08 Jul 2011 13:05:49 +0100, McDowell, Brett  
 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.
>
>> to make to avoid the horrors of a duplicate From: attack that is and  
>> likely will
>> 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).

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Charles Lindsey]

On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy  
 wrote:

>> -Original Message-
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Friday, July 08, 2011 3:52 AM

>> 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.
>
> 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.

>> 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.
>
> 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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Pete Resnick]

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:

On 7/8/11 5:52 AM, Charles Lindsey wrote:
> 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.
>

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.

> 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.
>

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

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

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

[Douglas Otis]

On 7/8/11 4:43 AM, Alessandro Vesely wrote:
> On 07/Jul/11 16:13, Dave CROCKER wrote:
>> 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...
> 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.
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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Hector Santos]

Douglas Otis wrote:

> 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.

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.

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



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

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

[Charles Lindsey]

On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick   
wrote:

> 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:
>
> On 7/8/11 5:52 AM, Charles Lindsey wrote:
>> 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.
>>
>
> What Charles have written above is not true, or at the very least  
> 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:
>
> 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...

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.
>
> 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.

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.
>
>> 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.
>>
>
> 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.

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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Hector Santos]

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.



Charles Lindsey wrote:
> On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick   
> wrote:
> 
>> 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:
>>
>> On 7/8/11 5:52 AM, Charles Lindsey wrote:
>>> 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.
>>>
>> What Charles have written above is not true, or at the very least  
>> 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:
>>
>> 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...
> 
> 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.
>> 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.
> 
> 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.
>>> 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.
>>>
>> 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.
> 
> 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  
> bot

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Sunday, July 10, 2011 6:00 AM
> To: DKIM
> Cc: Pete Resnick
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> 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.

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.

> 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).

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

> 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.

I think the above text covers that as well.


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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Murray S. Kucherawy
> Sent: Sunday, July 10, 2011 8:39 PM
> To: Charles Lindsey; DKIM
> Cc: Pete Resnick
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> "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."

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

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

[Charles Lindsey]

On Mon, 11 Jul 2011 05:53:58 +0100, Murray S. Kucherawy  
 wrote:

> 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."

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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Monday, July 11, 2011 3:52 AM
> To: DKIM
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> 
> > "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."
> 
> 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.

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
> 8.14 in draft-12.

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

> 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 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.

> 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.

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.


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

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

[J.D. Falk]

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.

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


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

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

[Charles Lindsey]

On Mon, 11 Jul 2011 14:56:26 +0100, Murray S. Kucherawy  
 wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org  
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Monday, July 11, 2011 3:52 AM

>> > "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."
>>
>> 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.


>> 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.
>
> 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.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  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

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

[Douglas Otis]

On 7/12/11 12:02 PM, Charles Lindsey wrote:
> 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.
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




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