Subject: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01

From: Jim Fenton <[email-masked]>
Date: Wed, 02 Oct 2013 15:54:26 -0700

I have not been monitoring this mailing list, but a couple of people
have asked me to have a look at the DMARC spec.  I apologize for the
amount of time it has taken for me to get to this.

I'll leave out the editorial issues, but I'm happy to share those (in
particular, with the editors) if there is interest.  I'll start with a
lot of specific comments; there are a few additional comments at the
very end.

===

1. Introduction

Paragraph 3:  I'm surprised to see the use of the word "policy". In the
context of ADSP (originally Sender Signing Policy), the word "policy"
was considered inaccurate because it was deemed inappropriate to dictate
policy to a Receiving Domain. Even though SSP was describing the
domain's policy with respect to signing messages with DKIM, the word
"practices" was substituted. Is it now considered acceptable to make
policy requests of a Receiving Domain?

Paragraph 4 #1: "assertions about senders' practices" : shouldn't that
be Domain Owners' practices, since the sender might include spoofers?

Paragraph 3 #1: "Senders make policy assertions" -> "Domain owners
publish policy assertions". But see comment below about "domain owners",
and note that DMARC records contain considerably more than policy
assertions.

Paragraph 3 #2-1: "The receiver" might be interpreted as being an MUA.
Suggest "Receiving domains". "how the mail is handled" -> "how they
should handle the mail"

Last bullet: I immediately went to the case of the From: header field
with multiple addresses, which had been a significant issue with ADSP.
More about this later.

2.1 High-Level Goals

First bullet: senders -> Domain Owners. Similar comment on the word
"receivers".

Third bullet: "effect on legitimate messages" isn't clear on what the
"effect" is. Deliverability impact?

2.4 Out of Scope

This section is full of double negatives, e.g., "not in scope for this
work include: DMARC shall not be required..."

Authentication of individuals rather than domains: DMARC doesn't perform
authentication at all, it acts on the result of two other mechanisms.
This muddies that point.

3. Terminology and Definitions

The main part of this section is indeed terminology and definitions, but
the subsections, particularly 3.2, aren't.  This should be reorganized.

Domain Owner: This definition clearly defines the Domain Owner as the
registrant of a domain. But as we will see much later, DMARC records are
sometimes published by From domains directly, which could be a person or
organization delegated by the Domain Owner. Perhaps another term is
needed, because there are some things that are available only to Domain
Owners and others that are also available to those able to publish a DNS
record for a subdomain.

Organizational Domain: I have many problems with this:

(1) An algorithm like this doesn't belong in the definitions.
(2) This creates a dependency on a public suffix list such as that
published by Mozilla, but doesn't require the use of a particular list.
This would create an inconsistency in the result of DMARC that I
consider to be an interoperability problem.
(3) During the development of ADSP, it was made clear to me by the DNS
folks that there is no way, in practice, to determine an Organizational
Domain.
(4) The last paragraph acknowledges that it is a heuristic, and its use
of "currently" implies that something better is in the works (which
needs to be described instead in the spec).

3.2 Overview

Paragraph 1: "Mail sent for such a domain" -> "Mail sent from such a
domain" (important distinction!)

Paragraph 2: Feedback is to the Domain Owner, not the claimed sender.

Paragraph 4: "from the Domain Owner" -> "from the Organizational Domain"

[aside: I see, much later in the spec, that DMARC records can be
published by the From domain directly, not just from the Domain Owner. A
lot of earlier text needs to be cleaned up to accommodate that.]

3.3 Flow Diagram

"The above diagram shows the flow of messages": But there are lots
more.  Spoofed messages have a different flow. So do mailing lists,
domains with multiple layers of MTAs, etc. This is just the simplest
flow of legitimate messages.

Item 6: "author's DNS data".  For SPF and DKIM, what's queried is not
necessarily the author domain.

Item 7: "queries to the author domain": Organizational Domain? (with the
above aside as a caveat)

3.4 Identifier Alignment

It would be good to start with a definition of what identifier alignment
is, and I'm not finding that (perhaps it is buried there somewhere).

