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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
