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

[Barry Leiba <[e-mail]>]

Doug, I think the issue here is that I disagree with your premise, so
the rest of the argument fails for me:

> 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:

I don't agree with the characterization of the second group.  I would
say that we are partitioning messages into these two groups:
- Those for which we can confirm that they originated in the domain
they say they did.
- Those for which we can not confirm that.

Note that the second of those is subtly different to your
characterization, in that there's a difference between knowing that
they did not originate in the domain... and not knowing whether they
did or didn't.  It has never been a claim of either DKIM or SPF that
we can know anything in particular about a message when validation
fails: all either of them tells us is that validation has failed.

As Jim says, DKIM is very clear about that, when it tells us to treat
a validation failure the same as an absent signature.  Any proposal
that tries to treat a signature that fails to validate in any special
way is a non-starter, as it violates DKIM.

Barry

On Sat, Jul 17, 2021 at 8:38 AM Douglas Foster
<[e-mail]> wrote:
>
>
> 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
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc