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