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-bounces@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