[dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Seth Blank <[e-mail]>]

As an individual, below are my comments and nits.

Top line:

1. The document needs to consistently use "verification" "validation" or
"authentication" -- 7489 used "validation" in its abstract, and I'd
recommend we stick with that.

2. The abstract, introduction section 2.2 still needs to be tightened up
after the rest of the document settles. In particular, alignment is the
most critical component of DMARC, and it is not mentioned in the abstract.
The introduction and anti-phishing (2.2) sections can be made much tighter
and to the point, and with fewer subjective parantheticals. I'm happy
to propose text here once the rest of the document is settled.

3. Domain Owner Actions section needs cleanup; notes below. I'm also
willing to propose text for this.

4. Consistency and definition of terms: In general, terms should be defined
before they're used. Probably because some of the document has been
reordered, there are several places that begin text without properly
referencing or defining terms. For example, the term "target domain"
appears three times in the document but is never defined. Is this an
accidental shorthand for Author Domain? Something else? There are a bunch
of throw away terms like "DMARC-Compliant" which are only used once. Can we
get rid of these and use simple descriptive language like "Receiving mail
systems that properly evaluate DMARC"?

5. To channel Crocker: always "header field" never just "header"


Specific nits:


Section 1: Introduction:

"As with SPF and DKIM, DMARC reports results as "pass" or "fail"." is
confusing to someone expecting the introduction to cover reporting. Clearer
would be "As with SPF and DKIM, DMARC validation results in a "pass" or
"fail" verdict."

The introduction should also more clearly and simply call out that DMARC is
about Aligned Authentication, Reporting, and Policy Conformance and how
they interrelate in one place, before describing them separately.

I have many other concerns/recommendations in this section, but will
provide text separately.


Section 4:2: Use of RFC5322.From:

Is it also worth it to call out that time and operational impact have
proven this to be the right choice?


Section 4.4: Identifier Alignment Explained:

Both relaxed and strict alignment are defined in the midst of paragraphs in
this section, but have no section headings nor earlier high level
definitions in 3.2. As they're such core concepts, this feels lacking.


Section 4.4.1 and 4.4.2:

Naive question: Both sections call out requiring the aligned identifier to
be an FQDN. Is this sufficient with the extension of DMARC to PSDs? Would
this mean that .google can never be a source of authenticated mail? Is that
desirable?

Do we want to remove the reference to FQDN and say that an aligned
identifier must be at or below a valid Organizational Domain?


Section 4.6: DNS Tree Walk:

The text is correct, but N is wrong. I've shared my notes with this list
but we never reached consensus:
https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/

tl;dr: N of 5 works for *org domain discovery* but falls short
*policy/reporting* discovery. The algorithm can stay the same, but N needs
to be increased and the text to match.

I *strongly* believe that N needs to be 8 to meet operational use cases
we see today, and may still fall short in the future as this use case is
unlocked by the tree walk.


Section 4.7: Policy Discovery:

The policy discovery that covers p=, sp=, and np= is technically correct,
but confusing to parse. I'd recommend this be a clear algorithm like the
preceding tree walk and the following org domain discovery.


Section 4.8: Organizational Domain Discovery:

The algorithm (step 2) that covers the psd=y case could use an example.
"One label below" is technically correct, but anyone not intimately
familiar with DNS terminology might make a mistake, so a precise example
would help.


Section 5.3: General Record Format:

Shouldn't the RUF options be defined in the RUF document, as opposed to the
primary bis document?

psd: "n: The DMARC policy record is published for a PSD, but it is the
Organizational Domain for itself and its subdomain."

-> "subdomains."


Section 5.5. Domain Owner Actions

This section makes sense piecemeal, but doesn't quite work as a whole.

The text in 5.5, 5.5.1, and 5.5.2 should be reordered a touch and cleaned
up. Explanation for both SPF and DKIM is in the SPF section, and the DKIM
section covers too much about SPF. Also, the "SHOULD first ensure SPF and
DKIM" in 5.5.1. seems strange, as there's no way to do this prior to
section 5.5.4.

I would argue the 5.5.1 and 5.5.2 should be moved after 5.5.4.

There also appears to be a missing section between sections 5.5.5. and
5.5.6. which should be "remediate unaligned or unauthenticated mail
streams" i.e. use the output from collecting and analyzing reports to
actually make sure all your mail flow is properly authenticated, ideally
with both SPF and DKIM, with at least one aligned.


Section 5.5.6. Decide Whether to Update DMARC Policy:

The final paragraph mentions "deliverability" which I do not think is
appropriate for this document. It is also worth calling out here the
interoperability challenges of NOT sending aligned mail that is capable of
receiving an aligned pass, as this mail is increasingly likely to get
rejected regardless of what policy you publish.


Section: 5.7.2. Determine Handling Policy

I know we say the steps MAY be done in parallel, but even so shouldn't step
4 (SPF) come before step 3 (DKIM)? In practice, SPF was designed to be
validated as early in the mail flow as possible (during 5321), and this
could be an unintended normative change to SPF in a DMARC context by
requiring evaluation after DKIM can validate 5322.

The penultimate paragraph also exposes a nasty security consideration. If
an attacker can get SPF and DKIM responses to return temperrors, then DMARC
evaluation will fail and advertised policy will not be applied. This
doesn't seem desirable. If there's a policy that is not none, and SPF and
DKIM can't pass, why wouldn't the policy get applied?


Section 7.6: Expansion of Domain Owner Actions Section

Already covered by Todd, but this should be SHOULD NOT, not MUST NOT.


Section 8.1. Issues Specific to SPF:

This is a real operational problem, so I wanted to expand guidance. The
note about best practice may or may not be appropriate here, but I think it
works. There are multiple M3AAWG documents which cover this use case, and
we can also link them if valuable.

OLD:

Some Mail Receiver architectures might implement SPF in advance of any
DMARC operations. This means that a "-" prefix on a sender's SPF mechanism,
such as "-all", could cause that rejection to go into effect early in
handling, causing message rejection before any DMARC processing takes
place. Operators choosing to use "-all" should be aware of this.

NEW:

Some Mail Receiver architectures implement SPF in advance of any DMARC
operations. This means that an SPF hard fail ("-") prefix on a sender's SPF
mechanism, such as "-all", could cause that rejection to go into effect
early in handling, causing message rejection before any DMARC processing
takes place, and DKIM has a chance to validate the message instead of SPF.
Operators choosing to use "-all" to terminate SPF records should be aware
of this. Since DMARC only relies on an SPF pass, all failures are treated
equally. Therefore, it is considered best practice when using SPF in a
DMARC context for domains that send email to end records with a soft fail
("~" / "~all").


Section 10.2. Failure Report Considerations:

Add a preceding sentence before "out of band" that says "Due to the nature
of the email contents which may be shared through Failure Reports, most
major receivers refuse to send these reports on privacy grounds."


Section 11.4: Display Name Attacks:

This feels out of place. Even though it's mentioned as a different problem,
this is a lot of content irrelevant to the spec itself. Do we need it at
all outside the second paragraph?



-- 

Seth Blank | Chief Technology Officer
Email: [e-mail]


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.