Subject: [dmarc-ietf] draft-kucherawy-dmarc-base-05

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Nov 2014 18:02:02 -0800

https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

Dear Murray,

Based on yours and Stephen's feedback, a few modifications have been made to the proposed edits:

Starting with the acronym.
Was:
  Domain-based Message Authentication, Reporting and Conformance (DMARC)
Change to:
  Domain-based Message Authorization, Reporting and Conformance (DMARC)

This change affects the title, the abstract, and various defined terms.

Justification for this change includes RFC7001 Section 1.5.2. that states the following:

 o  "Authorization" is the establishment of permission to use a
      resource or represent an identity.  In this context, authorization
      indicates that a message from a particular ADMD arrived via a
      route the ADMD has explicitly approved.

 o  "Authentication" is the assertion of validity of a piece of data
      about a message (such as the sender's identity) or the message in
      its entirety.

Neither SPF nor DKIM can claim to authenticate the sending domain of any particular message.  A DKIM signature is independent of both the domain sending the message and its intended recipient by design.  While a DKIM reference to a public key in its signature produces a cryptographically strong association with signed portions of a message, many message elements are excluded.  This exclusion permits unlimited message variability independent of the actual sending domains or intended message recipients by design.  As such, DKIM alone is unable to authenticate a domain publishing a referenced public key actually generated any specific message.  At best it might be claimed that by signing the message, it has authorized various related functions, such as delivery status notifications and specific use of some header fields, particularly the From header field. 

In addition, the identifier purportedly verified in Authentication-Results header fields as specified by RFC7001 suffers from these DKIM related uncertainties caused by exclusion of portions of the message.  In addition, DKIM permits header obfuscation by failing to detect invalid header field structures.  SMTP makes no assurance of message structure, and most DKIM signatures circumvent the overhead necessary to patch DKIM's non-detection of invalid header structures.  It took a large provider several years to discover this particular oversight, even after being warned in appeals and technical publications making specific reference to their service.  Others remain unaware DKIM still permits header spoofing, especially when deployment suggests a valid DKIM signature of a trusted domain can be allowed to bypass subsequent checks.  

In addition, DKIM's lack of header stack validation permits errant results to be conveyed when maliciously changed.  Suggesting a DKIM signature authenticates the source domain places anyone depending on this identity having been authenticated in respect to any particular message at risk.    

The introduction properly states the function of DKIM or SPF is to detect and block unauthorized email.

Neither DKIM nor SPF determines:
1) valid RFC5322 structure
2) intended message recipient
3) sending domain  (not related to signing domain and may have a one of many relationship)
4) From header field content
5) Subject header field content

Of course points 4 and 5 might be repaired, but when such a repair has occurred can not be determined using the present protocol as intended.  Just as most senders avoid the overhead needed to ensure against invalid header field structures, most receivers have similar sensibilities related to subsequent handling necessary to detect these deceptions.

As such, using the terms authenticates and authentication should not be used when referring to DKIM or SPF results.  Nothing is being authenticated.  The real function is the confirmation of an authorization.  It is dangerously misleading to overstate DMARC/SPF/DKIM mechanisms, especially since DMARC permits the weakest mechanism (simple authorization) as a basis for acceptance.

Section 2,
Was:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message authentication policies, or to
   request reporting of authentication and disposition of received mail.
Should be:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message authorization policies, or to
   request reporting of authorization and disposition of received mail.

Was:
   As a result, senders who have implemented email authentication have
   had difficulty determining how effective their authentication is, and
   use of authentication failures to filter mail has not been a success
Should be:
   As a result, senders implementing email authorization schemes have
   had difficulty determining how effective their authorization is, and
   use of authorization failures to filter mail has not been a success.

Section 2.2
 Was:
 o  authentication of entities other than domains, since DMARC is
     built upon SPF and DKIM which authenticate domains; and
Should be:
 o  authorizations of entities other than domains, since DMARC is
     built upon SPF and DKIM which authorizes domains; and 

Section 3:
Was:
      Authenticated Identifiers:  Domain-level identifiers that are
      established using authentication technologies are referred to as
      "Authenticated Identifiers".  See Section 3.1.1 for details about
      the supported mechanisms.
Should be:
      Authorized Identifiers:  Domain-level identifiers that are
      established using authorization technologies are referred to as
      "Authorized Identifiers".  See Section 3.1.1 for details about
      the supported mechanisms.

Was:
3.1.1.  Authentication Mechanisms
Should be:
3.1.1.  Authorization Mechanisms

Was:
o  [SPF], which authenticates the domain found in an [SMTP] MAIL
      command when it is the authorized domain.
Should be:
o  [SPF], which authorizes the domain found in an [SMTP] MAIL
      command.

Section 3.1.4
Was:
  Each of the underlying authentication technologies
Should be:
  Each of the underlying authorization technologies

Was:
   3.1.4.2.  SPF-authenticated Identifiers
Should be:
   3.1.4.2.  SPF-authorized Identifiers

Section 5
Was:
   A Domain Owner may find that although its messages pass a particular
   authentication scheme's checks, it wishes not to have Mail Receivers
Should be;
   A Domain Owner may find that although its messages pass a particular
   authorization scheme's checks, it wishes not to have Mail Receivers

Although DMARC requires subsequent format checks of the From header field, it does not do this with the Subject line which often permits injectable clickable URLs.

As was done with the DKIM deployment RFCs, the same has been done for DMARC BCP.  It seems neither DKIM nor DMARC follow the path of least astonishment.
If history is any sort of predictor, DMARC will be gamed whenever receivers follow the path of least resistance by trusting Authentication-Result header fields as recommended.
The alternative to DKIM was IIM (Internet Identified Mail).  IIM was not adopted because it passed the public key within the message which was considered to cause too much message size overhead.  Now, rather than correcting DKIM's signature validation process, domains are expected to list all the headers used twice in each and every message.

It is very dangerous to over sell the function of SPF and DKIM.  Both of these mechanisms are experiencing increased exploitation in highly critical areas.  It is unfortunate it took until May of 2014 for a major provider to finally acknowledge the nature of these exploits, although they had been explained much earlier in appeals and magazine articles.  Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts are sorely lacking much needed guidance.  Guidance, if written to be effective, many are likely to find astonishing.

DMARC is missing an opportunity to permit From header exceptions that could be based on specific group syntax.  Visible From header field exceptions are needed to permit undisrupted and safer use of third-party services.  

Regards,
Douglas Otis