Paragraph 2 end: "most MUAs represent..." introduces a UI issue, and we
have considered that out-of-bounds in the past.

Paragraph 4: identity alignment -> identifier alignment

This section should discuss the rare-but-legal case of From: header
fields with multiple addresses.

3.4.1 DKIM-authenticated identifiers

I got confused here right away by the use of "strict" and "relaxed"
modes without proper introduction to what they are, since those terms
are used in DKIM (as canonicalization modes) and mean something very
different here. It was only when I got to the SPF section and it was
still talking about strict and relaxed that I realized those terms were
being used in DMARC as well.

Paragraph 2: must be equal -> must be equal in order to be considered to
be in alignment

Last paragraph: "DMARC pass" hasn't been defined anywhere.  Does DMARC
produce a pass/fail result?

3.4.1 and 3.4.2

I'm unclear on the motivation for having both strict and relaxed modes.
Is it because we don't know what will work in practice, or because
different sorts of domains will want to choose differently. If the
latter, please give some guidance for which mode should be used in which
situation.

4. Policy

Paragraph 2: sending domains -> Organizational Domains (with above caveat)

Paragraph 4: It's possible to determine non-use of SPF, but not DKIM, in
this way.

5. DMARC Policy Record

Paragraph 2: "matches perfectly with the DNS".  Not at all -- the fact
that it isn't possible to deterministically determine the organizational
domain, is an example of the mismatch.  Also, operational limits on DNS
record sizes prompts the use of non obvious syntax like the !<size>
construct.

5.2 General Record Format

Paragraph 2: Last sentence is less about DMARC than about change control
for the spec itself.

adkim tag: Definition unnecessarily limits alignment modes to "s" and
"anything else". Suggest that it require "s" or "r", with other values
reserved for future use.

fo: The tag value can contain both 0 and 1; what happens then?

d: Not sure why it's interesting to find about broken signatures when
there's a good signature that meets alignment requirements.

p: quarantine: What does "fails the DMARC mechanism" mean overall? Is
this defined somewhere?  "suspicious": After all the controversy about
the use of the use of the word suspicious in SSP/ADSP, I'm highly amused
to see it here.

pct: DNS domain isn't defined. DMARC mechanism is to be applied -> DMARC
policy is to be applied

rf: This is comma-separated, while other tag values are colon-separated.
Why the inconsistency?
Initial default values are -> Possible values are (and possibly
reference a registry)
[IODEF] is listed as an Informative Reference; shouldn't it be normative
like [AFRF]?

ri: It seems like everything is best-effort; the Receiving Domain is
doing a favor here (and sendto: is itself best effort).

sp: Does this apply to subdomains at all levels, or just direct
subdomains? What's the motivation for specifying a different policy for
subdomains vs. the organizational domain?  Should also point out that sp
is meaningful only for DMARC records published in Organizational Domains
and not From domains, (although  publishing in From domains isn't
introduced until later in the document).

6. Policy Enforcement Considerations

Paragraph 2: "...not to increase the likelihood of accepting abusive
mail..." This seems like a qualitative requirement, not sure it belongs
here.

7.1 Verifying External Destinations

Paragraph 3: SHOULD -- shouldn't that be a MUST?

Item 8: If rua and ruf can be overridden by the report receiver,
wouldn't it be useful to be able to override at least ri and perhaps
other values as well?

Third to last paragraph: "*._report._dmarc.example.com" looks rather
scary -- mechanisms that depend on DNS wildcarding are always fragile.
This may very well work, but it looks to me like this record actually
says that example.com is willing to receive reports for ANY domain, not
just child domains.

7.2 Aggregate reports

The format for these reports is critical to interoperability -- should
it really be specified in an appendix?  It's more important to specify
the format of the reports than the requirements shown in the bulleted list.

7.3 Failure reports

Paragraph 1 reads as though AFRF is the only reporting format, but needs
to accommodate IODEF and any future-defined reporting formats as well. 
For extensibility, there should also be a way for the Mail Receiver to
generate a meta-report saying that they don't support the requested
report format.

