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

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Apr 2014 12:11:45 -0700

It seemed like a good time to run through the current DMARC draft. I'm
pleased to see that quite a few of the comments I made in my 2 Oct 2013
review of the -01 draft have been addressed.

Note that this review addresses the quality of the specification only;
it intentionally doesn't address the question of whether deployment of
DMARC might be harmful in some way.

=====

1. Introduction

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.

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

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

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?

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.

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.

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.

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.

3.2 Organizational Domain

I remain very concerned about this algorithm since I have been
previously told very specifically not to do this by the DNS folks. I'm
also concerned about the inconsistency (interoperability impact) that
could result from different operators using different public suffix lists.

4. Policy

Paragraph 4 basically says, if you don't want a particular
authentication scheme to be considered by DMARC, don't use it at all.
For a domain that is using SPF and DMARC (for example), this could be an
impediment to their deployment of DKIM because they could not test with
it without having it immediately affect recipients' message handling.
One possibility would be to ignore DKIM if the testing (t=y) flag is
set, although a campaign would be needed to get the many domains
currently using t=y to turn it off. Another possibility would be to have
a setting in DMARC to ignore a specific authentication method entirely.

On a related note to the t=y flag for DKIM, are all types of SPF failure
(-all, ~all, and ?all) treated equally, or can one of them (probably
?all) be used for testing?

5. DMARC policy record

Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
characterization. If the query requirement matched perfectly with the
DNS, DNS would have a way to determine the Administrative Domain without
resorting to suffix lists and such. Just strike the sentence; this isn't
relevant here anyway.

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.

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?

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

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?

5.3 Formal Definition

dmarc-rfmt: Should allow a colon-separated list as described in 5.2.

7.1 Verifying External Destinations

Paragraph 3: "verification steps SHOULD be taken" These steps are to
protect another domain from attack. It needs to be a MUST.

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.

7.3 Failure reports

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

7.3.1 Reporting Format Update

"Operators implementing this specification also implement": Is that a
SHOULD or MUST before "also implement"?

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)

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

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.

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.

Second-to-last paragraph: "If the RFC5322.From domain does not exist in
the DNS" is basically changing what RFC5321/5322 allow. This isn't the
place to be making fundamental changes to the behavior of email.

9. Domain Owner Actions

Last paragraph doesn't seem like it fits. Suggest it be removed.

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.

11.1 Discovery

Mail Receivers can also discover reporting requests from the
Organizational Domain. That should be mentioned here. But I'm a little
confused why we have another Discovery section at all.

11.2.1 Email

The whole thing about filenames needs to go away. Since it's only a
SHOULD requirement, the Report Receiver needs to be able to handle
reports that don't follow this format as well as those that do. I also
wonder if some operating systems have trouble with filenames containing
the "!" character. Just let the filename be arbitrary. And since there's
a MIME-type, the file extension shouldn't matter either.

I have somewhat the same reaction to the Subject header field
discussion. It's only a SHOULD, so report receivers can't depend on it.

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.

14.1 Data Exposure Considerations

Last paragraph: what's an "unexpected Mail Receiver"?

The privacy consideration here, which isn't obvious from the wording, is
that users may currently use forwarding in a way that prevents the
sender from determining the ultimate delivery address. DMARC has the
potential to break that. This might be important in the case of a user
that is trying to distance themselves from a stalker.

14.2 Report Recipients

Some potential exists for report recipients to perform traffic analysis:
to obtain metadata about the receiver's traffic. In addition to
verifying compliance with policies, receivers need to consider that
before sending reports to a third party.

14.4 Secure Protocols

This seems like it belongs more in Security Consideration than here.

15.5 Identifier Alignment Considerations

"DKIM signing practices" -> "DKIM selector records"

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?

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.

=====

I didn't particularly review the appendices this time around.

-Jim