Subject: Re: Review of: draft-otis-dkim-harmful

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Jun 2013 11:44:06 +0200

The problems with this draft persist...

> Organizations such as M3AAWG hope to use DKIM will be able as a required
>    acceptance requirement to offer better ensure a domain identity to provide offers a
>

I happen to be sitting in a M3AAWG meeting as I write this note and it 
happens that I just came out of a session in which someone tried to 
assert the use of DKIM (or SPF) as a 'requirement' and the group was 
very clear that no such 'requirement' exists or is a goal.

of coure, this is quite different from seeking to promote "greater use" 
of such authentication, but the word 'required', above, is wrong.  This 
is worth noting since the premise of the I-D concerns problematic 
policies and practices.

Certainly some individuals advocate such a requirement, but that's 
different from saying that a primary anti-abuse organization advocates it.

> There are
>    proposals within the IETF aimed at establishing DKIM as a basis for
>    reputation schemes in the Repute WG (i.e. section 3.2 of
>    [I-D.ietf-repute-email-identifiers] which introduces DKIM domains
>    being used along with SMTP client IP addresses and rfc5321.helo also
>    identifying the SMTP client.  Identifying the SMTP client encompasses
>    both "Who Initiated" and "To Whom" message elements to support fair
>    negative assertions.  However, DKIM does not encompass this essential
>    information.

The repute drafts specify a query mechanisms; they don't "establish" use 
of the information being queried.  DKIM is already used for reputation.

Worse, the draft here seems to conflate address-based reputation and 
role-based reputation with dkim-based reputation.  That's probably 
because any handling agent can add a dkim signature to a message, 
including an "SMTP client".

However DKIM does not specify the role of the signing agent and doesn't 
care.  Consequently the concern apparently being raised here seems to be 
fundamentally confused about what DKIM is doing.

> Simply publishing this draft
>    appears to have already increase the level of multiple FROM header
>    field abuse seen where it is now at 21% of signed DKIM messages.

Sounds pretty scary.  No doubt the assertion is publicly verifiable, 
including the basis for asserting that it is causing problem?

>  DKIM signs only fragments of an email message, so it is more proper
>    to refer to "DKIM Signed Fragments", and not "DKIM Signed Messages".
>    Normal DKIM signature validation offers a simple PASS/FAIL
>    associating it with a specific domain.  When a recipient receives a
>    PASS status, only the last FROM header field message fragment is
>    ensured to have been included in the DKIM signature process.

This continues the draft's fundamental failure in understanding what 
DKIM does.  DKIM does not validate the message; it uses crypto-signing 
methodology to "affix" a domain name to the message.  In other words, it 
validates the attached domain name, not the message.

As such, the choice of what message parts to include in the signing hash 
is more like deciding how strong the glue on the stamp should be, than 
deciding how to prove the message is valid.

> DKIM's trust related role is to better ensure message delivery to a
>    user's in-box.  Unless DKIM ensures this trust is not used to
>    perpetrate deception, no positive assertions regarding a DKIM domain
>    is safe.  As a result, DKIM can not be used with either positive or
>    negative reputation assertions in its current form.

As logic sequences go, this paragraph is difficult reading.  At least 
one of it's key errors is in claiming that a validation technique has a 
responsibility for how the validated information is used.  DKIM has a 
responsibility for provide a validated domain name.  It does that.

Policies and practices for the /use/ of that domain name are outside of 
the scope of the DKIM signing specification.

When you show your drivers license to validate your identity, it does 
not mean you are a good credit risk.  Nor does it mean that the 
Department of Motor Vehicles has a responsibility to ensure that you are.

> The FROM header field is the Author identifier in section 11.1 of
>    [I-D.kucherawy-dmarc-base].  The DMARC specification offers normative
>    language that a message SHOULD be rejected when multiple FROM header
>    fields are detected.  This requirement would not be necessary or
>    impose protocol layer violations if DKIM did not offer valid
>    signature results when repeated header fields violate [RFC5322].

It's good to see this text refer to a layer violation, since the text is 
one.

Discussion of DMARC is entirely outside of the scope of DKIM, unless use 
of DMARC uncovers some technical flaw in DKIM.  It hasn't done that so 
far and the text in the draft doesn't offer any.

At the least, the draft appears to be claiming that DKIM validates the 
author (rfc5322.From) field.  It doesn't do that validation and it 
doesn't purport to.

It appears the authors have some concerns about the way DMARC uses DKIM. 
  That well might be a worthy discussion... about DMARC.  It actually 
has nothing to do with the DKIM signing specification.

> Trust established by a signing domain is being exploited to mislead
>    recipients about who authored a message.

The draft continues to make broad, onerous claims like this, but 
provides no documentation to indicate that the DKIM signing 
specification is flawed in the function it is performing:  attaching a 
validated domain name to a message.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Jun 2013 13:08:42 +0200

Dear Dave,

On Jun 4, 2013, at 11:44 AM, Dave Crocker <[email-masked]> wrote:

> I happen to be sitting in a M3AAWG meeting as I write this note and it happens that I just came out of a session in which someone tried to assert the use of DKIM (or SPF) as a 'requirement' and the group was very clear that no such 'requirement' exists or is a goal.
> 
> of coure, this is quite different from seeking to promote "greater use" of such authentication, but the word 'required', above, is wrong.  This is worth noting since the premise of the I-D concerns problematic policies and practices.
> 
> Certainly some individuals advocate such a requirement, but that's different from saying that a primary anti-abuse organization advocates it.

"Hope to use", rather than advocates.  We stand by the assertion, but we can further modify this statement.
> The repute drafts specify a query mechanisms; they don't "establish" use of the information being queried.  DKIM is already used for reputation.
> 
> Worse, the draft here seems to conflate address-based reputation and role-based reputation with dkim-based reputation.  That's probably because any handling agent can add a dkim signature to a message, including an "SMTP client".
> 
> However DKIM does not specify the role of the signing agent and doesn't care.  Consequently the concern apparently being raised here seems to be fundamentally confused about what DKIM is doing.

The combination of an assertion a message fragment is "authenticated" and conflation of that assertion is happening today.  More on this in a bit.  The authors are in no way confused.

> Sounds pretty scary.  No doubt the assertion is publicly verifiable, including the basis for asserting that it is causing problem?

Sure.  Simply observe the increasing signed DKIM messages that have multiple From:'s.

> This continues the draft's fundamental failure in understanding what DKIM does.  DKIM does not validate the message; it uses crypto-signing methodology to "affix" a domain name to the message.  In other words, it validates the attached domain name, not the message.
> 
> As such, the choice of what message parts to include in the signing hash is more like deciding how strong the glue on the stamp should be, than deciding how to prove the message is valid.

Unfortunately, affixation of the domain name to the message is the root of the issue.   More on this in a bit.

> As logic sequences go, this paragraph is difficult reading.  At least one of it's key errors is in claiming that a validation technique has a responsibility for how the validated information is used.  DKIM has a responsibility for provide a validated domain name.  It does that.
> 
> Policies and practices for the /use/ of that domain name are outside of the scope of the DKIM signing specification.
> 
> When you show your drivers license to validate your identity, it does not mean you are a good credit risk.  Nor does it mean that the Department of Motor Vehicles has a responsibility to ensure that you are.

There's quite a difference between the use of a Department of Motor Vehicles driver's license to validate your identity, and using a [insert theme park of your choice] driver's license to validate your identity.  In one, significant thought has gone into the  process, including several field verifiable methods to ensure that the license itself is valid.  In the other, you can simply write your name on the top of the license, and it becomes valid.

Again; we are objecting to the absolute ease of forgery facilitated by DKIM.  

> It's good to see this text refer to a layer violation, since the text is one.
> 
> Discussion of DMARC is entirely outside of the scope of DKIM, unless use of DMARC uncovers some technical flaw in DKIM.  It hasn't done that so far and the text in the draft doesn't offer any.
> 
> At the least, the draft appears to be claiming that DKIM validates the author (rfc5322.From) field.  It doesn't do that validation and it doesn't purport to.
> 
> It appears the authors have some concerns about the way DMARC uses DKIM.  That well might be a worthy discussion... about DMARC.  It actually has nothing to do with the DKIM signing specification.

This assertion is simply wrong.  

> The draft continues to make broad, onerous claims like this, but provides no documentation to indicate that the DKIM signing specification is flawed in the function it is performing:  attaching a validated domain name to a message.

DKIM does not, in its current form, attach a validated domain name to a message.  By adding one line "MUST NOT validate a message with multiple From:'s", DKIM will attach a validated domain name to a message.

In its current form, DKIM simply attaches a domain name in an unseen message fragment, not a message.  The ease in which the only assured visible fragment of the message signed by the domain being forged makes it impossible for appropriate handling to be applied or likely harm prevented.

Thank you for your review.  We'll take your input and review how this draft can be better clarified.

Regards,
Douglas Otis

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Jun 2013 09:08:09 -0400

> provides no documentation to indicate that the DKIM signing specification
> is flawed in the function it is performing:  attaching a validated domain
> name to a message.
>
> DKIM does not, in its current form, attach a validated domain name to a
> message.  By adding one line "MUST NOT validate a message with multiple
> From:'s", DKIM will attach a validated domain name to a message.

Here's the part of this I don't understand:
A DKIM signature does two things.  It *does* attach a validated domain name
(the domain in the d= tag).  And it tells the verifier what parts of the
message are covered by the signature (h= and l= tags).  There is no claim
in DKIM that the d= domain has any relation to the RFC 5322 From.  But the
h= tag does tell you how many From header fields are covered by te
signature.

Any verifier that wants to consider a message suspicious if the message
contains more From fields than are covered by the signature can do so, and
the DKIM spec does describe this situation.

You would like the spec to REQUIRE that a message be considered suspicious
under those circumstances.  You made your case for this at least twice to
the working group and at least once more to the IETF community during Last
Call of the draft that became RFC 6376.  Your opinion wasn't agreed with:
you were "in the rough".  You're now bringing it up a fourth time (at
least), and you still appear to be in the rough.   The decision was to
allow the verifier to decide how to handle this.

