Dear Dave,
On Jun 4, 2013, at 11:44 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
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.
"Hope to use", rather than advocates. We stand by the assertion, but we can
further modify this statement.
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.
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.
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?
Sure. Simply observe the increasing signed DKIM messages that have multiple
From:'s.
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.
Unfortunately, affixation of the domain name to the message is the root of the
issue. More on this in a bit.
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.
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.
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.
This assertion is simply wrong.
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.
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