Re: [dmarc-ietf] Announcing DMARCbis Editors

[Hector Santos <[e-mail]>]

On 11/9/2020 6:04 PM, Jim Fenton wrote:

> On 7 Nov 2020, at 20:12, Steven M Jones wrote:
>
>> Okay, but what is the expected payoff from splitting it out? Does it
>> make it easier to process and approve updates of the policy content
>> separately from, say, the description of record discovery or
>> Alignment concepts? Easier to pass muster for Standards Track? Are
>> implementers currently confused and dissuaded by having policy
>> details mixed with the other content?
>>
>> If the benefits seem worthwhile, I could get behind the split - but
>> there ought to be a clear benefit.
>
> The benefit I have in mind is that reporting does not cause issues
> with indirect mail flows (the addressing of which is item 1 on the WG
> charter), so it can proceed even while there isn’t WG consensus on how
> to solve that problem for the policy piece. Or in the extreme case, it
> can proceed even if IESG considers the policy piece to not have an
> acceptable solution.
>
> Of course, if the solution to the policy piece is likely to affect the
> discovery/binding of the policy and reporting, which would be in the
> base document, this argument doesn’t hold.

My view.

I was the 2nd on Jim's proposal to split DMARC.  I presumed the obvious:

- DMARC-BASE
- DMARC-REPORTS  (optional reporting features. Not required)

DMARC-BASE is the base policy protocol based on the DKIM-POLICY model 
as was DKIM-SSP and DKIM-ADSP.  All these proposals used the required 
DKIM 5322.From domain identity binding as input for a DKIM Policy 
model.The DKIM Signer Domain identity is input for an Reputation 
lookup that never materialized. DKIM-VBR is the closes thing we have 
to a IETF proposed reputation lookup for DKIM.  DKIM-VBR does the 
Author and Signer as input.

I favored the split for the same reasons DKIM was split into two WG PS 
work items:

- DKIM-BASE   was the base signing/verification protocol,
- DKIM-POLICY where DKIM-SSP was the draft proposal on the table.

The split allowed DKIM-BASE to be completed and now we have a DKIM STD 
document.

Fenton was the editor of DKIM-SSP. It evolved to DKIM-ADSP which was 
abandoned and the DKIM WG ended.  It was replaced with DKIM-DMARC as 
an Informational Status document.

Keep in mind that DKIM-SSP covered 3rd party policies with an "o=" tag:

SSP Draft:

    o=~  NEUTRAL (signature optional [No 3rd party?])
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

WG Suggestions:

    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)


Due to the ambiguity of the 3rd party policies and the lack of a 3rd 
party authorization protocol, Levine rewrote DKIM-SSP draft 3 titled 
DKIM-ASP and by draft 10, it became DKIM-ADSP.

ADSP stripped the 3rd party semantics and pretty much left an 
EXCLUSIVE policy with ADSP DISCARDABLE policy.

DMARC also offered a similar exclusive signing policy and also 
reported as well.

Fast forward to today.  I believe the charter is touching based with 
the 3rd party resigners design issues. So we are back to a situation 
where we may have three documents:

- DMARC-BASE      base protocol for current strong 1st party policy,
- DMARC-REPORTS   optional reporting
- DMARC-TPA       Third party Authorization proposals.

The DMARC-TPA should cover ATPS, ARC and hopefully conditional 
signatures. However, based on the charter, it outlined specifically:

* Incorporate ARC or something that deals with indirect mailflows

This work item was lumped into DMARC-BASE.

My position is this:

I believe ARC or "something that deals with indirect mailflows" that 
is not well defined or has not gained traction as a TPA solution, 
should not be included in DMARC-BASE.

DMARC-BASE should be independent of any other add-on but it should 
allowed for Tag Extensions to support TPA concepts included ARC, ATPS 
and conditional signatures.

In my opinion, this is a best way to get DMARC-BASE fast tracked to 
standardization. DMARC-TPA or DKIM-TPA can be a separate doc that 
specifies add-on DMARC augmentations which are designed to help 
address the long time 3rd party resigned and authorization issue.

While I personally, and I believe ideally, prefer ATPS be included in 
the DMARC-BASE protocol, due to the lack of WG support, I rather get 
the DKIM-BASE 1st party semantics completed first.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos