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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Sep 2019 08:57:59 -0700

On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker <[email-masked]> wrote:

> Review of:    DMARC (Domain-based Message Authentication, Reporting, and
>                Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:          draft-ietf-dmarc-psd-06
> Reviewer:     D. Crocker
> Review Date:  12 August 2019
>

Dave,

Thanks for your feedback about draft-ietf-dmarc-psd on August 13.  Though
Working Group Last Call closed on July 17th, the chairs have taken careful
consideration of your feedback before allowing the document to proceed.

We take these as the main points of your comments (and please correct us if
we have missed any):

   1.

   The current design of DMARC observes a clear division of functions
   between itself and the PSL.  Specifically, as you point out, DMARC relies
   on a PSL existing and being available as input, but provides no guidance
   regarding selection of a PSL source nor of its content management policy.
   Also, the only operation available on the list is a test of membership
   (i.e., “is this domain on the list?”). Both of these tenets contribute to
   simplicity in DMARC’s current design.
   2.

   The PSD proposal attempts to resolve use cases that have appeared since
   the publication of RFC7489 by prescribing the conditions under which an
   additional check for a policy record at a new (related) location should be
   done.  This violates the tenets of (1) above.
   3.

   This additional lookup, in those cases where it is done, increases
   substantially the complexity of DMARC implementations, and that complexity
   comes with non-trivial cost.
   4.

   The use case(s) sustained by this change are not clearly substantial or
   beneficial enough to warrant enshrining this as a change to DMARC, even
   with only Experimental status.  There has also been very little indication
   of interest for implementation of the experiment.

On review (and our apologies for the duration of that review), we believe
the current draft does attempt to address your concerns, but does not make
this clear in its current form.  Given our responses to your points below,
and if you agree, perhaps you can help us to compose alternative text that
improves that situation.

For the first two points, we concur.  On the issue of the second violating
the tenets of the first, we suggest that the outcome of the experiment can
be used to drive an evolution of the PSL into a new form and perhaps new
update policies.  That is, rather than driving a change to DMARC itself,
the experiment’s results (if successful) can drive a change to the PSL, or
perhaps inform development of an alternative to it.

>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.

The working group originally discussed other alternative ways to augment or
even replace the PSL, such as creating a queryable IANA registry controlled
under our own terms.  The WG did not achieve consensus on such a proposal.
Should this experiment bear fruit, that discussion could (and should) be
revisited. Also, to be clear, any effort to augment the format, content, or
management of the PSL would require collaboration with the Mozilla
Foundation, as they are its de facto maintainers; absent such
collaboration, or if our proposal is not accepted, we must revisit the
notion of creating our own version of it and coming up with workable query
and update mechanisms and policies.

On the third point, we respectfully disagree.  An informal canvassing of
some members of the DNS community has been done and the consensus opinion
suggests that the additional operational overhead proposed here is
negligible.  This is, indeed, a far cry from the resistance with which the
original DKIM policy work was met, wherein even a one-level tree walk
upward drew heavy criticism. Code-wise, DNS queries are well understood
processes by now, and adding one more to the implementations of those
packages with active representation in the working group has not been seen
as costly enough to be a concern.  And it seems logical that conducting
this experiment will indeed help to confirm whether the additional query is
an apparent burden on either implementers or operators.

On the final point, we suggest that the WG considers this an intentional
part of the experiment’s design.  The set of use cases to which the
experiment applies is deliberately constrained, which of course will limit
the apparent effectiveness of the technique being proposed.  However, if it
is effective for the small number of domains that are part of the
experiment, and with a relatively limited set of implementers, this
constitutes evidence that a wider trial involving more prominent PSL
entries and larger operators would be warranted as part of the development
of DMARCbis.

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.

If none of the above are enough to assuage your concerns, we would
appreciate any suggestions you might have about an alternative experiment
that might be run to address the use cases both you and the draft have
described.

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?

-MSK, co-chair

[1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI

---

From: Dave Crocker <[email-masked]>
Date: Wed, 4 Sep 2019 06:28:41 -0700

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:
> queryable registry described in Appendix B), which DMARC then can 
> consume to resolve the use cases that have appeared which now need to be 
> 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.

> 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.

> 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.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 4 Sep 2019 16:53:26 -0400

Dave

I've had discussions with folks within the W3C on the PSL and the
possibility of extending it,
and there is always interest in considering requests from the IETF, but
they are the final
decision makers.

The whole idea of running an experiment would be to produce data that can
be shared and
can help the W3C modify the PSL.  Suggesting changes without understanding
their effects sounds would concern me.

Tim
(hats/no hats/I apologize for not knowing)

On Wed, Sep 4, 2019 at 9:29 AM Dave Crocker <[email-masked]> wrote:

> > [1]
> https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 Sep 2019 22:24:44 -0400

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:
>>  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.
>
> 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.
>
>> 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]
> 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.
>
> 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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Sep 2019 01:15:35 -0400

