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

[Barry Leiba <[e-mail]>]

>> 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.
>
> When we use P=REJECT, we assert that anything which cannot be
> confirmed is unacceptable.   That makes for two pretty disjoint
> groups.   If Authentication is only to be used to validate a
> whitelisting decision, then a one-sided test would be sufficient.   In
> practice, the primary use for DMARCv1 is to block messages, and much
> of our discussion has been around the unwanted disposition that this
> places on mailing lists.

Indeed; there is definitely a problem between DMARC's p=reject and
mailing lists.

> DKIM treats an invalid signature as non-existent.   It also treats a
> DKIM signature as fully optional.   DMARCv1 changes the rules to
> gather more usable information from the message.    DMARCv1 with
> P=REJECT says that a message which lacks authentication is
> unacceptable, and since any message might be forwarded, it has
> effectively made DKIM non-optional..  So we have already modified the
> interpretation of DKIM.

Here, again, I disagree with your premise: we have not modified the
interpretation of DKIM.  Senders still decide whether to sign with
DKIM or not, and you're correct that it's a poor quality deployment to
use p=reject (or even quarantine) without also deploying DKIM signing.
But the interpretation has not changed: a valid DKIM signature still
means the same as it always did, and the absence of a valid DKIM
signature still means the same as well.  We have not created -- and
must not create -- an additional state that has been proscribed for a
number of good reasons.

> I have observed that IF the domain owner indicates that all messages
> originate with DKIM signatures, then the presence of a signature is no
> longer optional at the evaluation point.    As I have said previously,
> this provides a valid basis for partitioning messages between
> verified, ambiguous, and repudiated.   If you accept the premise that
> mailing list messages should not always be repudiated, then nothing we
> have done up to this point has provided a reliable way to repudiate.
> I am saying that this is a problem that we can fix.

It does not provide such a valid basis.  With your proposal, any
attacker can move her message from "repudiated" to "ambiguous" simply
by attaching a fake DKIM signature that she knows will never validate.
That alone is a reason this plan won't work.

> Yes, I have gone radical, and I am no longer willing to be limited by
> the design limitations of DMARCv1.

I think that's a fine approach, but it has to come with proposals that
do not violate the other protocols that we're relying on.

Barry