Subject: [dmarc-ietf] Ticket #112 - Authentication vs. Repudiation.

From: Douglas Foster <[email-masked]>
Date: Sat, 26 Jun 2021 12:35:38 -0400

DMARC is very effective for message authentication.  DMARC PASS allows
preferred handling to be applied without fear of spoofing.  For example:

If DMARC=PASS
and RFC5322.FROM ends with “EXAMPLE.COM”
they Bypass Tests ( “Spam Scoring”,  “Attachment Restrictions” )

(Curiously, I had trouble finding products which could implement this type
of rule, suggesting that we need more best practice documentation.)

However, DMARC has proven to be ineffective as a tool for message
repudiation.    DMARC FAIL does not necessarily mean spoofed content, it
can mean many things:

·         If the message contains a DKIM signature that does not verify:

o   the message was forwarded with modifications

o   the signature hash was computed incorrectly at creation

o   the signature hash was computed incorrectly at reception

o   the signature and the message are fraudulent

·         If the message does not contain a DKIM signature at all:

o   the SPF policy has an omission

o   the SPF policy has a PERMERROR mistake

o   the message was forwarded

o   the message is from a tolerated and non-malicious impersonator

o   the message is fraudulent

Given these diverse possibilities, DMARC FAIL is not a reliable indication
that the message should be blocked, whatever the sender policy.
Quarantining might be the best response, if evaluators have the human
resources with sufficient skills to evaluate each such message, so that a
determinative policy can be created.

Overall, Sender Authentication meets the primary needs of message
senders:   their messages can be verified with SPF or DKIM in the hope that
their messages will be more likely to be given preferred handling.

Message receivers are very concerned about malicious messages being
accepted, so repudiation has a high interest level, and these interests are
not satisfied with an Authentication-Only result.   Some vendor products
and some system managers have responded to this need by treating an
authentication failure as if it provides confirmed repudiation.  Such
behavior is not justified and has created all of the problems documented by
RFC 7960.

The notion of an NP policy reverses this situation.  NP has no ability to
provide authentication, and is only evaluated when authentication fails.
But it can provide confirmed repudiation for a subset of the organization
or PSD name space, specifically the names which are never used for a
particular purpose.

The PSD proposal defined a two-way split:   names which are plausibly used
for SMTP are considered valid, and names which are not plausibly used for
SMTP are considered invalid.   As I have discussed elsewhere, this creates
errors because it involves guessing the sender’s intention and it excludes
certain name usage scenarios.

Given that we have two usage states (valid or invalid) and two usage
locations (RFC5321.MailFrom and RFC5322.From), we have four possibilities
for any specific name:

1.       Name used by domain owner for both MailFrom and From.   A message
which uses this name is not repudiated.

2.       Name used by domain owner for MailFrom only.   A message which
uses this name in the From header is repudiated.

3.       Name used by domain owner for From only.  A message which uses
this name in the MailFrom address is repudiated.

4.       Name used by domain owner for neither MailFrom nor From.  A
message which uses this name is repudiated.

How to document and evaluate these categories:

We have the available tools to distinguish the SMTP portion of this problem:

·         An SPF policy which evaluates to at least one IP address
indicates that the message is used for SMTP, and the message must be in
categories 1 or 2.

·         An SPF policy of "-ALL" indicates that the name is never used for
SMTP.   The message must be in category 3 or 4.

·         An SPF policy lookup which returns NXDOMAIN indicates that the
name is not defined in DNS, and therefore has no return path.   For
purposes of NP processing, it is appropriate to treat this result as
equivalent to a policy of “-ALL”.   The message must be in category 3 or 4.

·         A message which does not have an SPF policy is ambiguous, but if
the domain owner has published an NP policy of reject or quarantine, the
absence of an SPF policy should be treated as equivalent to rejection
(“-All”).

What we lack is an equivalent mechanism for indicating whether a name is
used in an RFC5322.From header.   I have proposed that this be implemented
as a TXT record, because it must be possible to assign the signal to any
possible DNS name.  To handle all four categories, we need both a positive
signal (name is used for From) and a negative signal (name is never used
for From).

We can assume that in the absence of a signal, the From signal matches the
MailFrom signal.  This minimizes the number of DNS entries required, and
simplifies the conformance effort for domain owners who wish to utilize the
NP policy.

·         When SPF evaluation indicates that the name is valid for SMTP,
then

o   If the DMARC signal is present and positive, the signal is redundant
and category 1 applies.

o   If the DMARC signal is absent, positive is assumed and category 1
applies.

