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

[Douglas Foster <[e-mail]>]

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