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

[Jim Fenton <[e-mail]>]

Below is a number of “minor issues and editorial comments” on 
dmarcbis-30. I have a larger issue regarding the draft as a whole that I 
have yet to write up and will post separately.

-Jim

=====

1\. Introduction
----------------

Paragraph 3 introduces alignment, and goes into relaxed and strict 
alignment (which seems like a lot of detail this early). But then 
paragraph 4 doesn’t talk about alignment at all, but rather whether 
the RFC5322.From domain has been authenticated. This seems like a 
disconnect from alignment, since it doesn’t say what 
“authenticated” means.

Paragraph 5 again jumps terms, from “authenticated” to “passes 
verification”. It seems like this means the same thing, and should use 
the same term (or at least explain the difference).

Paragraph 5, last sentence: perhaps “should not affect its 
reputation.”

Paragraph 6, don’t need quotes

Paragraph 7, “identify, not only sources”: Does “identify” mean 
that it claims to know where they came from? Seems like a different word 
like “flag existence of mail” might be better.

2.1 High level goals
--------------------

PSOs: Define this abbreviation on this first use. Since it’s talking 
about a public suffix, “the domain” doesn’t seem sufficient, maybe 
“the domain or suffix”.

Side note: I’m very dubious about the allowances for DMARC records to 
be published by public suffixes since the PSO is much less likely to 
know the usage of the domains under it, and whether a policy like Reject 
is appropriate. But I suspect the WG decided to include the public 
suffix policies so this would be a relitigation.

2.2 Anti-Phishing
-----------------

“Claims to come from legitimate senders” — should specify in what 
way this claim is made.
“Informed by ongoing efforts” - Can any be cited here? Otherwise 
this is a throw-away sentence.

2.4 Out of scope
----------------

Entities other than domains: Public suffixes aren’t (necessarily) 
domains, but they aren’t out of scope. I would say authentication at a 
finer grain than domain is out of scope.

4.1 DMARC Basics
----------------

Paragraph 1: “verification” again

Paragraph 2: Awkward wording: aligned supported authentication mechanism

Paragraph 5: “feedback component”: maybe “reporting component”? 
Feedback seems like an inappropriate term when the reports might go to a 
third party and not the purported source.

4.2 Use of RFC5322.From
-----------------------

Second bullet: “most MUAs display some or all of the contents of that 
field”. I find this becoming less and less true. Many MUAs that I use, 
including Apple Mail (iOS) and Outlook, display only the Display Name, 
which is not authenticated at all as pointed out much later (11.4).

Third bullet: “Many high-profile email sources…”: This doesn’t 
seem actionable since DMARC does not have a means for the source to 
assert that it authenticates the individual sender. So the recipient 
would just be guessing.

Last paragraph: I don’t see a profile of RFC5322.From in section 5.7.

4.3 Authentication Mechanisms
-----------------------------

Bullet 1: “verified DKIM-Signature” vs. bullet 2 “SPF, which can 
authenticate”.

4.4 Identifier Alignment Explained
----------------------------------

Drop the word “Explained” from the section title.

Paragraph 1: “DKIM authenticates” (compare with Sec. 4.3 use of 
“verified”)

Paragraph 2: This would be a much better place to put the examples of 
relaxed and strict alignment that appear in later sections. The 
definitions weren’t sufficient for me.

Paragraph 3: Also site the profile of RFC5322.From (wherever it is) when 
talking about non-compliant cases.

4.4.1 DKIM-Authenticated Identifiers
------------------------------------

Paragraph 1: Authenticity of the Author Domain: “Authenticity” seems 
more like it has to do with whether it’s a real domain or not. Maybe 
“association with” or something like that?

Paragraphs 2-4: This would be better back in Sec. 4.4 and reference back 
to it.

Paragraph 5: “aligned and verified”. “Authenticated and aligned” 
maybe?

4.4.2 SPF-Authenticated Identifiers
-----------------------------------

Paragraphs 2-4: Repetitive; also better back in Sec. 4.4. Or is there 
some subtle difference between SPF and DKIM alignment that I missed?

4.5 Flow Diagram
----------------

This diagram and accompanying explanation doesn’t help me at all.

“Solid lines”: Dashed lines, maybe?

4.6 DNS Tree Walk
-----------------

Step 2 starts talking about the psd flag without telling what it is. It 
would be much better if this discussion came after the flags and their 
meanings was introduced.

I’m concerned that some (admittedly rare) public suffixes with 
multiple components are not well served by this algorithm, such as 
pvt.k12.ma.us.

What happens if a domain that is not a public suffix publishes psd=y, 
either accidentally or maliciously?

Side note: I got well into this document before I realized that DMARC is 
publishing an assertion of being a public suffix. Some mention of that 
belongs back in the introduction.

4.7 DMARC policy discovery
--------------------------