Being in the rough doesn't make you wrong.  But DKIM isn't wrong either,
and at some point you have to accept that you're standing alone, and accept
the consensus.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Jun 2013 15:48:42 +0200

On 6/4/2013 1:08 PM, Douglas Otis wrote:
>> I happen to be sitting in a M3AAWG meeting as I write this note
>> and it happens that I just came out of a session in which someone
>> tried to assert the use of DKIM (or SPF) as a 'requirement' and the
>> group was very clear that no such 'requirement' exists or is a
>> goal.
...
> "Hope to use", rather than advocates.  We stand by the assertion,
> but we can further modify this statement.

You can invent any sort of claim you want.  What you can't do is
substantiate it, because it has no objective basis.

I made a point of citing minutes-old group discussion that I had
first-person knowledge of and that was explicitly contrary to your claim.

>> However DKIM does not specify the role of the signing agent and
>> doesn't care.  Consequently the concern apparently being raised
>> here seems to be fundamentally confused about what DKIM is doing.
>
> The combination of an assertion a message fragment is
> "authenticated" and conflation of that assertion is happening today.
> More on this in a bit.  The authors are in no way confused.

People mis-use specifications all the time.

The issue here is what the spec says and does, not how people some stray
folk somewhere choose to mis-use it.

DKIM makes no 'assertion a message fragment is "authenticated"'.

