Dear Dave, On Jun 4, 2013, at 11:44 AM, Dave Crocker <d...@dcrocker.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