Paragraph 3: “domain does not exist”: How is that determined, 
NXDOMAIN, NODATA? What happens with SERVFAIL (e.g., DNSSEC problem) or 
no response? And if a domain really doesn’t exist, isn’t that a 
reason to reject “with prejudice”?

Paragraph 4 bullet 1: “syntactically valid”: It seems like there are 
a lot of URIs with valid syntax that would not make sense here. What if 
someone publishes [sip://example.org](sip://example.org) or 
[gopher://example.org](gopher://example.org)? Also, don’t a lot of 
these things that have to do with reporting belong in one or both of 
those drafts (which I haven’t read yet)?

4.8 Organizational Domain Discovery
-----------------------------------

Paragraph 2, bullet 2: “DMARC mechanism does not apply”: What if 
there is a PSO policy? Or is that covered by the tree walk? (I may have 
gotten lost here)

5\. Policy
----------

Paragraph 2: “A Domain Owner…may choose not to participate...by not 
publishing an appropriate DNS TXT record”. But what if the PSO did? If 
they disagree with that record, they do need to publish a TXT record of 
their own, don’t they?

5.3 General Record Format
-------------------------

Finally, a definition of those tags I have been reading about! I think 
this belongs much earlier.

adkim and aspf: “Domain Owner requires”: should this be Domain Owner 
or PSO requires?

fo, rua, ruf: Should these be in the reporting documents instead?

sp: “applies only to subdomains”: Does this mean an immediate 
subdomain or sub-subdomain, etc.?

5.5.3 Setup a Mailbox…, 5.5.5, etc
----------------------------------

Does this belong in the reporting documents?

6\. DMARC Feedback
------------------

Again, I don’t think “feedback” is the best term here.

7\. Changes
-----------

The changes section usually appears very close to the end.

7.5.1 Tags Added
----------------

Probably inappropriate to cite \[RFC9091\] in this way — it’s being 
obsoleted, and this looks like a normative reference.

8.6 Interoperability Considerations
-----------------------------------

Paragraph 1: Alumni forwarders can also break DKIM signatures (although 
frequently not), and this should be acknowledged.

10.1 Aggregate Report Considerations
------------------------------------

Aggregate reporting could reveal sensitive traffic patterns, for example 
if Company A is in the process of an acquisition of Company B.

11.4 Display Name Attacks
-------------------------

This goes to one of the overarching concerns I have about DMARC. I am 
getting lots of spam and phishing with plausible display names but 
obvious throwaway addresses controlled by attackers. “Further 
exploration…needs to be undertaken” is not a sufficient response 
IMO.

Paragraph 3, bullet 2: Since this is easily defeated, why even mention 
it?

11.5 Denial of DMARC Processing Attacks
---------------------------------------

Paragraph 3: Regarding multi-valued From, I thought these were out of 
scope. They are not a “particular challenge” then.

References
----------

RFC7489 and RFC9091 should not be listed as normative references; they 
are being obsoleted by this document.

A.3 Sender Header Field
-----------------------

I don’t recall any use of Sender by DomainKeys. Where I do remember it 
was in Microsoft’s alternative to SPF, SenderID \[RFC4406\].

A.4 Domain Existence Test
-------------------------

This is the sort of thing I was looking for in Sec. 4.7 paragraph 3: 
this needs normative language saying how nonexistence of the domain is 
to be established.

A.5 Issues with ADSP in Operation
---------------------------------

Maybe include an informative reference to \[RFC5617\] here.

Item 1: Wildcards cannot be used, as RFC 5617 points out, because it 
isn’t possible to wildcard anything except the first element. One 
can’t wildcard \_adsp.\*.example.com. A tree walk was proposed and 
extensively discussed for ADSP, but working group consensus was that it 
was harmful to include (overhead, etc.).

Item 2: NXDOMAINs were considered out of scope for ADSP because ADSP is 
a policy published by the author domain, and there is no way to publish 
a policy for a nonexistent domain. The same argument could apply to 
DMARC as well.

Item 5: DMARC also has no mechanism for a slow rollout now that the pct: 
tag has been removed.

Item 6: ADSP has an intermediate policy, “all”. ADSP policies are 
declarative rather than imperative because WG consensus was that the 
author domain can’t tell the recipient what to do, hence “all” 
rather than “quarantine” and “discardable” rather than 
“reject”.

A.6 Organizational Domain Discovery Issues
------------------------------------------

It seems much safer to just point to RFC 7489 for a description of the 
PSL method than to repeat it here, where a non-careful reader might 
think that this is a recommended method.

A.7 Removal of the “pct” tag
----------------------------

Already mentioned in 7.5.2, I don’t think this much description is 
needed for something that isn’t part of the spec.

??? Not Found
-------------

I expected to find some text at least recommending a rewriting strategy 
for From addresses to be used by mailing lists and the like. But I guess 
that’s in RFC 7960, which is informational, so you can’t reference 
that normatively. Not sure what to do about that.