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

[Hector Santos <[e-mail]>]

Yes, RFC 7960 summarized/gathered what was already well known.  We 
also have a List Server product, for practically "30 years," too and I 
am very aware of how mail flows works.   One problem is the fallacy 
that we didn't want to change software.  Well, I was ready to do so, 
and did, and only until others were force to do so, other list servers 
began to do the 5322.From rewriting thing.  Not my preference to be 
tampering with the author address, I do recognize it helped address 
the issue.   The better rand more logical alternative (imo) is for the 
list to:

     - Deny Restrictive Domains in the name of security, both for
       subscriptions and submissions into a list.

Finally, in my opinion,  extended policy designs need to be revisited 
as an simplified alternative to the experimental status, a high 
overhead, expensive ARC design which really doesn't promise anything, 
yet, other than record what kind of failures happened.  I can't find 
convincing ARC design logic that suggest this will help address the 
unauthorized 3rd party resigner problem unless as I suggested, it 
comes with an extended DMARC tag that gives receivers the "authority" 
to check the "ARCness" of a failed DKIM message.  Even though, I would 
only like to do so with authorized domains I trust.


On 5/31/2019 11:16 AM, Elizabeth Zwicky wrote:
>
> RFC 7960 has an extensive discussion of mail flows that modify mail (as well as other cases that are problematic for DMARC). Mailing lists are not the only case, and, as John has pointed out, reformatting and part stripping are things that happen in mail flows.
>
> Elizabeth
>
>> On May 31, 2019, at 8:02 AM, Hector Santos <hsantos=[e-mail]> wrote:
>>
>>> 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
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 
HLS