Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
In article you write: >> I'd counter by personal anecdote that we have had to undertake >> security remediations because of messages which were forwarded by our >> CEO to other employees for responses which happened to contain malware >> and/or bad links. ... >Except that the problem isn't the email address, especially since almost >no one sees those any more. And the display name isn't protected. Do we have any recent numbers on how many users see the From address rather than or in addition to the display name? Signed, uh, someone ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC threat analysis needed
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://w
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/17/2020 11:30 AM, Kurt Andersen (IETF) wrote: Dave writes: However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user. I'd counter by personal anecdote that we have had to undertake security remediations because of messages which were forwarded by our CEO to other employees for responses which happened to contain malware and/or bad links. Presumably, the cachet which was carried along with "important person says look into this" overcame whatever native caution or skepticism might have prevented them from falling prey otherwise. Except that the problem isn't the email address, especially since almost no one sees those any more. And the display name isn't protected. I'm not quite motivated enough, or I'd have had this message contain: Kurt Anderson and it would have passed the necessary tests... In other words, when we talk about threats and we talk about mitigations, we need to be careful that they align properly. (I suspect there's some irony in my choosing 'align' but it was not intentional, though I'll take the extra point for noting it.) -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
Dave writes: However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user. I'd counter by personal anecdote that we have had to undertake security remediations because of messages which were forwarded by our CEO to other employees for responses which happened to contain malware and/or bad links. Presumably, the cachet which was carried along with "important person says look into this" overcame whatever native caution or skepticism might have prevented them from falling prey otherwise. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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