7.3.1 Reporting Format Update

Are there any updates to IODEF?

7.4 Failure Reports

Paragraph 2: "ruf" tag -> "rf" tag

8. Policy Discovery

This is the first mention I have seen that DMARC records are published
directly on From domains; up to this point it looked like DMARC was only
published by a Domain Owner on an Administrative Domain.  This changes a
lot -- like the fact that a delegate of the Domain Owner, and not the
[administrative] Domain Owner him/herself, can set the policy for a
domain. This might require a major change of terminology usage, or at
least a change in the definition of Domain Owner, to fix.

Items 2 and 4: Effectively, this means that v=DMARC2 records are
completely independent of v=DMARC1 records. There is no interoperability
between versions. Is this what is intended?

"If the RFC5322.From domain does not exist...": This specifies an action
that has nothing to do with DMARC. I don't know the history of this but
it seems like if there was going to be some global "you SHOULD reject
messages with a nonexistent From domain" action, it belongs someplace
like RFC 5322, not here. See also comment under A.4.

9. Domain Owner Actions

Paragraph 1: "set up an address to receive reports" -- could also
delegate that externally

Paragraph 2: What does "protect those email addresses" mean?

Paragraph 3: What does this have to do with domain owner actions? If
this is connected to the previous paragraph, note that there is no
requirement that reports use SPF and/or DKIM authentication (although
perhaps there should be).

Paragraph 4: Need some specific guidance on how URIs other than mailto:
are to be used (although there is some discussion of this in section 11;
maybe a forward reference is needed)

10.1 Extract Author Domain

Paragraph 3: "Such messages SHOULD be rejected." Again, this specifies
an action on messages that has nothing to do with DMARC. In particular,
bullet 2 and 4 describe messages that are legal according to RFC 5322,
and if they're undesirable should have been addressed there.

If the messages are rejected, should they be silently discarded or fully
rejected (per section 15.4)?

10.3 Messaging Sampling

Much of this section applies generally to the application of policy and
not specifically to sampling, so perhaps the section heading should be
"Policy Application" or something like that.

11.1 Discovery

Paragraph 1: Does not discuss DMARC policy records associated with
Administrative Domains, only those associated with the From address
(converse of everything before section 8).

Paragraph 2: Section 7.1 -> Section 8

11.2 Transport

Paragraph 1: "secure transport mechanism" needs to be specified more
completely. Does SMTP/TLS qualify? Is successful certificate
verification required?

Paragraph 3: "Mail Receiver SHOULD send" -- section 11.2.4 (paragraph 1)
says that an attempt MUST be made.

"MAY discard" -- 11.2.4 calls for error reports

11.2.1 Email

Paragraph 1: Is it equally acceptable to send via SMTP over SSL (port 465)?

Filename extensions: Is the .gz format just a GZIPped XML file?  That
isn't stated clearly, and if it is, why not make the extension .xml.gz?

11.2.2 HTTP

Paragraph 2: "POST or PUT" -- which method is used? Must reporting URIs
support both methods? Or is there a process for discovering which method
is to be used?

I'm not an expert in HTTP, but I have the feeling that this transport
(and all transports except possibly mailto:) is underspecified. For
example, what Content-Types MUST be supported? Are there any other HTTP
headers that MUST be included?

11.2.4 Error Reports

Paragraph 1: Last sentence seems to say that mailto: URIs are preferred
over other transports, which is the opposite of the last paragraph of
section 9.

Why is the error report in a text/plain format rather than a text/xml
format like the feedback reports themselves?

"Note: A more rigorous syntax specification...will be added here" says
this is still an experimental capability.

12. Capacity Planning

DNS: This understates the actual DNS load; there will be additional
queries in connection with looking up and sending feedback and aggregate
reports, additional queries associated with reporting addresses that are
outside the current domain, and probably other things I haven't
considered (like DNSSEC). A more thorough analysis is needed here.

13. Minimum Implementations

