ietf
[Top] [All Lists]

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

2013-06-04 05:48:13

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

<Prev in Thread] Current Thread [Next in Thread>