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

[Scott Kitterman <[e-mail]>]

On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:
> (I am trying to formulate a response on the higher-level technical and
> process issues under consideration, but decided to respond now on these
> particulars, since they are more focused...)
> 
> On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
> > Dave,
> > 
> > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <[e-mail]
> > 
> > <mailto:[e-mail]>> wrote:
> >>     Nothing I've worked on at the IETF with such a label is something
> >>     I would necessarily stand behind as Internet-scalable.
> >     
> >     Such as?
> > 
> > RFC 6541 comes to mind.  To the best of my knowledge, it's an
> > experiment that never even ran.
> 
> I don't recall that scaling limitation was an embedded and acknowledged
> fact about that spec. And with a quick scan I don't see anything about
> that in the document.
> 
> There is a difference between having some folk be critical of an
> experiment, versus have its non-scalability be an admitted limit to its
> future.  That is, you or I or whoever might know a spec sucks and can't
> succeed, but that's different from having the formal process declare
> that an experiment is /intended/ not to scale, which seems to be the
> case here.

This claim seems to me to be unrelated to anything in the draft.  Would you 
please point to where you found this?

> > Implementations shipped, but its use on the open Internet was never
> > detected or reported.  And I had my doubts about the scalability of
> > the second DNS check that was added to it, but it didn't seem like it
> > could go forward without.
> > 
> > One that wasn't mine: RFC 6210, an experiment to prove how bad
> > something can be.
> 
> There is a reasonable argument to be made that little about /any/
> security spec actually scales well, but that's such a cheap shot, I
> wouldn't dream of taking it.
> 
> However, yeah, "to find out how bad including hash parameters will be"
> does seem to provide an existence proof for using IETF Experimental to
> bench-test something rather than as a gateway to standard for that
> something.  sigh.
> 
> >>     But I would probably expect something at Informational probably
> >>     to scale, and anything with "Standard" in it certainly to scale.
> >     
> >     Laying any general expectation on an IETF Informational RFC would
> >     be a mistake, because there is so much variety in their content
> >     and intent.
> > 
> > Why would the expectations for Experimental be higher than for
> > Informational?  LMTP is Informational, and it certainly needs to succeed.
> 
> As a rule -- or certainly a solid pattern -- Experimental means that the
> document wants to be standards track or BCP but needs some vetting
> before being permitted that honor.  Informational docs don't have an
> expectation of making it to standards track.

Would you withdraw your objections if we made this informational?

> >>     So: Can you propose any sort of specific restructuring of the
> >>     document or the experiment that achieves the same goal as the
> >>     current version while also resolving your concerns?
> >     
> >     I'm pretty sure I've raised fundamental concerns about this work
> >     and that those concerns have not been addressed.  The simple
> >     summary is that the way to restructure this work is to go back to
> >     first principles.  But there doesn't seem to be any interest in
> >     having that sort of discussion.
> > 
> > I thought we were having that sort of a discussion right here.
> > 
> > Your position as I recall is that we have no choice but to take all of
> > this back to first principles and separate DMARC from the
> > determination of Organizational Domain (i.e., make them separate
> > documents) before PSD can proceed.
> 
> Unfortunately, that's accurate. At the least, I'd expect to see
> thoughtful responses and some breadth of support for those responses,
> countering the fundamental concerns I expressed. I don't recall seeing
> responses with such substance.
> 
> (One of the challenges for me, in trying to formulate the 'thoughtful'
> response I'm considering is to provide/repeat a concise summary of those
> fundamental concerns.  As I recall they were both architectural and
> operational.)

Help me understand.

Currently the proposal is:

PSD DMARC defines PSD relative to org domain and points to DMARC for how one 
finds org domain (no PSL reference in the PSD DMARC draft - there have been at 
times, but there aren't now).

You find this unacceptable, as I understand it.  What you think we should do is 
first split the DMARC spec into two so that:

PSD DMARC defines PSD relative to org domain and points to DMARCbis for how one 
finds org domain and DMARCbis points to a new spec that explains how to use the 
PSL to find the org domain (or some other method if it's agreed).

You find this acceptable, as I understand it.

Assuming that's correct, please help me understand what PSD DMARC is affected 
at all.  All it does is consume the org domain however DMARC/DMARCbis choose 
to define it.  I don't see as it makes a difference from a PSD DMARC 
perspective.

I get that you want to fix the architectural warts in DMARC and I don't 
disagree with you about working on that.  Where I get lost is how PSD DMARC 
has anything to do with it.  PSD DMARC could be done first, in parallel, or 
after the DMARC architectural work.  It would have no impact on that work.

I would like to understand your position, but I don't, so please help me out 
here.

Scott K