[dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)

[SM <[e-mail]>]

Hi Murray,
At 01:34 05-07-2013, Murray S. Kucherawy wrote:
>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:

Ok.

I would have to read draft-kucherawy-dmarc-base-00 to remember the 
context of my previous comments.  I'll respond quickly instead.

>On Thu, May 23, 2013 at 2:55 AM, SM <[e-mail]> wrote:
>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.

I'll have to go and read before suggesting anything.  Let's put this 
one on hold and get back to it later.

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

I suggest not putting requirements in a section which provides an 
overview.  Barry and Pete commented about yelling in a WG.  I suggest 
taking those comments into consideration.    As a meta-comment about 
setting the stage I suggest writing the proposal as a mechanism.  You 
could then drop text, reorganize it, etc. to come up with a leaner 
version which specifies the mechanism and avoids the usual headaches.

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

Yes (see above).

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

What I meant is that the proposal is telling mail receivers what to 
do.  The matter is entirely a local policy 
issue.  draft-kucherawy-dmarc-base-00 is intended as a Standards 
Track document.  The draft is doing policy stuff and trying to set 
conformance.  There has been previous similar efforts.  I would 
describe them as controversial and subject to interpretation.  I 
would scope the work to keep the implementation and policy parts 
separate so that you have a tightly-written specification.

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

I guess that we are reading "policy enforcement considerations" 
differently.  The context is as what you wrote above.  What I was 
suggesting is to separate policy from how the DMARC code is supposed 
to work.  You could take the RFC 5451 approach to simplify the draft.


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

I disclaim any knowledge of any other working group. :-)

I have been reading some specifications (not mail-related) and some 
reviews recently.  I don't think that the Internet Engineering Tooth 
Fairy will agree with the following; sometimes a proposal specifies a 
method and gets into details which turns the proposal into a guide 
about a specific implementation.  A Standards Track document is about 
interoperability and not about specifying how the implementor should do things.

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

Yes.

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

As a quick reaction this is fixable.

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

I missed the "e.g.".  You could leave it as it as informative.  I 
would remove the example, or that entire paragraph, and focus on the 
technologies you are using to design DMARC.

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

If I recall correctly, I wrote that as I thought that the above 
dictates local policy.  You could restate this in terms of 
information the publisher is trying to convey.  I would remove the 
"SHOULD apply local spam classification" as the draft is then trying 
to solve the spam problem.

>   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 trust path is usually broken for STARTTLS.  It's like using 
self-signed certificates.    There is also an ambiguity, if I recall 
correctly, in the specification.

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

Ok.


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

That sounds using MIME sniffing.  It's easier to defer to the 
relevant specification instead of setting a requirement 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?

Yes, I was keying on the word "conform".  The "standard" tells you 
what you need to know to achieve interoperability.  My reading of the 
above is that you want an aligned "pass" and you worked your way back 
to get there.

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

The specification is re-purposing ancient technology. :-)  The short 
answer is that it is not good.    I was not keen about previous 
proposals taking such an approach.  It works if you do it on a 
controlled environment.  You might see problems as you scale it.


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

I don't have enough information as I write this to say that it is 
bad.  The proposal reminds me of another specification and that's not 
a good sign. :-)

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

The draft getting into heuristics.  This takes you away from protocol 
specification to things people do because "it works for them".  The 
straight answer is that I don't really know as it is a matter of 
whether the heuristics not working is really an edge case or 
something to seriously consider.

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

I flagged this as "things to look out for".  It's easier if you have 
people who will review the privacy considerations during the initial 
work.  Given all the privacy discussions that are going on I suggest 
looking into it carefully.  I don't have any idea of whether 
everything is covered adequately as I prefer not to put too much time 
into a review at this stage.

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

The chicken-and-egg problem has been solved.  You could have DNSSEC 
under Security Considerations.

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

I see.

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

Ok.

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

It happens. :-)

You could leave it for now and drop the text before publication.

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

I would flag the "public suffix list" on a Last Call so that nobody 
says that they were not aware that it is being standardized.

Regards,
-sm