Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Hector Santos <[e-mail]>]

On 5/31/2019 6:59 AM, Douglas E. Foster wrote:

> DKIM was supposed to provide sender authentication when SPF was
> invalidated by forwarding, so DMARC said that the two techniques
> should be evaluated together.

Unfortunately, DMARC did not have a policy that offered that output.

   SPF >> FAIL
   DMARC >> PASS?

Overall, DMARC failed to cover all the possible scenarios of mixed 
signatures.

To cover all aspects, the DKIM POLICY model has to offer 3rd party 
signature conditions.   In the DSAP proposal, it highlighted this as 
the broader possible options:

     https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2

     +-----------------------------------------------------------------+
     | op=         | 3p=        | Domain Policy Semantics              |
     |=================================================================|
     | empty       | empty      | No mail expected                     |
     |-----------------------------------------------------------------|
     | never       | never      | No signing expected                  |
     | never       | always     | Only 3P signing expected             |
     | never       | optional   | Only 3P signing optional             |
     |-----------------------------------------------------------------|
     | always      | never      | OP signature expected                |
     | always      | always     | Both parties expected                |
     | always      | optional   | OP expected, 3P may sign             |
     |-----------------------------------------------------------------|
     | optional    | never      | Only OP signing expected             |
     | optional    | always     | OP expected, 3P expected             |
     | optional    | optional   | Both parties may sign.               |
     +-----------------------------------------------------------------+

That covered all possible combinations.

We actually wrote an IETF functional spec regarding Sender Signing 
Policies:

    rfc5016 Requirements for a DKIM Signing Practices Protocol
    https://tools.ietf.org/html/rfc5016

    Abstract

    DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
    for domains to assert responsibility for the messages they handle.  A
    related mechanism will allow an administrator to publish various
    statements about their DKIM signing practices.  This document defines
    requirements for this mechanism, distinguishing between those that
    must be satisfied (MUST), and those that are highly desirable
    (SHOULD).


But then something happen as this document was being completed -- list 
administrators got scared that DKIM Policy was gaining tractions and 
stepping into their market toes.  After all, we had "30 years" of 
legacy list operations, we did not want DKIM Policy interfering with 
the broad range of established list distribution operations. So this 
RFC5016 "Blocker" was written at the last minute to preempt it from 
happening:

   Section 5.3, Item 10
   https://tools.ietf.org/html/rfc5016#section-5.3

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.


That was basically, a "Don't step on my turf!!" requirement. It also 
meant "Local Policy Always Prevail" regardless of what a Domain 
published which is always the case anyway. Does not need to be stated. 
  But overall, this is what help demote SSP, ADSP, ATPS and DKIM 
policy in general.  ADSP was abandoned.

But no one can kill a good idea,  the proof of concept was too 
powerful, hence it returned as DMARC but as an informational status 
document to avoid the IETF mch higher review process.

I have no idea how a high overhead, complex ARC will resolve this 
problem unless
it comes with a 3rd party signature concept with an extended DMARC 
"arc=y" tag:

   arc=y  If the 1st party signature failed, then authorize the XYZ
          domains using ARC seals to promote a failure to a pass.

How would you specify the 'authorization" of XYZ domains and do so at 
scale?

-- 
HLS