Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Hector Santos <[e-mail]>]

We need to use the QUERY for the DMARC record to get compliant clients 
to try (explore) different things. Let the record tell the client what 
to do. We need an expanded language for the possible tags.   SPF was 
very flexible.  DMARC is not because it removed 3rd party 
capabilities. It is too limited.  In the end, this is still about 3rd 
party AA (authentication/authorization) and in this case what is being 
labeled PSD domains.  Just define/refine the BASE lookup mechanism, 
and the possible extensions.

ATPS offers an extended protocol mechanism for 3rd party domain 
authorization.  This is basically what is wanted for PSD.



On 9/4/2019 9:28 AM, Dave Crocker wrote:
> Murray,
>
> Thanks for the diligent reply.
>
> (As a matter of etiquette, I will again apologize for not having
> submitted my concerns earlier.  Partially, this was because my
> assessment of the work did not gel until recently.)
>
>
> Some responses:
>
> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
>>  From a higher level view, the experiment can be seen as the
>> temporary construction of an augmented PSL (i.e., the actual PSL
>> coupled with the queryable registry described in Appendix B), which
>> DMARC then can consume to resolve the use cases that have appeared
>> which now need to be addressed.  The portion of the experiment
>> comprising an augmentation to DMARC’s algorithm would therefore not
>> be part of DMARC permanently. Then, if the experiment proves
>> effective, that would become prima facie evidence that the PSL,
>> augmented with this additional information, would enable DMARC to
>> resolve those use cases.  Such an augmented PSL would still conform
>> to the desirable separation of functions to which you alluded.
>
> This model of iterative design does not match my own sense of IETF
> work, experimental or otherwise.
>
> Simply put, 'temporary' is an appealing but highly misleading
> construct, in the form and scale of a standards body.[*]  The closest
> reality comes to matching that term is when the 'experiment' fails
> utterly and the effort must completely restart. When work like this
> operates over a period of years and at Internet scale, nothing is
> temporary.
>
> If an experiment succeeds, the specified work will have become
> entrenched and there will be significant resistance to making major
> changes.
>
> With respect to the use of this work as a model for changes to the
> PSL, unfortunately the spec is not written in a fashion to support
> that. This really is a core concern, in my view: the work needs to
> have a basic model that really is expected to be appropriate for the
> long term; hence my suggestion to highly limit any changes to DMARC
> and, instead, cast the bulk of the work as augmenting the PSL.
>
> That said, and as for getting changes to the PSL, based on my
> interactions with that community, I think it unlikely.  There does not
> seem to be the interest or resources for such work.  Strategically,
> that's the biggest hurdle to overcome, IMO.
>
>
>
>> In addition, there are a few very large players in the space who are
>> unfortunately reticent to declare publicly that they are interested
>> in seeing this evolutionary experiment proceed.  These include large
>> email providers and operators of sizable TLDs in need of the
>> capabilities pursued here. This provides some weight to the idea
>> that this will not be simply a niche experiment.
>
> Good to hear.
>
>
>> Lastly, we note that the idea of “walk up one node” came from an
>> email thread in December[1] wherein you suggested that approach, and
>> which the PSD draft now follows.  We are thus a little surprised by
>> the assertion that it should not proceed at all. Was there some
>> content of that thread that was not taken into account that would
>> make it palatable?
> ..
>> [1]
>> https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI
>
> Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an
> idea simmer for a while, to think about it more.  My feeling is that
> the idea does not adequately attend to the items 1 and 2 I listed in
> that note.
>
> Hence my current view that:
>
> 1. The change to DMARC should be limited to permitting the query for
> the organization domain to be anywhere in the DNS tree, including a
> TLD. Within DMARC this would not look like 'extra' mechanism.
>
> 2. The mechanism that processes that query should be cast strictly as
> a PSL enhancement, independent of DMARC.
>
>
> d/
>
> [*] Note the 'obsolete' construct in RFC 5322.  It was introduced in
> RFC 2822, as a revision to RFC 822, 20 years ago.  As is obvious, it's
> intent was to eliminate use of the portions of RFC 822 deemed
> obsolete. Yet these portions still haven't been eliminated from the
> specification.  Twenty years later.
>

-- 
HLS