> PSL enhancement, independent of DMARC.

I think some related, but distinct issues are conflated in your analysis.

The core PSD check doesn't need a PSL change.  The current PSL works fine.  The 
sequence is:

1.  Check at the From domain level.
2.  If no record, check at the org level.
3.  [New] if no record check one level above the org level (PSD).

That's all doable with the current PSL.  I don't think we want to force 
additional lookups between 1 and 2 for lower level domains.  Currently for 
something like:

a.b.c.d.org.example where only example is in the PSL the queries would be:

1.   a.b.c.d.org.example
2 .  org.example
3.  example

As I read your proposal we've have to add in queries for:

b.c.d.org.example
c.d.org.example
d.org.example

I don't think querying anywhere in the DNS treee is an improvement for 
scalability of DMARC.

Adding the single additional PSD lookup works fine with the existing PSL.  
There are two reasons to go beyond this:

1.  Since most PSDs won't publish DMARC records, as an efficiency, let's not do 
that third lookup unless we have to.

2.  PSD DMARC without some constraints on the additional lookup automatically 
opts in all organizational domains that do not publish DMARC records, which 
has privacy implications.  This is discussed in Section 4.1 of the draft.

As it says at the start of Appendix B, the options proposed there are to 
mitigate the privacy risks described in Section 4.1.  The related requirements 
discussion is in Appendix A, Section A.1.

It is a beneficial side effect that they also reduce the need for DNS lookups 
and thus provide an efficiency enhancement.

If we didn't care about privacy, this would be easy.  That's the hard part 
that does not have a clear solution.  One thing that is clear is that it's not 
the PSL.  PSL is a collector of assertions from operators, so it fails to meet 
the attributes laid out in A.1.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Sep 2019 10:28:05 +0200

On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote:
> 2.   org.example

Besides scalability, the question is whether b, c, or d have the right to
override the DMARC policy of org.example.  The current spec clearly says no.

My reading of Dave's proposal differs.  Modifying the PSL has the implicit
objective to skip step 2.  That is, to limit queries to:

1.   a.b.c.d.org.example
3.   example

Thereby slashing org.example's privilege to establish its own domain policy.

> has privacy implications.  This is discussed in Section 4.1 of the draft.

We should also consider updates:

How often is/should be the PSL updated at average mail servers?

How often would then the extra list at psddmarc.org have to be updated?

> the attributes laid out in A.1.

Failure reports are considerably less implemented than aggregate ones.  The
current spec doesn't mention any privacy risk in its Security Considerations
section.  However, some concern must exist, otherwise the difference in
implementations cannot be easily explained.  The I-D at hand touches on this
point marginally.  A general consideration would better fit in DMARCbis.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Sep 2019 13:35:29 +0000

On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely <[email-masked]> wrote:
>PSL,
>the

That's because there's an entire separate section on privacy considerations.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Sep 2019 13:22:27 -0700

