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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Nov 2019 23:34:39 -0800

On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <[email-masked]> wrote:

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

We (the chairs) fully agree with all of this.  What we -- I in particular
-- have been struggling with is to find a path forward so the PSD
experiment can still take place without being blocked by the need to first
go back and overhaul RFC 7489 as you've described here, separating DMARC
and the OD determination.  Because that'll take months.

We are perhaps in the fortuitous position in our charter now that our very
next work item is to take up the task of reopening DMARC itself, and the
separation of function Dave is espousing could be made into a reality
during that work.  Given this, we suggest that the PSD draft be allowed to
proceed as Experimental, but with appropriate preamble text added to its
Introduction explaining the deficiency Dave has identified.  So the order
of operations becomes:

* add text to the PSD draft making it clear that what it's describing is an
experiment whose outcome will be taken only as feedback to the revision of
the standard (i.e., this is not intended to be the final form of anything),
and it is not intended to be deployed outside of the experiment's
participants;
* publish the experiment with those cautions and allow the experiment to
begin
* while the experiment is running, spin up the work on two new standards
track documents, in line with our charter:
  a) DMARC, with PSL references replaced by the abstract notion of the OD
that's determined in some non-specific way, as Dave suggests
  b) a PSL document that satisfies the abstract notion of OD in the DMARC
document, also as Dave suggests
* when the experiment completes, either augment (b) if it's still in
development, or publish a revision to it, based on what the experiment has
revealed

Can this be made to work?

Honestly, the experiment could start anyway without an RFC published, but a
formal record of the experiment and its caveats doesn't strike me as a
wrong thing to do.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Nov 2019 08:29:02 +0000

>formal record of the experiment and its caveats doesn't strike me as a

