Hector, I think I am reading RFC 5016 section 5.3 differently from you. My paraphrase:
This SSP assertion is allowed: "Example.com says: Example.com messages can be considered authorized if and only if they have a signature from our domain." This SSP assertion is not allowed: "Example.com says: Example.com messages can be considered authorized if and only if they have a signature from our domain, and DO NOT have a signature from OtherGuy.com domain" The second assertion is not allowed because Example.com should not be "impugning" the validity of a signature from OtherGuy.com. Example.com is not empowered to be a reputation service for unrelated entities. However, the language of this section directly supports the DMARC implementation. To solve the MLM problem, you need to explain how MLMs become authorized by the author domain to send on behalf of the author, without authorizing spammers to send on behalf of the author. It seems that we have an architectural problem because the current infrastructure assumes a single author. In reality, we have multiple situations that involve multiple authors. For example, this message includes your entire note, and your note includes part of Jim's note. But those notes no longer have valid digital signatures, so there is no proof that I have represented you correctly, and it is technically possible for me to rewrite your comments entirely. A similar problem occurs if my spam filter adds content to a message as it arrives into my domain, content that is really intended for "internal use only". The additions will break incoming signatures, although this is tolerable because signatures are not checked again, as long as the message remains internal. But if a message is auto-forwarded to another domain, the additions are probably inappropriate and the message no longer passes Sender Authentication. I would like to be able to preserve the original signature throughout, and remove the internal spam filter content when the message leaves the internal domain. Consequently, I am dreaming about an architecture that allows mediators to add content under their own signature without voiding the signature of other sections. The concept is a combination of John's ARC project, which uses nested signatures , and Murray's tagged content, which acts as a change log. It would allow an MUA to clearly identify the content contributed by the different authors, and it would contribute to solving the MLM problem. It is easier to imagine how it could be used to identify additions, such as a message footer, then to identify alternations, such as a URL rewrite. And the whole thing may be too complicated to implement in a way that is upward compatible with the present architecture. But it would be a better model of reality. Doug Foster -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Friday, July 17, 2020 12:02 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC threat analysis needed On 7/15/2020 8:14 PM, Jim Fenton wrote: > Unburying this from a different thread. > > I'm really struggling to understand what problem(s) DMARC is trying to > solve. The most common answer I have heard says something about > "defending brand identity", which is a marketing, not a technical > consideration. > > IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the > technical requirements. I am NOT volunteering to do this. Jim, if we review both RFC4686 and RC5016, I believe we might find there is not much to be changed. However, imo, something will have to be done regarding RFC5016 section 5.3 item: https://tools.ietf.org/html/rfc5016#section-5.3 5.3. Practice and Expectation Requirements 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. This provision with strict protocol language "MUST NOT" prohibits any DKIM Policy protocol, formally called SSP "Sender Signing Practices" and now today, DMARC, from impugning on 3rd party policies such as how a MLM operator via local policy exceptions can ignorantly and blinding destroy the integrity and resign the mail instead of just honoring it. This language would have be updated or removed and just leave the implicit idea that local policy always prevails in all SMTP situations. Have a good weekend, be safe. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc