Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC spec

[SM <[e-mail]>]

At 22:43 22-05-2013, Murray S. Kucherawy wrote:
>---------- Forwarded message ----------
>From: Eliot Lear <[e-mail]>

[snip]

>I've been asked to take a look at the DMARC spec.  Let me start by 
>saying that I know that you guys have running code.  I beg your 
>indulgence and ask you to read through.  While this review may come 
>across as a bit negative, and while I have concerns about several 
>components (potential downgrade attack etc).

I strongly agree with what is mentioned in Eliot's review.

>In general I'd say this document needs some cleanup, and in my 
>opinion, it is not ready to move forward as a proposed standard.  To 
>start with, the requirements section is horribly confused.  Some are 
>not requirements but specifications, others are vague.  They read 
>like there was a negotiation among the contributors on what to keep 
>out and what to keep in, or perhaps these are markers for the 
>working group.  Whatever.

If the aim to have a proposed standard I suggest focusing on the 
protocol aspect instead of having a document which tries to say everything.

>The whole section needs to be replaced with something simpler, like:
>
>[1]  Here is what the specification is out to accomplish (and not accomplish).
>[1a] A formal description of the threat model
>[2]  Here are the assumptions we make about sender capabilities
>[3]  Here are the assumptions we're making about receiver capabilities.
>
>Let me stress conciseness!!

Agreed.

 From the Abstract:

   "This memo presents a proposal for a scalable mechanism by which an
    organization can express, using the Domain Name System, domain-level
    policies and preferences for message validation, disposition, and
    reporting with predictable and accurate results.

    The enclosed proposal is not intended to introduce mechanisms that
    provide elevated delivery privilege of authenticated email.  The
    proposal presents a mechanism for policy distribution that enables a
    continuum of increasingly strict handling of messages that fail
    multiple authentication checks, from no action, through silent
    reporting, up to message rejection."

The body of the draft diverges significantly from what is stated in 
the Abstract.  Instead of expressing policies and preferences parts 
of the draft imposes policies (on the receiver).

The Introduction Section discusses about DMARC from a high-level 
perspective and does not convey any information about the 
technologies used in the design.  I had to read up to page 15 to get 
an idea of what DMARC is about.  It is not clear how DMARC URIs fit 
into the picture.

Some text in the document sounds like marketing to me.  For example, 
in Section 2.1:

   "DMARC is designed to support the extreme scalability requirements
    that characterize the systemic problem of identifying the origination
    and legitimacy of email.  DMARC seeks to preserve the positive
    aspects of the current email infrastructure, such as the ability for
    anyone to communicate with anyone else without introduction."

I suggest focusing on how the protocol works instead of trying to 
convince the reader about scalability requirements.

In Section 2.2:

   "This document is significantly informed by ongoing efforts to enact
    large-scale, Internet-wide, anti-phishing measures.  Whereas DMARC
    can only be used to combat specific forms of exact-domain phishing
    directly, the DMARC mechanism is viewed more importantly as a
    substantial step forward in terms of creating reliable and defensible
    message streams."

This can be discussed under security considerations if the question 
is considered as in scope for the protocol.

It would be easier to move Section 3 out.  The text makes the 
document look like a compliance document instead of a protocol 
specification.  In my opinion security considerations are about what 
threats were identified, what was addressed, what was not addressed, 
together with explanations.  Saying that X is out of scope does not 
sound like consideration has been given to a security issue.

The terminology section mentions terms such as "cousin domains", 
"domain owner", etc.  Although such terms may be popular I don't 
think that it is a good idea to use them in a protocol document as 
they can be ambiguous.

In Section 5:

   "A Mail Receiver MUST consider an arriving message to pass the DMARC
    test if and only if one or more of the underlying message
    authentication mechanisms pass with proper identifier alignment."

The above conveys the idea.  It does not provide adequate information 
for the implementer.

   "A Mail Receiver implementing the DMARC mechanism MUST make a best-
    effort to adhere to the Domain Owner's published DMARC policy when a
    message fails the DMARC test."

The above uses a "MUST" to tell people that they ought to make a 
best-effort.  In my opinion that is incorrect usage of RFC 2119 key words.

   "Mail Receivers MAY deviate from a Domain Owner's published policy
    during message processing and SHOULD make available the fact and
    reason of the deviation to the Domain Owner via feedback reporting."

I read the above as "if you do not do what I say you have to provide 
me with a justification".  Let me rewrite the text:

   "Mail Receivers deviating from a Domain Owner's published policy
    during message processing and MUST make available the fact and
    reason of the deviation to the Domain Owner via feedback reporting."

If that text is not acceptable to mail receivers the RFC 2119 SHOULD 
will have the same effect.

In Section 7:

   "When this is done, the DNS domain name thus recorded MUST be encoded as an
    A-label, as described in Section 2.3 of [IDNA]."