The current revision of the PSD DMARC draft makes no reference to the PSL in the body of the draft (it only comes up in Appendix A and C).    It seems like an odd choice to continue to insist PSD DMARC is specifically tied to the PSL when the text indicating so has been removed (Dave's email was two months ago and things have changed in the interim).

I don't think the proposed note says anything the status of experimental shouldn't already communicate.  Given the current state of the draft, I don't think it's necessary to have such a note.

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 11 Nov 2019 04:58:00 -0500

Scott

PSD DMARC does talk about organizational domains which from the original
DMARC spec (section 3.2)
does say 'Acquire a "public suffix" list'

The addition of the preamble text shouldn't move the document in either
direction.
I do feel anything which helps focus us on moving forward on DMARC-bis is a
good thing.
The WG should be able to start writing the PSL document right away.

Murray and I will be in Singapore if anyone wishes to speak their mind.

thanks
Tim

On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman <[email-masked]>
wrote:

> The current revision of the PSD DMARC draft makes no reference to the PSL
> in the body of the draft (it only comes up in Appendix A and C).    It
> seems like an odd choice to continue to insist PSD DMARC is specifically
> tied to the PSL when the text indicating so has been removed (Dave's email
> was two months ago and things have changed in the interim).
>
> I don't think the proposed note says anything the status of experimental
> shouldn't already communicate.  Given the current state of the draft, I
> don't think it's necessary to have such a note.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:38:50 -0800

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski <[email-masked]> wrote:

> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:46:17 -0800

> The WG should be able to start writing the PSL document right away.

Tim,

I think that you are being too liberal in applying transitive references.
The PSD document only refers to the PSL in

   - Informative References
   - Appendix A.1
   - Appendix B.3
   - Appendix C.2 (implementations)

I don't think that it is fair to say that anyone who refers to the org
domain concept as cited in the DMARC spec is necessarily invoking the PSL.

I do have a problem with the conflation of the org domain with a
super-organizational "realm" (?) that may impose conditions upon
organizations that fall within their jurisdictional purview. My main
concerns are with the potential usurpation of the org domain's policy
declaration rights. "Moving" the org domain up one level disenfranchises
the organizations and that is the wrong thing to do IMO.

As to the proposed "let's run this as an experiment pending DMARCbis", I
don't see how that satisfies Dave's concern about creating new work for
receivers in order to help a small set of domain (realm) owners. I'm not
opposed to it, but I just don't see how this solves the issue.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Nov 2019 18:50:30 +0100

On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> 
> I don't think that it is fair to say that anyone who refers to the org domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.

Agreed.  The PSL just happens to be the only valid tool to do that.

For various reasons, large organizations administer many apparently unrelated
domains.  For example, _dmarc.youtube.com has a rua mailto ending in
@google.com.  We cannot infer an OD from that, but I think the concept is clear.

> super-organizational "realm" (?) that may impose conditions upon organizations
> that fall within their jurisdictional purview. My main concerns are with the
> potential usurpation of the org domain's policy declaration rights. "Moving"
> the org domain up one level disenfranchises the organizations and that is the
> wrong thing to do IMO.

The I-D definitions are clear enough.  Section 2.5, in particular, prevents the
conflation neatly.

> As to the proposed "let's run this as an experiment pending DMARCbis", I don't
> see how that satisfies Dave's concern about creating new work for receivers in
> order to help a small set of domain (realm) owners. I'm not opposed to it, but
> I just don't see how this solves the issue.

Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record.  The
latter is a Nominet, already solved problem, AFAICS.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 11 Nov 2019 10:31:52 -0800

On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely <[email-masked]> wrote:

> domain

Which was not what I thought Tim W was talking about...

> @google.com.  We cannot infer an OD from that, but I think the concept is

I don't think this has anything to do with the PSD proposal either. Why do
you bring it up?

> don't

If it was a solved problem, then we would not need a PSD (or realm) I-D and
this whole discussion would be moot. What ICANN does and does not allow is
out of scope for the IETF/protocol work (though I do acknowledge that ICANN
may consider protocol factors when making decisions - or I would hope that
they would).

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Nov 2019 21:43:10 +0100

On Mon 11/Nov/2019 19:31:52 +0100 Kurt Andersen (b) wrote:
>> For various reasons, large organizations administer many apparently 
>> unrelated domains.  For example, _dmarc.youtube.com has a rua mailto
>> ending in @google.com.  We cannot infer an OD from that, but I think the
>> concept is clear.>>
> 

If it were possible to infer OD from some kind of DNS record (or from RDAP
responses, for another way) then we'd have a tool alternative to the PSL.  That
proves that the concept of OD is independent of the PSL, doesn'it?

>>> As to the proposed "let's run this as an experiment pending DMARCbis",
>>> I don't see how that satisfies Dave's concern about creating new work
>>> for receivers in order to help a small set of domain (realm) owners. I'm
>>> not opposed to it, but I just don't see how this solves the issue.>>
>> Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt 
>> returns an empty NOERROR response, while _dmarc.gov.uk returns a valid
>> record. The latter is a Nominet, already solved problem, AFAICS.>>
> 

Oh, you meant the receivers burden of an extra lookup?  Sorry, I though it was
about the need for each OD to opt out by defining its own DMARC record, lest
have reports delivered to the realm.  In the latter sense, Nominet solved the
problem of what rights has gov.uk on domains below it.

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 11 Nov 2019 16:27:29 -0500

Kurt

You are absolutely correct.  We were having such discussions about the PSL
origins that I was going back over the DMARC spec and refreshing my
memory on how the PSL was defined and used. I wasn't even looking at the
PSD document.

Tim

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 11 Nov 2019 16:35:12 -0500

> proves that the concept of OD is independent of the PSL, doesn'it?

Over in DNSOP we're been working with the authors on this Related Domains
draft

https://datatracker.ietf.org/doc/draft-brotman-rdbd/

which defines a mechanism where two domains can state they are related, or
not related via DNS records.
What one wishes to use this information is left to them.

It would be great to get y'all giving feedback

Tim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Nov 2019 14:21:12 -0800

On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote:
> organizations that fall within their jurisdictional purview.

This goes to the essential challenge of a proposal like PSD.  It 
embodies a particular model, in the absence of clarity about the model 
or broad-based discussion of its appropriateness.  (Note, for example, 
that my review offered some discussion of that sort but got no comment 
on that discussion.)

In effect, it creates a strategic solution -- that is, a long-lived and 
embedded mechanism -- without a clear and broad understanding of the 
organizational space it is working in.

On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
> * add text to the PSD draft making it clear that what it's describing 
> is an experiment whose outcome will be taken only as feedback to the 
> revision of the standard (i.e., this is not intended to be the final 
> form of anything), and it is not intended to be deployed outside of 
> the experiment's participants;

Forgive me, but while everyone involved in this has extensive experience 
and is trying to solve a real and serious issue, this is an 
astonishingly naive view.

The IETF does standards, not experiments.  Not /real/ experiments.  What 
it calls an experiment mostly serves as market testing, with a smidgen 
of engineering tuning later.  For the most part, IETF experiments 
produce an accepted/failed/needs-small-revisions range of results.  What 
it does /not/ produce is results along the lines of "that was 
interesting, now let's start fresh and do the real standard."

Perhaps there are exampls of IETF experiments that have permitted 
entirely starting over, but mostly those only happen when there is a 
complete failure, and those typically are called experiments.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Nov 2019 14:27:07 -0800

On 11/11/2019 2:21 PM, Dave Crocker wrote:
> and those typically are called experiments.

/not/ called.

(sorry)

d/

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2019 17:31:10 -0500

>It would be great to get y'all giving feedback

If it's useful at all, which I don't think it is, it's definitely not
useful for PSD since it's intended to describe cross-tree
relationships, not the vertical ones that the PSL identifies and that
PSD needs.

This proposal also invents yet another signature scheme, presumably
for the benefit of people who don't think DNSSEC will ever work, which
is strange since the lead author works for Comcast who have what is
probably the world's biggest set resolvers that validate and use
DNSSEC and DANE.

R's,
John

PS: It's not that I think there are no cross-tree relationships to
describe, it's that we know from Andrew Sullivan's failed SOPA
proposal that doing it one label at a time rather than subtree
to subtree isn't viable.

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2019 17:47:47 -0500

>organizational space it is working in.

I've been talking to some of the PSL people, and they seem really
stuck.  They know they don't have a way to describe vanity
single-registrant TLDs, and I don't even want to suggest that they
might want to describe something like PSD, with a super-authority
above a suffix boundary.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 11 Nov 2019 14:51:17 -0800

> problem of what rights has gov.uk on domains below it.

Requiring "trick" authoritative name servers at the realm level is a/the
solution?!? If so, let's just drop all this I-D noise and get it all done.
That would also solve .bank's problem because they would not have to
"publish" any records contravening ICANN's requirements. They would only
have to "serve" them as responses.

--Kurt

---

From: Ian Levy <[email-masked]>
Date: Tue, 12 Nov 2019 06:59:09 +0000

> while _dmarc.gov.uk returns a valid record. The

I can speak authoritatively about this. What we’ve got is an evil, hacky kludge that has some weird side effects (since we respond to *any* non existent sub domain, not just DMARC and SPF related ones). It’s just about passable as an interim, but we believe we need a better, targeted solution along the lines of Scott’s draft.

Ta.

I.

—
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]
________________________________
From: dmarc <[email-masked]> on behalf of Alessandro Vesely <[email-masked]>
Sent: Monday, November 11, 2019 5:50:30 PM
To: [email-masked] <[email-masked]>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Best
Ale
--