Period.

>>> Simply publishing this draft appears to have already increase
>>> the level of multiple FROM header field abuse seen where it is
>>> now at 21% of signed DKIM messages.
>>
>> Sounds pretty scary.  No doubt the assertion is publicly
>> verifiable, including the basis for asserting that it is causing
>> problem?
>

The challenge I placed was on documenting the claim.  The point is to
permit community assessment of the claim.

> DKIM does not, in its current form, attach a validated domain name
> to a message.  By adding one line "MUST NOT validate a message with
> multiple From:'s", DKIM will attach a validated domain name to a
> message.

One of the hallmarks of serious participation in IETF processes is
respect for the outcome of a legitimate discussion that happen to go
against one's preference.

d/

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Jun 2013 16:51:54 +0200

> DKIM does not, in its current form, attach a validated domain name to a message.  By adding one line "MUST NOT validate a message with multiple From:'s", DKIM will attach a validated domain name to…

Dear Barry,

Thank you for your response.

> A DKIM signature does two things.  It *does* attach a validated domain name (the domain in the d= tag).  And it tells the verifier what parts of the message are covered by the signature (h= and l= tags).  There is no claim in DKIM that the d= domain has any relation to the RFC 5322 From.  But the h= tag does tell you how many From header fields are covered by te signature.

