Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[David I <[e-mail]>]

During IETF 108, the chairs realized that there was interest in Dave's
RFC5322.Sender draft.

This starts a Call for Adoption for draft-crocker-dmarc-sender

The draft is available here: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-crocker-dmarc-sender%2F&data=02%7C01%7Cdavid.i%40ncsc.gov.uk%7C8b6f69bd79a0456b083a08d83d605162%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637326831179930300&sdata=essow9o1nmqARNXCr%2BUFkBhUwomyBq0E0dpxzzK7q9E%3D&reserved=0>

Currently, the draft is marked as "Standards Track".  The chairs feel if the
working group does adopt this, it should begin as "Experimental".  If we start
to see adoption of this work, this can be changed back to "Standards Track" before
Working Group Last Call.  Of course, we welcome input from the working group on this.

Please review this draft to see if you think it is suitable for adoption, and
send any comments to the list, clearly stating your view.

There's some good thinking in the document, that however leads me to a different solution space. There are also some bits which aren't clear enough for me to fully analyse the security impact, and some places where I think it's lacking.

In a little more detail:
- The reflection that mediators are going to have to implement approaches like From-rewriting for at least a while leads me to think that standardising From rewriting is a better way to go. Standardising would allow recipient systems to undo the From-rewriting if they trust the intermediary and the email is authenticated (perhaps simple DKIM, perhaps something ARC-related). This has the benefit that the intermediary doesn't need to worry about whether it's trusted by the recipient, or whether the recipient has implemented <insert new system here>. I agree with everyone who thinks it's somewhat distasteful, but seems least-worse to me given today's email environment.
- It's not clear to me in the doc which domain is being referred to in various places. eg assuming From: [e-mail]<mailto:[e-mail]>, Sender: [e-mail]<mailto:[e-mail]>, which domain's DMARC policy should have the snd tag? If I never add the snd tag to _dmarc.from.example, do I get to keep today's behaviour?
- It turns a fact based check 'did the DMARC checks pass for the From domain' to a fuzzier reputation based one. This *may* be similarly effective at scale against volume spam, though I'm sceptical. I don't believe it's true for low-volume spear-phishing where 'a few getting through while the reputation system trains itself' isn't good enough.
- Comparing this to ARC, there's no passing of information about what authentication checks an intermediary did, nor a statement that an intermediary should be doing strict DMARC authentication and not passing on things which fail. That makes the 'trust' decision at a receiver much harder as you don't know if any authentication has taken place.
- As a reputation/trust based mechanism, it shares weaknesses with ARC - difficulty of bootstrapping, and favouring large and existing players. So I don't think it's expanding the solution space much, and risks distracting from ARC and then running into similar issues.
- The absence of a mechanism to get away from From-rewriting or similar (even in the long term), means this would be additional complexity with little, if any practical upside.

Given the above, I don't think this is a fruitful path, so I don't support adoption at this time.

Regards,
David

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail]. All material is UK Crown Copyright ©