On 9/4/2019 6:28 AM, Dave Crocker wrote:
> ence my current view that:
> 

Trying to refine things further:

    DMARC does not care about the PSL.

    What DMARC cares about is the Organizational Domain (OD), as a 
fallback when no DMARC record is found at the desired domain name.

    That is, PSL is literally outside the scope of DMARC.

    At the least, therefore, the DMARC specification should define a 
distinct interface to the outside functionality that tells DMARC where 
the OD is, which will return what suffix of the full domain name is the 
OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix

    The PSL-related side of that interface should be a separate 
specification, so that changes to its behavior -- such as has been 
happening with the introduction of ODs that are TLDs or are otherwise 
'above' where DMARC has been guessing the OD to be -- are isolated from 
DMARC.

    The current problems are that DMARC has embedded too much detail 
about the PSL world, yet DMARC has no involvement in that world. The 
current proposal embeds assumptions of PSL knowledge further, rather 
than separating PSL knowledge out.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Sep 2019 21:49:09 +0000

>than separating PSL knowledge out.

I don't think so.  The draft defines PSD as org - 1.  However you figure out org (currently PSL, but whatever).  If there's some place in the draft that doesn't say that, it's a mistake to fix.

I'm currently writing on my phone, so draft review isn't easy.  I'll look at it again later today and report back on details.  If you have specific suggestions on making this clearer, please let me know.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Sep 2019 18:02:45 -0700

On 9/5/2019 2:49 PM, Scott Kitterman wrote:
> I don't think so.  The draft defines PSD as org - 1.

Writing a definition for something you don't control and that can (and 
has) change tends to be problematic.

As it is here.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Sep 2019 21:28:16 -0400

> has) change tends to be problematic.

Now that I'm at a computer where I can review the draft as it stands (as 
opposed to the draft as I remember it), I agree the current definition is 
problematic.  However, I think it's easily fixable.  Here's where I see a 
problem:

> 2.3.  Longest PSD
> 
>    The longest PSD is the PSD matching more labels in the domain name
>    under evaluation than any other public suffix list entry.

As you suggest, it leverages PSL in a way that's sub-optimal at best.  
Fortunately I think we can fix it.  I'd suggest this instead:

2.3.  Longest PSD

   The longest PSD is the Organizational Domain with one label removed.

With that change, PSD DMARC makes no claims based on use of the PSL that 
aren't inherited from DMARC.

How's that?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 8 Sep 2019 13:22:30 +0200

On Thu 05/Sep/2019 15:35:29 +0200 Scott Kitterman wrote:
>>> If we didn't care about privacy, this would be easy.  That's the hard
>>> part that does not have a clear solution.  One thing that is clear is
>>> that it's not the PSL.  PSL is a collector of assertions from operators,
>>> so it fails to meet the attributes laid out in A.1.>>
>> Failure reports are considerably less implemented than aggregate ones. 
>> The current spec doesn't mention any privacy risk in its Security 
>> Considerations section.  However, some concern must exist, otherwise the
>> difference in implementations cannot be easily explained.  The I-D at hand
>> touches on this point marginally.  A general consideration would better
>> fit in DMARCbis.>

My bad English.  By "current spec" I meant rfc7489.

Best
Ale
--

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Mon, 9 Sep 2019 18:29:40 +0000

>> Within DMARC this would not look like 'extra' mechanism.

An additional DMARC query at one level above the organizational domain should be an additional query, rather than more simply being able to have the organizational domain higher up the DNS tree and not having an extra DMARC query.  This is particularly the case for reporting so that even if the organizational domain and the PSD domain one level above the organizational domain have the same DMARC requested handling policy, they can have different DMARC reporting addresses.

For DoD and the .mil TLD, we support this PSD DMARC effort and believe that it would be beneficial to have an additional DMARC query at the PSD level.

Thanks,
-Eric

Eric Chudow
DoD Cybersecurity Mitigations
[email-masked]