Of course it is incorrect for a DKIM signature to be valid when a message has multiple From header fields.  DKIM requires AT LEAST the From header field to be the minimal portion of the message signed.  Every other part of the message is optional.

DKIM was intended not to require ANY change of other mail components.  None.  

When the DKIM signature is trusted and changes how the message is handled, it would be wrong to suggest special consideration is then given other message fragments.  In addition, recipients will not see the signature header field nor should they be expected to understand what it contains.  They will see and understand the From header field however. 

Of course dkim=pass is placed in an Authentication-Results header where many suggest this indicates the message has been "authenticated"!

> Any verifier that wants to consider a message suspicious if the message contains more From fields than are covered by the signature can do so, and the DKIM spec does describe this situation.

DKIM does NOT score messages.  Either the signature is valid or not.  The spec wrongly justifies allowing invalid repeated headers to result in a DKIM signature verified as valid. 

> You would like the spec to REQUIRE that a message be considered suspicious under those circumstances.

No. Just indicate the signature is NOT valid.  This is the only sure way to ensure trust is not misapplied and cause harm.

>  You made your case for this at least twice to the working group and at least once more to the IETF community during Last Call of the draft that became RFC 6376.  Your opinion wasn't agreed with: you were "in the rough".  You're now bringing it up a fourth time (at least), and you still appear to be in the rough.   The decision was to allow the verifier to decide how to handle this.

You and Dave Crocker made assurances this issue would not be abused.  It is being abused and NO other protocol layer ensures message structures are valid. None.  It was negligent for DKIM to ignore occurrences of highly deceptive invalidly repeated header fields as it walks up and down the header field stack.  It is also wrong to suggest some other protocol layer handles this checking.  Such suggestion represents a waste of resources as ONLY DKIM should determine signature validity which MUST consider invalidly repeated header fields.  It also appears most even expect DKIM signature validation checks message structure, but this ONLY happens by double listing singleton header fields in the signed header list.  MOST domains don't bother with this ugly hack, especially larger domains where checking message structure is critical. 

> Being in the rough doesn't make you wrong.  But DKIM isn't wrong either, and at some point you have to accept that you're standing alone, and accept the consensus.

Putting people at risk in some race to obtain Standard status can not be justified.  Getting this right is far far more important.  Allowing this to become a standard will make specification modification even more difficult.

Regards,
Douglas Otis

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Jun 2013 11:20:01 -0400

>
> Of course it is incorrect for a DKIM signature to be valid when a message
> has multiple From header fields.  DKIM requires AT LEAST the From header
> field to be the minimal portion of the message signed.  Every other part of
> the message is optional.
>

In retrospect, I think that requirement was a mistake, because it
encourages misunderstandings such as yours.  Whether or not a header field
is signed has nothing whatever to do with the validity of the signature or
the fact that the signature attaches the d= domain to the message.

Having an (extra) unsigned From should no more invalidate the signature
than having an unsigned Subject should.

But the information that there's a valid signature and an unsigned
<whatever> header field can certainly be two pieces of information that are
passed to an evaluator, which decides what to do with the message.

> DKIM does NOT score messages.  Either the signature is valid or not.  The
> spec wrongly justifies allowing invalid repeated headers to result in a
> DKIM signature verified as valid.
>