Please provide separate minimum requirements for Domain Owners (or other
publishers of DMARC records) and Mail Receivers. Bear in mind that
Domain Owners, etc. may not themselves receive the reports.

14. Privacy Considerations

One privacy consideration I don't see listed anywhere is forwarding
privacy: Basic email provides good protection against message senders
finding out the actual delivery address of forwarded mail. The reporting
capabilities of DMARC make it trivially easy for a Domain Owner to
discover the delivery address of a message delivered to a
DMARC-compliant Receiving Domain.

14.2 Report Recipients

It might be noted that the privacy consideration is not that different
from a domain with an MX record that is handled by someone outside the
domain.

14.4 Secure Protocols

Should there be a requirement that if the original message was sent with
TLS, that feedback reports be sent securely?

15.1 Use of RFC5322.From

Last paragraph: "This document prescribes no specific action, other
than..."  Section 10.1 does indeed prescribe a specific action that
SHOULD be taken.

15.3 DNS Load and Caching

It would be good to see a more thorough analysis of DNS effects -- both
the number of queries that DMARC adds and the possible use of DMARC
records (large records, at well-known locations in DNS) for DNS
amplification attacks.

15.5 Identifier Alignment Considerations

Paragraph 1: Don't the concerns about SPF apply apply to DKIM key
records too?

Paragraph 3: "cede" -> "delegate" (administrator doesn't actually lose
control)

16. IANA Considerations

I didn't review this section.

17. Security Considerations

Check RFC 6376 Section 8.x for other attacks that might be documented
here. In particular, attackers might publish intentionally malformed
DMARC records in conjunction with domains they control and send mail
from in an effort to make DMARC less useful or onerous in some way, in
an effort to discourage its use.

17.2 DNS Security

This should emphasize that both the publication of DNSSEC by Domain
Owners and the use of DNSSEC-aware resolvers by Mail Receivers is
needed.  See also RFC 6376 section 8.5.

Appendix A. Technology Considerations

These provide good insight into some of the design choices made in the
development of DMARC. Is the intent to include this in the
standards-track document, or is this just information to aid the
evaluation process?

A.3 Sender Header Field

Item 3: Note that there are already multiple ways to discover policy
(From Domain and Owner Domain), but yes, this would add to the complexity.

A.4 Domain Existence Test

This section indicates that there was operational experience that the
error rate was too high. Given that experience, I am surprised that
section 8 says that the receiver SHOULD reject the message.

Note that while [ADSP] does discuss checks for domain existence, it is
in connection with determining the ADSP result, not with rejection of
the message.

A.5 Issues With ADSP In Operation

This section reads like somewhat of a debate with ADSP, or as though
DMARC is competing with ADSP. DMARC and ADSP have different goals, and
different constraints (e.g., SPF is explicitly out of scope of ADSP) so
the list of issues doesn't really make sense.

A.6 Organizational Domain Discovery Issues

Paragraph 3: "Climbing the tree", explored extensively in the
development of ADSP, can of course be constrained to a specific limited
number of queries. But ultimately even a one-level climb was considered
too much and was rejected. Nevertheless, DMARC does look for policy in
two places (the From domain and the Organizational Domain).

The approach being used in DMARC was briefly considered in ADSP, but
didn't even make it into a draft at the strong advice of the DNS
Directorate that there is no way to reliably determine the delegation
level in a domain name.

B. Examples

It looks like these examples are attempting to define the syntax of
aspects of DMARC, rather than to be illustrative of things that are
defined normatively elsewhere.  I have not otherwise reviewed this section

C. DMARC XML Schema

Not reviewed.

=====

General Comments

There is no discussion of the effect of the effect of DMARC on some very
common situations, such as mailing lists and forwarding (except a couple
of hints at heuristics in the XML Schema). If the deployment of DMARC
has an effect on the delivery of messages sent through mailing lists,
that's a serious problem. I'm not aware of a straightforward answer to
that problem, other than to maintain a whitelist of mailing lists that
themselves authenticate their messages, which would normally not align
with the From addresses at all. This has been cited as a serious problem
with ADSP, so one would not want to repeat that problem here.

-Jim