The above is under "policy enforcement considerations".  It should be 
in a section discussing the DNS aspects of the specification.

Section 8.2 is about "Verifying External Destinations".  If I am not 
mistaken, IETF specifications are not about imposing a specific 
method.  Section 8.2 sounds like a tutorial for the implementer 
instead of a definition of what the "DMARC policy string" means.

   "A report receiver MUST publish such a record in its DNS if it wishes
    to receive reports for other domains."

The RFC 2119 usage is inappropriate here.  I would put it after the 
high-level view (see Eliot's message) of how DMARC works.

In Section 8.3:

   "The report SHOULD include the following data:

    o  Enough information for the report consumer to re-calculate DMARC
       disposition based on the published policy, message dispositon, and
       SPF, DKIM, and identifier alignment results. {R12}"

"enough information" is an ambiguous description of what the report 
should include.

In Section 11.2:

   "Heuristics applied in the absence of use by a Domain Owner of either
    SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be
    the case that the Domain Owner wishes a Message Receiver not to
    consider the results of that underlying authentication protocol at
    all."

The reference would have to be normative.

In Section 11.3:

   'If email is subject to the DMARC policy of "quarantine", the Mail
    Receiver SHOULD quarantine the message.  If the email is not subject
    to the "quarantine" policy (e.g., due to the "pct" tag), the Mail
    Receiver SHOULD apply local spam classification as normal.'

The usage of RFC 2119 key words in the above is incorrect.

In Section 12.2.1:

  'In the case of a "mailto" URI, the Mail Receiver SHOULD communicate
    reports using the method described in [STARTTLS].'

Has the usual STARTTLS issues been taken into consideration for the 
RFC 2119 recommendation?

   "The aggregate data MUST be an XML file subjected to GZIP compression.
    The aggregate data MUST be present using the media type "application/
    gzip", and the filenames SHOULD be constructed using the following
    ABNF:"

In Section 12.2.2 it mentioned that:

   'Where an "http" or "https" method is requested in a Domain Owner's
    URI list, the Mail Receiver MAY encode the data using the
    "application/gzip" media type ([GZIP]) or MAY send the Appendix C
    data uncompressed or unencoded.'

The data exchange format depends on the URI scheme being used.  In my 
opinion that makes the implementation more complex.

   'For the GZIP file itself, the extension MUST be "gz"; for the XML
    report, the extension MUST be "xml".'

I would ask why such a RFC 2119 requirement is in the draft.

   "Email streams carrying DMARC feedback data MUST conform to the DMARC
    mechanism, thereby resulting in an aligned "pass" (see Section 4.3)."

As far as I am aware the IETF does not do conformance.

   'The RFC5322.Subject field for individual report submissions SHOULD
    conform to the following ABNF:'

The Subject field is specified as structured text in the above.

In Section 12.2.2:

   "The header portion of the POST or PUT request SHOULD contain a
    Subject field as described in Section 12.2.1."

This sounds like sending RFC 5322 formatted messages over HTTP.

In Section 15.8:

   "Many systems are able to scan the SMTP reply text to determine the
    nature of the rejection, thus providing a machine-detectable reason
    for rejection allows automated sorting of rejection causes so they
    can be properly addressed."

I don't think that it is a good idea to discuss about that as part of 
a protocol specification.

I suggest giving careful consideration to privacy.  The draft 
discusses about that in Section 15.10.1.  The draft would require a 
detailed review to understand what information is being exchanged and 
how that can affect users.

In Section 15.12:

   "The DMARC mechanism and its underlying technologies (SPF, DKIM)
    depend on the security of the DNS.  To reduce the risk of subversion
    of the DMARC mechanism due to DNS-based exploits, serious consideration
    should be given to the deployment of DNSSEC in parallel to the deployment
    of DMARC."

I would ask whether anyone who has deployed this mechanism is 
actually using DNSSEC.  If not the above is not saying anything to 
ensure secure use of the protocol.

   "S/MIME, or Secure Multipurpose Internet Mail Extensions, is a
    standard for encryption and signing of MIME data in a message.  This
    was suggested and considered as a third security protocol for
    authenticating the source of a message."

I could not understand the relationship between S/MIME and what this 
specification attempts to do.

   "It has been suggested in several message authentication efforts that
    the Sender header field be checked for an identifier of interest, as
    the standards indicate this as the proper way to indicate a re-
    mailing of content such as through a mailing list.  Most recently, it
    was a protocol-level option for DomainKeys, but on evolution to DKIM,
    this property was removed."

That discussion would be better in a DKIM-related document instead of 
adding it to this draft.

   'DMARC has been characterized as a "super-ADSP" of sorts.'

It is not a good idea to include criticism of other protocols in a 
draft that specifies a protocol unless it is relevant to the protocol 
being specified.

I suggest dropping the idea of using the "public suffix list" as 
previous attempts to use it have not been successful in the IETF.

Regards,
-sm