Colleagues, This is my AD evaluation for DMARCbis. I've taken the liberty of preparing it even though the shepherd writeup is not yet uploaded and the chairs have not yet formally requested publication.
There's a Google document to which everyone has "view" access at the link below for the details as there's a large number of aesthetic tweaks I made (missing or mismatched quotes, etc.) and minor text suggestions, but the non-trivial things I'd like to raise and possibly discuss are laid out here. If you're not one of the document editors, you probably don't need the Google document, but here it is anyway if you're curious: https://docs.google.com/document/d/14Mz005MU2lIIL0zOZxgdkOFprW57clrsmumToJvwVMU/ I recognize that this document has WG consensus, and my own views about some things are in the rough. Where I appear to be challenging consensus, look at it more like I'm trying to help you make the WG's position less likely to meet obstruction. I'm not blocking it from moving forward. It was a long road to get here, I realize. There are still some steps we need to get through before this can be published, and it's unclear how smooth of a ride that's going to be. There will almost certainly be more feedback. Let's please try to build or at least preserve whatever momentum we have left to get it across the finish line. More on this later. Here we go, in top-down (i.e., not priority) order: In Section 2.1, under "High-Level Goals", there's a bullet that reads thus: "Minimize implementation complexity for both senders and receivers, as well as the impact on handling and delivery of legitimate messages." Given the collision with indirect mail flows, which I don't think this document actually improves relative to RFC 7489, do we feel like we met this goal, at least the part after the comma? Should we revise this so we don't draw fire for a failure here? In Section 2.4, "Out Of Scope", there's this bullet: "Reporting or otherwise evaluating other than the last-hop IP address;" ...which reminds me that ARC is in an unresolved state. Is the plan to ship DMARCbis without any particular reference to its use and "Update" it in later? There's another reference to ARC later in the document as well. In Section 3.2.8, "MTA" is defined as "Mail Transport Agent", but we also import definitions from RFC 5598, which defines it as "Message Transfer Agent". We should probably match that. In Section 3.2.10, two things: * Did we ever discuss RFC 7505 in this context? * This is the first place I noticed that in some places throughout the document (and there are many instances), a reference to another RFC looks like the usual "[RFCxxxx]", but in others it's the more verbose "RFCxxxx, <title>". We should pick one or the other and use it throughout, and I suggest that the former is far more common. Section 3.2.12 is the first reference to PSD. About PSD in general: This document introduces this concept, as a significant change since RFC 7489. Appendix C identifies it as a major change, which is good, but I'm wondering if somewhere we might want additional text that describes the likely interaction between Domain Owners relying on PSD and Receivers relying on the old PSL way of doing things, or vice versa. Are there any interoperability concerns? Section 3.2.15 refers to "messages related to another operator's domain". If there's an example of such an arrangement in the appendices, this is one spot where I felt I'd like a more complete description so a forward reference would be helpful for illustration. In Section 4.4.1, I thought it might be helpful to make an explicit statement that there is no currently accepted common mechanism for declaring a third-party relationship in terms of signing and DMARC evaluation, though several have been considered. Section 4.4.2 needs the same thing about SPF, so maybe an additional subsection that says the same about both would be better. Section 4.5 says: DMARC Policy Records are stored as DNS TXT records in subdomains named "_dmarc". Are those subdomains? Aren't they just records in the domain? I suspect DNS people might get picky here. In Section 4.6, the SHOULD needs justification. In Section 4.7, just out of curiosity, how much have we observed use of the "fo" tag in the wild? Same section, for "np", we might want to include a link to where "non-existent domain" is defined in the DMARC context. Same section, for "psd", in the "y" block, there's use of the term "policy domain" for the first time in this document. I'm thinking it needs a formal definition somewhere (or just spell it out here). Same section, again for "psd", in the "u" block, we say "There is no need to explicitly publish psd=u in a DMARC Policy Record." Do we need to say that when we already say it's the default? Same section, for "rua" and for "ruf", instead of "URIs not supported...", I think we want "URI schemes not supported ..." Same section, for "t", in the "y" block, we find the first reference to the idea of From field rewriting. Does this need treatment or a reference somewhere before we run into it here? In Section 4.8, I think there's an ABNF ambiguity in that "dmarc-record" ends with *WSP, but so does the optional "dmarc-sep" right before it. Section 4.10 is the first place where the PSL is mentioned. We might want to include a forward reference to Appendix C here; left by itself, it assumes the reader has that context. Also in Section 4.10, I don't know what the purpose of Step 3 is. Same section, I think there's a problem with Step 7. If I'm following this correctly, this query might return a single record containing "psd=n" and there might still be one from Step 2 that contains "psd=y". This test then fails because it's not true that "a single record remains", so the algorithm continues. Steps 6, 7, and 8 are then repeated up to the limit at which point the algorithm stops with two or more answers in the set. Is that what's intended here? What does a filter do with that? Section 4.10.1 says: "Note: PSD policy is not used for Organizational Domains that have published a DMARC Policy Record. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so." So back in Section 4.7, the formal part, should we say expressly that "psd=y" MUST NOT be used with the "rua" and "ruf" tags? Section 5.1.1, regarding SPF, says: "... SHOULD be constructed to ensure that only those authorized sources can get an SPF pass verdict." Why is this only SHOULD when it's MUST for DKIM (Section 5.1.2)? I think Section 5.3.1 should say more about multi-valued From and what MUAs tend to do with it. Otherwise, this almost says "If you want to bypass DMARC, just use a multi-valued From field." Are attackers not incentivized to try? In Sections 5.3.3 and 5.3.7, the SHOULDs need to be justified. The one in 5.3.9 is a little better, but it could say more. The second paragraph of Section 5.4 is significant. I think Section 10 should contain a reference to it, or maybe this paragraph should move there and be replaced by a reference to that. Same section, we have "important that Mail Receivers not reject messages solely because of a published policy of "reject", ..." Does this warrant a SHOULD NOT? Section 6 introduces, but does not define, the terms "PSD DMARC" and "org-level". In Section 7.1, the two M3AAWG links need to become informative references. Section 7.2 strikes me as something that isn't likely a novel discussion, so is there any other DNS document we can think of where we can reference the topic? At the bottom of Section 7.3: RFC 7372 introduced enhanced status codes related to mail authentication; should we consider registering some for DMARC? A note to Tim: I think the shepherd writeup needs to call out that the material in Section 7.5 was controversial, though the WG did reach consensus on the text that's there. Same section: I also think -- and this is probably my most significant piece of feedback for the WG -- that we need to include some discussion of the fact that we are knowingly advancing to the Standards Track something that has serious and well described interoperability concerns. This is being done because (give reasons here). This could go here or in its own section (definitely not in an appendix). RFC 6377 is available as a reference to describe some of the disruption. Just as with the principle behind Security Considerations sections, I think it's more important to highlight that we know there are problems, but believe this is worth publishing at Proposed Standard anyway. Same section: We're saying receivers MUST NOT reject based solely on the DMARC result. I feel like we're pushing the interoperability problem onto receivers here. What advice do we have for them around how to go about doing this? What properties of a message should they be looking at to head off this problem? Is anyone successfully doing this today? In several spots in Section 8, the text talks about creating a registry, but the registry already exists. For each, we should instead say that RFC 7489 created the registry, but all existing references to that document should now point here. Section 10.4 talks about display name attacks, and I wonder if we have any (even vague) figures that compare the display name problem to the direct domain attack problem. If we think this is going to take out a small portion of the problem, or if we think the display name attack will grow as a result, we should probably say so. The second paragraph of Section 10.8 took me several times to read and parse. Maybe an example would help. Same sort of remark about the fourth. Section 10.8 also talks about "periodically checking the DMARC Policy Records, if any, of PSDs" but doesn't talk about how one might achieve knowledge of where they are. Is this just caching of the ones you've discovered? In Appendix A.1, S/MIME is RFC 8551. In Appendix A.3, DomainKeys is RFC 4870. Appendix A.6, third paragraph, third sentence, total parse failure. Appendix C.1, a correction: RFC 7489 has no IETF category or status at all. It's an informational RFC that was not a product of the IETF. In fact the only IETF review it got was the IESG confirming that it doesn't conflict with any work in the IETF already in progress. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
