Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Hector Santos <[e-mail]>]

On 5/23/2019 4:35 PM, Jim Fenton wrote:
> In response to Seth Blank's call for issues of 9 May 2019:
>
> DMARC contains what are really two distinct mechanisms, a reporting
> mechanism and a policy mechanism. The policy mechanism is largely a
> request to the verifier about what to do in the event that a message is
> received that does not comply with policy.
>
> There are domains that would like to receive reports, but whose usage of
> mail doesn't make it useful to express a policy. Conversely, there are
> domains that want to express a policy but aren't interested in reports.
> I'd like to advocate that DMARC be split up into two different documents
> dealing with reporting and policy separately. If it's useful to have a
> separate document that defines what it means to be "DMARC-compliant"
> that is referenced by both, that would be OK.
>
> There was a similar situation with MTA-STS which had both a policy and a
> reporting mechanism, and that was broken into two standards-track RFCs:
> RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport
> Security). I consider this to be a relevant precedent.

Hi Jim.

+1.  I agree with the split, if it helps with the focusing of 
completing a Proposed Standard (PS) DKIM-POLICY  framework that 
includes codification for the Author Domain Lookup method, 
clarification for alignment and most important, finally recognizing 
extended 3rd party authorization policies and protocol add-on 
capabilities.

I always felt reporting offered little payoff, added lots of overhead 
to the process, in particular more complex coding requirements, i.e. 
you really don't need JSON, XML, etc layers to do a simple DNS DKIM 
policy check, and there was a high potential for abuse.  In my 2006 
DSAP (DKIM Signature Authorization Protocol) proposal, a reporting 
option was offered but it was made clear it can be abused, so it 
should be limited. 
(https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16)

As you recall, the the past DKIM WG did the same with DKIM when it was 
decided to split the proposed standard's inherent POLICY model (SSP) 
component into two Proposed Standard DKIM Working Group work item 
documents;  DKIM-BASE and DKIM-POLICY. SSP was replaced with ADSP with 
reduced policies, ironically, the 3rd party policies were removed -- 
deemed too complex.  It focused on the principle 1st party domain 
policy, neglecting the 3rd party domain signature and how they should 
be evaluated.

Nonetheless, the split was a success in allowing us to finished 
DKIM-BASE.

But the negatives in the split, as some (including myself) with split 
concerns had predicted might happen, a lost of interest in finishing 
the Proposed Standard DKIM Policy work, coupled with a mis-directed 
attention (wishy future) with reputation methods, eventually, DKIM 
Policy would be abandoned.  I think we lost the interest of many 
policy advocates during this time, in particular when there was a 
resistance towards recognizing the "ADID"  (Author Domain IDentity) 
and not including it as part of the into the DKIM-base "Assessment" 
model.

So can the same happen if DMARC reporting was split from a PS 
DMARC-bis work?

IMO, yes, it could happen. I personally do not have any interest in 
reporting in its current form. I have all received reports gated into 
a NNTP newsgroup for private viewing. I don't see any consistency and 
value from them. So that item that can be done -- more consistency. 
It can discuss XML/JSON viewers, ad-hoc reporting methods to help with 
with labeling patterns.  I believe ARC will also need be part of the 
reporting as well. This can be very complex but also highly subjective 
design ideas. They can be discussed separately and independent of a 
straight forward DKIM author domain policy framework.

Finally, the key issue remains, to this day, over 12-15 years,  the 
dearth of 3rd party authorization concepts.

That is where the fuzziness remains.  To me, this is what DMARC-bis 
has to help finish.  The "Authorized Third Party Signature" (ATPS) 
model need to be recognized and put into the DKIM-POLICY framework, 
allowing it to get endorsed and explored at small to high deployment 
scenarios.  We have allowed the brush back by the "Big Guy" (who can't 
seem to figure it out) deter the possible benefits for all other 
smaller scales.  That is what happen before just to do 1st party and 
ADSP paid the price only to be replaced later with Super ADSP - DMARC. 
  So they were wrong with ADSP, they are probably wrong with ATPS as 
well.  As a smaller organization with a well defined set of domains, 
well-defined network usage of where my domains are used.  Some are 
exclusive, very private, some are used in mailing list, like here. I 
know who is allowed to sign mail on my behalf.  That is all defined in 
published DKIM+ADSP/DMARC+ATPS DNS records.

-- 
HLS