[dmarc-ietf] Fwd: Priming the Pump for Discussion - Ratchets

[Douglas Foster <[e-mail]>]

The goal is to partition all incoming messages into two mutually exclusive
groups:   Those messages which originated under domain owner control, and
those which originated under domain owner control, and those which
originated outside domain owner control.   This requires two things:

- First, that at origination, credentials are in place so that a first-hop
MTA can reliably perform this partitioning.   I have a much longer
analysis, but the short version is that this requires an aligned and
verified DKIM signature on all messages.   There is no partial
participation, which is why the percentage notion needs to be discarded.
 Of course, fully authenticated messages are always detectable.  However,
in the absence of DKIM on all messages, the partitioning is not possible
because both domain owner and non-owner messages will both fail to be
authenticated.

- Secondly, the message addresses and the associated DKIM credential must
be preserved until the message is received.   We know that this is not the
case because forwarding with changes will break the DKIM signature.   The
absence of verification does not reliably indicate the absence of domain
owner
control, it can result from a domain owner message which was modified or a
non-owner message which was received in transit for any reason.

Consequently, we need three categories:
1) Messages which can be reliably attributed to the domain owner because
authentication passess.
2) Messages which can be reliably attributed to non-owners because of a
repudiation rule.
3) Messages which are ambiguous because they neither meet an authentication
rule nor meet a repudiation rule.

When we acknowledge this three-category reality, we have solved the mailing
list problem.   Mailing list messages can never be in category one.   They
belong in category 2.  The current DMARCv1 specification forces them into
category 3.   The two-possibility worldview creates the problem.   The
three-possibility worldview solves the problem.

I suggest these repudiation rules:

Rule 1:  The domain owner asserts that all messages from this domain will
originate with a verifiable DKIM signature.   If a message does not have an
aligned DKIM signature, or does not have a DNS public key available for the
scope ID, then the message originated outside domain owner control,  As I
have said, this is a mandatory first step to any policy being applied to
non-authenticated mail.

Rule 2:  The domain owner asserts that all messages from this domain will
originate with an SPF policy, including messages from email service
providers.   Results of SPF NONE or SPF NXDOMAIN indicate messages that are
outside domain owner control.

Rule 3:  The domain owner asserts that all messages from this domain will
have RFC5322.FROM addresses that "exist".   Messages that do not have FROM
addresses which "exist" have originated outside domain owner control.  The
definition of "Exists" is still being debated, and I have expressed strong
feelings about the right definition.

Rule 4:  The domain owner asserts that all messages from the domain will
originate with an initial ARC Set.   Messages which do not have an ARC Set
from the domain have originated outside domain owner control.  I am
inclined to include broken-chain ARC sets in this rule, but John would be a
better person to clarify this question

Everything that is not authenticated or repudiated is in category 2.   I
understand that category 2 includes a large number of messages.   These
messages require more analysis because the DMARC result is indeterminate.
 In most cases, this means that the next step is to put the message through
the full suite of content filters.   If the message is not blocked based on
content filters, then it may be desirable to do an in-depth analysis of the
message. Full header analysis is complex, ambiguous, subject to spoofing,
and very much outside of the capabilities of this document.

Note:  I am being careful to use "outside domain owner control" because
some such messages are very much wanted and should not be blocked.   Even
though such cases exist, the partitioning effort is indeed useful, because
it can be used to block some unwanted messages.  So "p=reject" fails on
multiple levels:   It presumes that the domain owner knows that credentials
will be preserved until reception, which is false, and it assumes that
non-credentials messages should always be blocked, which is also false.
 "Pct=50" fails because it presumes that partial participation is possible,
and it presumes that a message evaluator will be willing to use a random
number generator to decide message fates.

Doug Foster


Doug Foster


On Fri, Jul 16, 2021 at 7:24 PM Jim Fenton <[e-mail]> wrote:

> On 15 Jul 2021, at 18:07, Douglas Foster wrote:
>
> >> The aligned DKIM signature test can have three conclusions, not just
> two:
> >>
> >> ·         Fully Authenticated:    A signature is present, a DNS public
> >> key is available, and the key can be used to verify the signature.
> >>
> >> ·         Provided:  A signature is present, and a DNS public key is
> >> available, but the key cannot be used to validate the signature.
> >>
> >> ·         No Signature or No key:  A signature is not present or is
> >> present but the DNS public key is not available.
> >>
> >> If the domain owner indicates that all messages originate with a
> >> signature, then messages with “No Signature or No Key” are verifiably
> not
> >> from the domain owner and can be confidently repudiated.
>
> Why would “Provided” be handled any differently from “No signature or no
> key”? An attacker can easily provide a signature for a message they are
> spoofing, and after observing some of that domain’s traffic will know what
> selector name to use that has a published public key.
>
> DKIM is very explicit about its results: either the signature verifies or
> it does not. There is no third case.
>
> -Jim
>