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

["Murray S. Kucherawy" <[e-mail]>]

Hi SM,

As I said with Eliot's review, thanks for looking at this so early on.  I'm
going to chop a chunk of what you said out about the heavy requirements and
"marketing" since much of it will be slashed in the next version.  As for
what's left:

On Thu, May 23, 2013 at 2:55 AM, SM <[e-mail]> wrote:

>
> 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.
>

Can you make other suggestions?  I think the first one is not ambiguous in
general, but we're very clear on defining and using the second.


>
> 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.
>

The details are further down in the document.  Section 5 is setting the
stage for what comes later.  It's more overview than substance.


>
>   "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.
>

I agree, this would likely be caught during more formal reviews as well.  I
think "MUST make" can just be "makes".


>
>   "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.
>

SHOULD is appropriate.  There can be local policy reasons for not revealing
such details via feedback.


>
> 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.
>

Why?  The context is the construction of an RFC5451 header field, not
something about DNS.


>
> 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.
>
>
I disagree; a specification is indeed about describing a specific method.
Tutorials for implementers appear throughout various documents we produce,
one of which you are working on in another working group right now.  :-)



>   "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.
>

It's fine to drop this to "publishes".  I believe "MUST publish" is also
technically correct, but Pete has described it as "unnecessary shouting" in
the past.


>
> 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.
>

That SHOULD looks more like requirements language, and I agree the bullet
list is non-specific.  The details are in the section containing the XML
syntax.  We'll adjust.


>
> 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.
>

Is that true?  I would think making normative something one SHOULD NOT use
seems contradictory.


>
> 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.
>

Why?


>
> 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?
>

Such as what?


>
>   "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.
>

I don't agree, but I think the more important point is that the two
sections disagree on whether compression is required.


>
>   '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.
>

For interoperability, of course.  What's the issue here?


>
>   "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.
>

It doesn't do conformance levels, as far as I'm aware.  But you either
conform to the standard or you do not.  Are you keying on the word
"conform" or is there more going on here?


>
>   '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.
>

Is that bad?


>
> 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.
>

Is that bad?


> 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.
>

Why?


>
> 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.
>

What issue should we cover that 15.10.1 does not already?


>
> 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.
>

I don't think it's pragmatic to demand use of DNSSEC because of the obvious
chicken-and-egg problem.  However, for a system that is so heavily reliant
on the DNS being stable and secure, it seems wrong not to mention this.


>
>   "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.
>

S/MIME can authenticate part of a message and associate it with a user or
role.  DKIM and SPF can do the same.  The relationship seems obvious to
me.  The question will be asked "Why didn't you also include support for
FOOBAR?" and it seemed appropriate to make it clear that we did, even if
the result is that the idea was discarded.


>
>   "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.
>

I don't agree, because "Use the Sender field!" came up during both the
private and public portions of the evolution of this work.  As with S/MIME,
it seems appropriate to document history rather than repeat it.


>
>   '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.
>

Just about every BoF that tries to tackle a problem for which prior
attempts have failed includes an analysis of why those prior attempts
failed.  I don't think this is any different, and I think it provides a
fair treatment of the issues with ADSP that have been showstoppers for a
lot of people.


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

The revised version makes it clear that we don't like public suffix any
better than the rest of the IETF does, and will be happy to adopt a
replacement solution as soon as there is one.

-MSK