_______________________________________________
dmarc mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C63443737a62a47a65f1008d766cfae3a%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637090914473667320&amp;sdata=cOeg7QPSBP0Fzldb8a0RE3ZqsIrBmVG%2B4B2HOrCopaQ%3D&amp;reserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 Nov 2019 09:16:38 +0100

On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote:
>> while _dmarc.gov.uk returns a valid record. The latter is a Nominet,
>> already solved problem, AFAICS.>
> I can speak authoritatively about this. What we’ve got is an evil, hacky
> kludge that has some weird side effects (since we respond to *any* non
> existent sub domain, not just DMARC and SPF related ones). It’s just about
> passable as an interim, but we believe we need a better, targeted solution
> along the lines of Scott’s draft.

Thank you for chiming in.  Let me pinpoint that the hack you talk about is the
use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a
protocol issue.

At a PSO level, someone decided that gov.uk can publish TXT records which may
affect all of the downward tree --solved.  The bank PSO cannot do that, and we
(the WG) look forward to ICANN allowing it --not yet solved.  The com PSO
cannot do it either, but I'd guess lots of people trust that ICANN will never
allow it.

I hope I've now clarified what I mean by "ICANN problem".  Scott's draft cannot
solve it, albeit it nearly touches on the point at the end of the intro.  It is
not a protocol problem.  It involves PSO-registrants agreements, and ICANN
managing that stuff.  There is not much we (the WG) can do, except hoping that
ICANN may consider protocol factors when making decisions.  As an Internet
user, I'd welcome diversity among TLDs, as numerousness without diversity
becomes just annoying.

