[opendmarc-users] OT: Re: Rejecting DMARC errors

[Juri Haberland]

On 2019-06-13 15:10, Lefteris Tsintjelis wrote:
> On 13/6/2019 14:53, Juri Haberland wrote:
>> On 2019-06-13 12:43, Lefteris Tsintjelis wrote:
>>> On 13/6/2019 12:51, Juri Haberland wrote:
>>>> On 2019-06-13 10:45, Lefteris Tsintjelis wrote:
>> 
>>>> A receiver without DMARC checking would accept the mail anyway, so 
>>>> why would it be a security issue if a receiver /with/ DMARC checking 
>>>> accepts it, too?
>>> 
>>> Because the DomainKey ADSP policy (dkim=all) is set for all outgoing
>>> mail to be DKIM signed and therefore an unsigned mail with DMARC
>>> policy set to reject should be rejected.
>> 
>> DMARC does not enforce DKIM policies - it does enforce DMARC policies.
>> ADSP is considered dead. From RFC 7489, appendix A.5:
>>>  DMARC has been characterized as a "super-ADSP" of sorts.
>> See also https://dmarcian.com/adsp-and-dmarc/
> 
> If DMARC was called "super-ADSP" it should have stand up to it's name
> then. I am sure you are right about the RFCs but it should have
> followed on ADSP policies. For me, being able to enforce signatures is
> a very important security policy. I don't know about the rest of the
> RFCs but in this case DMARC looks more like a "sub-ADSP" to me as it
> creates a new and big security issue here, something that the old and
> dead ADSP did not have, if it were to be used properly of course. IMHO
> it seems to me that everyone can defeat the "super-ADSP" extremely
> easily here. I am really surprised that RFCs did not cover this case.
> Even OpenDKIM had the ADSP code removed recently if I remember
> correctly. I suppose this should have been a job for OpenDKIM to deal
> with but still, there seems to be a new big security gap here between
> the "old/dead ADSP" and the new "super-ADSP".

First, you are mixing up one implementation of DMARC (namely OpenDMARC) 
with the underlying DMARC specification.
Second, in your example with missing DKIM signature, OpenDMARC logged a 
permerror which means, the sending domain got something wrong with their 
DMARC records - how is a DMARC implementation supposed to know, what the 
sending domain really wanted? Don't blame the messanger - the fault is 
at the sending side.

ADSP is dead, the ADSP RFC was moved to historic 
(https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/), 
as it was never widely adopted - you seem to be one of the few really 
using it.

In RFC 7489 in section 6.7 "Policy Enforcement Considerations" it says:

    DMARC-compliant Mail Receivers typically disregard any mail-handling
    directive discovered as part of an authentication mechanism (e.g.,
    Author Domain Signing Practices (ADSP), SPF) where a DMARC record is
    also discovered that specifies a policy other than "none".  Deviating
    from this practice introduces inconsistency among DMARC operators in
    terms of handling of the message.  However, such deviation is not
    proscribed.


Furthermore appendix A.5 has a list of problems that ADSP has:

A.5.  Issues with ADSP in Operation

    DMARC has been characterized as a "super-ADSP" of sorts.

    Contributors to DMARC have compiled a list of issues associated with
    ADSP, gained from operational experience, that have influenced the
    direction of DMARC:

    1.  ADSP has no support for subdomains, i.e., the ADSP record for
        example.com does not explicitly or implicitly apply to
        subdomain.example.com.  If wildcarding is not applied, then
        spammers can trivially bypass ADSP by sending from a subdomain
        with no ADSP record.

    2.  Nonexistent subdomains are explicitly out of scope in ADSP.
        There is nothing in ADSP that states receivers should simply
        reject mail from NXDOMAINs regardless of ADSP policy (which of
        course allows spammers to trivially bypass ADSP by sending email
        from nonexistent subdomains).

    3.  ADSP has no operational advice on when to look up the ADSP
        record.

    4.  ADSP has no support for using SPF as an auxiliary mechanism to
        DKIM.

    5.  ADSP has no support for a slow rollout, i.e., no way to configure
        a percentage of email on which the receiver should apply the
        policy.  This is important for large-volume senders.

    6.  ADSP has no explicit support for an intermediate phase where the
        receiver quarantines (e.g., sends to the recipient's "spam"
        folder) rather than rejects the email.

    7.  The binding between the "From" header domain and DKIM is too
        tight for ADSP; they must match exactly.


That said, I'm not involved in creating any of those standards and if 
you would like to discuss this topic further, you might better do it on 
the dmarc-discuss mailing list (dmarc-discuss at dmarc.org) or on the IETF 
dmarc mailing list (dmarc at ietf.org).


Cheers,
   Juri