o   If the DMARC signal is negative, category 2 applies.

·         When SPF evaluation indicates that the name is not valid for
SMTP, then

o   If the DMARC signal is present and positive, category 3 applies

o   If the DMARC signal is absent, negative is assumed and category 4
applies.

o   If the DMARC signal is negative, category 4 applies.

Application of the NP policy

If the NP policy is NONE or not published, the domain owner has not
indicated compliance with this mechanism, and the SP policy is applied.

If the NP policy evaluates to “not repudiated”, then the SP policy applies.

If both NP and SP are set to reject or quarantine, then all unauthenticated
messages will be rejected by one or the other of the policies.   Messages
rejected because of NP have a higher level of certainty because they are
verifiably repudiated.

Notes about the NP approach:

·         NP does not protect all names; it only protects unused names.
For example, it does not solve the problem of messages that are processed
through a content-altering mailing list.   However, the mailing list
problem only applies to names that are valid, so a message with a
repudiated name is reliably not affected by the mailing list problem.  The
universe of unused names is very large, so blocking such usage is a
significant benefit to mail evaluators.

·         Some DMARC failures are caused by non-malicious impersonation by
trusted senders, and these can be wanted messages which will be given a
DMARC exception.   Operational experience indicates that these senders only
impersonate existing names that they have obtained through legitimate
interactions, so they will not be using invalid names and will be
unaffected by the NP policy.

Conformance effort for domain owners:

·         Determine all used names and how they are used.

·         Add DMARC positive DNS entries as needed to indicate names in 3.

·         If desired, add DMARC negative DNS entries to distinguish
category 2 from category 1 for improved enforcement.  In the absence of a
negative signal, category 2 messages will be handled as category 1 and
never repudiated.

·         When ready, publish a NP policy of quarantine or reject.

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Mon, 28 Jun 2021 08:57:20 -0400

On Sat, Jun 26, 2021 at 12:36 PM Douglas Foster <
[email-masked]> wrote:

> The reason you can't find products implementing that type of rule is
because there is no need for such a rule.

DMARC establishes the authenticity of the identity of the party responsible
for the message; DMARC makes no claim as to the quality, worthiness, or
desirability of the message.

DMARC ensures that your mail gets treated in a manner that is consistent
with the reputation earned by the responsible identity. Spam messages can
and do pass DMARC authentication checks every single day, and in large
numbers.

Passing DMARC should not lead to bypassing tests such as Spam Scoring or
Attachment Restrictions. All spoofs are spam, but not all spam is spoofed.

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Douglas Foster <[email-masked]>
Date: Tue, 29 Jun 2021 10:54:25 -0400

What is so hard to grasp'?

"Treated in a manner that is consistent with the reputation of the
responsible party"
means that
"the message is safe to whitelist if whitelisting is desired."

I was not saying that DMARC=PASS was a basis for whitelisting.   I said
that DMARC=PASS and a trusted identifier is a basis for whitelisting (when
necessary to avoid false positives.)

Any product can do whitelisting based on a single attribute, but
whitelisting requires at least two attributes:  a trusted identifier or set
of identifiers, and a verification status which indicates that the
identifiers are not spoofed.   Therefore the primary value-add from sender
authentication is that it allows me to whitelist messages from trusted
senders to avoid false positives.   As we have both said, sender
authentication=FAIL is a can of worms, but it is not identical with
Repudiate.

BUT MORE TO THE POINT

If you believe that the ex'sting NP language is sufficient and effective,
just explain why you believe this is so.   A justification is all that my
original topics requested, and this has not been done.  For my part, I
don't see a test definition that can be implemented reliably, all I see is
a test name.  Any attempt to code the test introduces questions that have
not been addressed, such as SP="-ALL" and MX= ".".  Similarly, I see a
concept name, "non-existent", which is also undefined.  Any attempt to
interpret "non-existent" will expose ambiguities.   This language is simply
not up to IETF standards.  When I try to fix the language, I find that the
design is not merely vague, it is wrong.

So please answer these questions:

   - Do you believe the problem and the solution are well defined in the
   current specification?
   - Can you explain why the solution is the best possible fit for the
   problem?
   - Have you evaluated the problem and solution against an actual mail
   stream to see if it works?
   - Have you asked someone to attempt an implementation of this part of
   the specification?

In short, the group needs to stop telling me why I don't think straight, or
why I am incomprehensible, why I should shut up, and instead start telling
me what they believe and why.

Those who cannot or will not do these things, should let someone who has
evaluated this idea against a real mail stream take the lead.

Doug Foster