Indeed; the signature is valid.  That and the list of what bits are covered
by the signature are the two things that DKIM provides.  An evaluator built
on top of DKIM can use that information in any way it likes, including
throwing away the DKIM validation if certain header fields weren't covered.
 That was the working group's decision, which you don't seem to accept.  As
I said, you're in the rough on that.

You and Dave Crocker made assurances this issue would not be abused.

That's not an accurate characterization.  No one made any "assurances";
certainly I didn't, as chair.
The working group understood the potential for abuse.  The working group
decided that the risk of abuse and damage from that abuse was less than the
problems that would be cause by the proposed fixes.  The text that's in the
document was put there to explain the problem, and to allow implementors to
address it if they want to (or think they need to).

> Putting people at risk in some race to obtain Standard status can not be
> justified.  Getting this right is far far more important.
>

Getting it right is, indeed, important, and the working group does think it
got it right.  The rest of that is hyperbole, as best I can tell.I see no
evidence that has been presented that shows me how this puts people at
risk.  (And remember that DKIM provides a relatively low level of security,
and is meant to be used as one piece of information that forms a *part* of
an overall system.)

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Jun 2013 17:45:40 +0200

On 6/4/2013 4:51 PM, Douglas Otis wrote:
> Of course it is incorrect for a DKIM signature to be valid when a
> message has multiple From header fields.

You lost that debate in the working group.  Multiple times.

Saying "of course" at the beginning of your claim does not make you win 
the argument.

> DKIM was intended not to require ANY change of other mail components.

It doesn't.

> When the DKIM signature is trusted and changes how the message is
> handled, it would be wrong to suggest special consideration is then
> given other message fragments.

So it's a good thing the DKIM spec doesn't do that.

>  In addition, recipients will not see the
> signature header field nor should they be expected to understand what it
> contains.  They will see and understand the From header field however.

Quite possibly.

And it's why the DKIM signing specification says:

    3.8.  Input Requirements

    A message that is not compliant with [RFC5322], [RFC2045], and
    [RFC2047] can be subject to attempts by intermediaries to correct or
    interpret such content.  See Section 8 of [RFC4409] for examples of
    changes that are commonly made.  Such "corrections" may invalidate
    DKIM signatures or have other undesirable effects, including some
    that involve changes to the way a message is presented to an end
    user.

    Accordingly, DKIM's design is predicated on valid input.

> Of course dkim=pass is placed in an Authentication-Results header where
> many suggest this indicates the message has been "authenticated"!

So, you are criticizing the DKIM Signature specification for wording in 
a separate specification that was developed independently?

>>  You made your case for this at least twice to the working group and
>> at least once more to the IETF community during Last Call of the draft
>> that became RFC 6376.  Your opinion wasn't agreed with: you were "in
>> the rough".  You're now bringing it up a fourth time (at least), and
>> you still appear to be in the rough.   The decision was to allow the
>> verifier to decide how to handle this.
>

Please document that claim.

>  It
> is being abused

Please document that claim, and more importantly please substantiate the 
implication that it is causing a problem in the operation of Internet mail.

> and NO other protocol layer ensures message structures
> are valid.

Perhaps you have heard of RFC5322 and MIME?  Those are the 
specifications that define valid message formats.  Software that 
implements those specs ensures message structure validity.

Your issue is with software that enforces those standards -- or doesn't 
--  rather than a separate specification that calls on them.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Jun 2013 09:05:45 -0700

> permit community assessment of the claim.

As another data point, when Doug's claim of increased appearance of
multi-From messages surfaced, I instrumented my own MTAs to detect the same
sort of thing to see if he's right.  My data don't concur with the claim;
it's still nearly zero.  I will release the source code for this in an
update to OpenDKIM soon, so others can collect their own data.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Jun 2013 09:13:10 -0700

On Tue, Jun 4, 2013 at 4:08 AM, Douglas Otis <[email-masked]> wrote:

