Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04

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

Covering the stuff Dave didn't cover:

On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton <[e-mail]> wrote:

> Top of page 6: "The receiver reports to the domain owner..."  The
> receiver actually sends reports to a report receiver designated by the
> domain owner.
>

Fixed.


> 2.4 Out of Scope
>
> I still find the double negatives to be confusing, e.g., "DMARC will not
> make a distinction...".  It's the making of a distinction that's out of
> scope, not the not making a distinction (forgive my own double negative,
> please!).
>

That text is apparently gone.


> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
> relies on other authentication mechanisms.
>
> 3. Terminology and Definitions
>
> Domain Owner: This definition refers to the domain owner as being the
> registrant of a DNS domain. But as used elsewhere in the spec, it can
> also be a delegate of that registrant that is given control over a
> subdomain. The document frequently refers to a domain owner publishing a
> DMARC record, so it's worth clarifying who has that capability.
>
> Report Receiver: "reports about the messages claiming to be from a third
> party"  We're talking about the reports here, not the messages
> themselves, so I would suggest "reports from a third party about their
> messages".
>

Fixed and fixed.


> 3.1.2 General Concepts
>
> Paragraph 2: "provide feedback to the Domain Owner". Should this say a
> Report Receiver designated by the Domain Owner, or is that too much
> information at this point?
>

Fixed.


> Paragraph 3 doesn't quite capture the sense of alignment properly,
> especially for SPF. A message that is authorized by SPF might have an
> unaligned envelope-from address, so the validity of SPF for such
> messages is moot.
>

This appears to have been rewritten already.


> 3.1.3 Flow Diagram
>
> Item 1: "Author constructs" and "Author also configures" -> "Domain
> Owner constructs" and "Domain Owner also configures" (I missed this last
> time)
>
> Item 7: 'e.g., a "pass" or "fail"'  Are there other results? If not,
> remove the e.g.
>

Fixed and fixed.


> 3.1.4 Identifier Alignment
>
> Paragraph 5: Although this document makes it clear that "strict" and
> "relaxed" are different from their usage in DKIM, I'm still having
> trouble with those words.  "strict" means that only this specific domain
> is affected; "relaxed" means that this domain and its subdomains are
> affected.  So "relaxed" is really more strict in that it enforces more.
> I find the terms to be confusing, and would recommend something that
> more directly describes whether the policy applies to subdomains.
>

Since we're documenting deployed infrastructure here, it's way too late to
be renaming these.


> 3.1.4.1 DKIM-authenticated identifiers
>
> Paragraph 4: Include section reference (3.2) to public suffix lists
> since the section describing it has moved after this text.
>

Added.


> 5.2 General Record Format
>
> fo: A colon-separated list of options is supported, but 0 and 1 conflict
> with each other so that either needs to be prohibited or it needs to
> define which wins.
>

Previously addressed (Scott Kitterman brought it up).


> fo:d: "a signature": In the case of a message with multiple DKIM
> signatures, does that mean if any signature failed evaluation, a message
> is sent? Is a separate message sent for each failed signature?
>

Clarified.


> p:quarantine: What does "suspicious" mean? It sounds like it means
> something other than "place into spam folder" and "scrutinize with
> additional intensity"
>

Clarified.


> pct: "DMARC-generated reports...must be sent and received unhindered".
> How does one identity a DMARC-generated report to make sure it's
> unhindered, especially if a bad actor tries to make their messages look
> like reports?
>

The syntax of a DMARC report is defined elsewhere in the document.
Shouldn't it be easy to identify one?



> 5.3 Formal Definition
>
> dmarc-rfmt: Should allow a colon-separated list as described in 5.2.
>

Fixed.


> 7.2 Aggregate Reports
>
> The list of what SHOULD be in the reports seems like it belongs in the
> definitions of the report formats themselves.
>

The report formats, defined in MARF RFCs, present the syntax you would use
to report those values if you have them.  For DMARC, we're saying that all
of those are a SHOULD.


> 7.3 Failure reports
>
> Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF]
> in the text was incompletely applied.
>

Cleaned up.


> 7.3.1 Reporting Format Update
>
> "Operators implementing this specification also implement": Is that a
> SHOULD or MUST before "also implement"?
>

It's an implied MUST.  We're being trained lately that use of RFC2119 words
is not always mandatory.  In essence, this is saying "If you're a DMARC
site, this is what you do."

7.4 Utility of Failure Reports
>
> Paragraph 1: "detects an authentication failure" -> "detects a DMARC
> failure" (since authentication can succeed but DMARC fail because of
> alignment)
>

Fixed (new location).


> Paragraph 2 is not relevant to utility of failure reports and probably
> belongs in 7.3.1.
>

It's all been rearranged, and the new layout seems better.


> 8. Policy Discovery
>
> Step 3: This implicitly says that policy directly applied to a subdomain
> takes precedence over that published by an Organizational Domain. That's
> fine, but it should be stated more clearly elsewhere. As I said before,
> it would be helpful to have something earlier in the specification that
> talks about the ability to publish a policy either directly on a
> subdomain or on an Organizational Domain.
>

Isn't this clear from the definition of "sp:" in 5.3 (of -08)?


> Also, note that subdomain policies are necessarily strict (don't apply
> to subdomains of the subdomain) because they won't be discovered using
> this algorithm. It should say that somewhere do operators don't try to
> apply DMARC to subtrees of their organizational domain.
>

I'm a little confused by your example.  If I put a "p" and an "sp" tag at "
example.com", then "p" applies to example.com and "sp" applies to *.
example.com.  That seems clear from 5.3.  Are you suggesting saying that
there's no way to do policy hierarchies?

10.1 Extract author domain
>
> "Such messages SHOULD be rejected": Agree where forbidden by RFC5322,
> but a single RFC5322.From containing multiple entities is explicitly
> valid. Again, this isn't the place to be making fundamental changes to
> the behavior of email.
>

This has already been cleaned up.


> 11.2.3 Error Reports
>
> Last paragraph: If this is published as an independent submission RFC,
> there will be no opportunity to add something here.
>

What might one want to add?

14.4 Secure Protocols
>
> This seems like it belongs more in Security Consideration than here.
>

OK.

15.5 Identifier Alignment Considerations
>
> "DKIM signing practices" -> "DKIM selector records"
>

Fixed.


> Note that actors that can gain control of SPF records or selectors can
> probably publish a DMARC record for the subdomain as well, which will
> take precedence over the record at the Organizational Domain.
>
> Last paragraph: What does "strict" have to do with this?
>

If you set "strict" on example.com, you remove any ability for someone
that's compromised foo.example.com from generating mail that will pass
DMARC.


> 17.3 DNS Security
>
> Might want to make a distinction between DNSSEC publication and
> resolution. Publication is relevant to Domain Owners, and third-party
> Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers
> and Report Receivers.
>

Done.

-MSK