Best
Ale
--

---

From: Ian Levy <[email-masked]>
Date: Tue, 12 Nov 2019 14:12:39 +0000

> Let me pinpoint that the hack you talk about is the use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a protocol issue.

Fair point. I was only trying to make sure that people don’t take wildcards as a long term solution to this problem. In our experience, they're not. 

> At a PSO level, someone decided that gov.uk can publish TXT records which may affect all of the downward tree --solved.  

That was me. Still don't agree that the problem is 'solved', but I may just be being a pedant :-).

> The bank PSO cannot do that, and we (the WG) look forward to ICANN allowing it --not yet solved.  

Agreed. 

> I hope I've now clarified what I mean by "ICANN problem".

Yes, thanks. I think we can, as the WG, do something - and that's to make known to ICANN the problem we believe exists and how their current policy could be amended (safely) to help fix it. We'll certainly do that, but I know our voice is not strong. Consistent messaging from people on this group would help, I believe. 

Ta.

I.

Staff Officer : Kate Atkins, [email-masked]

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
Sent: 12 November 2019 08:17
To: [email-masked]
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote:
> I can speak authoritatively about this. What we’ve got is an evil, 
> hacky kludge that has some weird side effects (since we respond to 
> *any* non existent sub domain, not just DMARC and SPF related ones). 
> It’s just about passable as an interim, but we believe we need a 
> better, targeted solution along the lines of Scott’s draft.

Thank you for chiming in.  Let me pinpoint that the hack you talk about is the use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a protocol issue.

At a PSO level, someone decided that gov.uk can publish TXT records which may affect all of the downward tree --solved.  The bank PSO cannot do that, and we (the WG) look forward to ICANN allowing it --not yet solved.  The com PSO cannot do it either, but I'd guess lots of people trust that ICANN will never allow it.

I hope I've now clarified what I mean by "ICANN problem".  Scott's draft cannot solve it, albeit it nearly touches on the point at the end of the intro.  It is not a protocol problem.  It involves PSO-registrants agreements, and ICANN managing that stuff.  There is not much we (the WG) can do, except hoping that ICANN may consider protocol factors when making decisions.  As an Internet user, I'd welcome diversity among TLDs, as numerousness without diversity becomes just annoying.

Best
Ale
--

_______________________________________________
dmarc mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cf21cf2f2ad5f40c6740208d76748ae44%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637091434175522175&amp;sdata=EZCj0S7gpioXC1UWsJ%2B8wsU8D1%2FPdtA2FZGBn84vj%2BQ%3D&amp;reserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©