> In its current form, DKIM simply attaches a domain name in an unseen
> message fragment, not a message.  The ease in which the only assured
> visible fragment of the message signed by the domain being forged makes it
> impossible for appropriate handling to be applied or likely harm prevented.
>
>
There are existence proofs that contradict this claim.  They have been
brought to your attention in the past.

It appears you're continuing to assign semantics to DKIM signatures that
simply aren't there.  I don't know what else can be done to clarify this.

Procedurally speaking, what path do you anticipate your draft following?

-MSK

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jun 2013 22:16:37 -0400

I'm jumping into this particular branch of the conversation late.  I've
followed Doug's concerns against DKIM somewhat over the years.

It seems fairly clear that Doug has a long-standing concern regarding
DKIM and how it interacts with e-mail.
It seems fairly clear he's in the rough within the IETF.

If Doug is asking the IETF to get consensus behind his draft, that seems
like it will be a hard sell.

However, I strongly support writing down Doug's argument in a draft and
assuming it is sufficiently coherent publishing it somewhere.  I tend to
think the ISR process of the RFC editor would do a good job evaluating
the question of coherency and that the independent stream of the RFC
series is a great place to publish the opinion of someone who has been
involved in the process for a long time and still believes we've made a
mistake.

Sure, lots of people in the IETF will disagree with doug; that's what
makes Doug in the rough.

Interestingly, reading Dave's review and criticism of Doug's draft
increases my confidence that there's something in what Doug has been
thinking worth writing down and publishing.
I think it's fine if Dave wants to write up his own draft about why Doug
is wrong.

So, I'd like to encourage Doug to refine his work, fix errors of
precision, but to say I think this is worth writing down.

--Sam

---

From: Douglas Otis <[email-masked]>
Date: Sun, 9 Jun 2013 10:42:57 -0700

On Jun 4, 2013, at 9:13 AM, Murray S. Kucherawy <[email-masked]> wrote:

> There are existence proofs that contradict this claim.  They have been brought to your attention in the past.

Thank you for your response.  Could I trouble you for a reference to the proofs or for you to expand on what you specifically mean?  The draft otis-dkim-harmful addendum captured actual DKIM From header field spoofing delivered to the in-box for several major providers.

> It appears you're continuing to assign semantics to DKIM signatures that simply aren't there.  I don't know what else can be done to clarify this.

The semantics of d=domain and dkim=pass appear to be at the root of the problem.    What other semantics are you suggesting?

> Procedurally speaking, what path do you anticipate your draft following?

To require messages with invalidly repeated header fields to not return a "pass" for DKIM signature validation.

I apologize if I missed your response to a private query.   I hope to post an update shortly covering all expressed concerns.  

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Jun 2013 01:18:17 -0700

> "pass" for DKIM signature validation.
That's a technical response.  What I asked was a procedural question.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Jun 2013 12:58:13 -0700

> precision, but to say I think this is worth writing down.

Dear Sam,

Thank you for your interest.  I have updated the draft and, and as requested by Dave Crocker, included references to prior statements by Dave Crocker and Barry Leiba made public subsequent to the conclusion of the WG DKIM specification in response to comments about the phishing threat DKIM permits.  In reviewing some of Dave Crocker's responses, it appears differences between "validated the SDID" and "authenticated the SDID" could use some clarification since this is awkwardly described in RFC6376 section 6.3.  

Quoting the abstract of RFC5863 co-authored by Dave Crocker, "DKIM's authentication of email identity can assist in the global control of "spam" and "phishing".  This document provides implementation, deployment, operational, and migration considerations for DKIM." 

Section 5.4 "Inbound Mail Filtering" of RFC5863 states: 
,---
   DKIM is frequently employed in a mail filtering strategy to avoid
   performing content analysis on email originating from trusted
   sources.  Messages that carry a valid DKIM signature from a trusted
   source can be whitelisted, avoiding the need to perform computation
   and hence energy-intensive content analysis to determine the
   disposition of the message.
'---
This is exactly how DKIM is being used and why DKIM is harmful!

Additional information is being acquired, but will not alter conclusions reached.
http://tools.ietf.org/html/draft-otis-dkim-harmful-03

Regards,
Douglas Otis