Subject: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 6 Jun 2019 17:12:40 +0000

I recently had a chance to read through draft-ietf-dmarc-psd. If I understand it correctly (and I'm not sure that I do), the document suggests that it's possible for a TLD like ".com" to be a PSD and a TXT record like "_dmarc.com" can be published in the com zone. I found this part of the draft confusing because it's not possible to add TXT records like that to the com zone. It might help to explicitly note somewhere (perhaps in Section 2.2) that there may be policy restrictions in place that disallow the publication of DMARC policy records in some DNS zones, including some top-level domain zones.

Scott

---

From: Craig Schwartz <[email-masked]>
Date: Thu, 6 Jun 2019 14:52:26 -0400

>On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote:
>I recently had a chance to read through draft-ietf-dmarc-psd. If I
understand it correctly (and I'm not sure that I do), the document suggests
that it's possible for a TLD like ".com" >to be a PSD and a TXT record like
"_dmarc.com" can be published in the com zone. I found this part of the
draft confusing because it's not possible to add TXT records like that >to
the com zone. It might help to explicitly note somewhere (perhaps in
Section 2.2) that there may be policy restrictions in place that disallow
the publication of DMARC policy >records in some DNS zones, including some
top-level domain zones.

The purpose of the document is to convey technically how PSD DMARC can be
accomplished rather than who can or cannot undertake this due to policy
considerations. As the operator of .BANK and .INSURANCE, fTLD initiated
this stream of work with the IEFT because of the explicit prohibition by
ICANN from inserting TXT records in the DNS. The goal is to get to an RFC
that specifies the technical aspect of PSD DMARC and ultimately seek
ICANN's approval to allow publication of such a record in the DNS. In
contrast, gTLDs not under contract with ICANN such as .MIL and .GOV, who
are both involved in this work, do not have a contractual relationship with
ICANN and thus are not prohibited from this activity, and the same goes for
ccTLDs.

Craig

*--*
Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz
www.fTLD.com

On Thu, Jun 6, 2019 at 1:12 PM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> I recently had a chance to read through draft-ietf-dmarc-psd. If I
> understand it correctly (and I'm not sure that I do), the document suggests
> that it's possible for a TLD like ".com" to be a PSD and a TXT record like
> "_dmarc.com" can be published in the com zone. I found this part of the
> draft confusing because it's not possible to add TXT records like that to
> the com zone. It might help to explicitly note somewhere (perhaps in
> Section 2.2) that there may be policy restrictions in place that disallow
> the publication of DMARC policy records in some DNS zones, including some
> top-level domain zones.
>
> Scott
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Jun 2019 11:02:59 +0000

From: dmarc <[email-masked]> On Behalf Of Craig Schwartz
Sent: Thursday, June 6, 2019 2:52 PM
To: Hollenbeck, Scott <shollenbeck=[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

>I recently had a chance to read through draft-ietf-dmarc-psd. If I understand it correctly (and I'm not sure that I do), the document suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT record like "_dmarc.com<http://dmarc.com/>" can be published in the com zone. I found this part of the draft confusing because it's not possible to add TXT records like that >to the com zone. It might help to explicitly note somewhere (perhaps in Section 2.2) that there may be policy restrictions in place that disallow the publication of DMARC policy >records in some DNS zones, including some top-level domain zones.

The purpose of the document is to convey technically how PSD DMARC can be accomplished rather than who can or cannot undertake this due to policy considerations. As the operator of .BANK and .INSURANCE, fTLD initiated this stream of work with the IEFT because of the explicit prohibition by ICANN from inserting TXT records in the DNS. The goal is to get to an RFC that specifies the technical aspect of PSD DMARC and ultimately seek ICANN's approval to allow publication of such a record in the DNS. In contrast, gTLDs not under contract with ICANN such as .MIL and .GOV, who are both involved in this work, do not have a contractual relationship with ICANN and thus are not prohibited from this activity, and the same goes for ccTLDs.

It would be helpful to the reader if the draft were either clear about potential limitations to deployment or more descriptive about the domains for which the approach can work. Right now, PSD DMARC cannot be deployed ubiquitously. That reality should not be overlooked.

Scott

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Jun 2019 18:30:38 -0400

On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, Scott wrote:
> >understand it correctly (and I'm not sure that I do), the document
> >suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT
> >record like "_dmarc.com<http://dmarc.com/>" can be published in the com
> >zone. I found this part of the draft confusing because it's not possible
> >to add TXT records like that >to the com zone. It might help to explicitly
> >note somewhere (perhaps in Section 2.2) that there may be policy
> >restrictions in place that disallow the publication of DMARC policy
> >>records in some DNS zones, including some top-level domain zones.
> 
> 
> 
> 
 
> 
> 
> It would be helpful to the reader if the draft were either clear about
> potential limitations to deployment or more descriptive about the domains
> for which the approach can work. Right now, PSD DMARC cannot be deployed
> ubiquitously. That reality should not be overlooked.

I see your point, but I think it's probably out of scope.  This is an IETF 
document and such restrictions are outside the IETF's control.  Also, keep in 
mind that once an RFC is published, it is immutable.  If that guidance 
changes, then there would be no way to correct the document without spinning 
up a whole new RFC process.

Is there a public, stable reference that describes the restrictions?  If so, 
it might make sense to reference it.  If we can, I think that would be much 
better than 'hard coding' the current external policy in an RFC.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 11 Jun 2019 09:07:59 +0800

> better than 'hard coding' the current external policy in an RFC.

Including this information in the draft would be counter-productive. A
large part of this effort is to document the desired handling so that the
RFC can be used as documentation to support a change in ICANN policy.

--Kurt

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 11 Jun 2019 11:55:37 +0000

From: dmarc <[email-masked]> On Behalf Of Kurt Andersen (b)
Sent: Monday, June 10, 2019 9:08 PM
To: Scott Kitterman <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

On Tue, Jun 11, 2019 at 6:31 AM Scott Kitterman <[email-masked]<mailto:[email-masked]>> wrote:

   Including this information in the draft would be counter-productive. A large part of this effort is to document the desired handling so that the RFC can be used as documentation to support a change in ICANN policy.

   [SAH]: The draft is targeted for Experimental status. It would be irresponsible to not document conditions under which the experiment can or cannot be conducted. Section 3.2 of RFC 7489 does a good job of describing organizational domain variability; might there be some way of defining a PSD that’s based on the definition of an RFC 7489 organizational domain? That would address my concern, and it seems like it should be possible given that the definition of a “Longest PSD” in Section 2.3 is based on the organizational domain description from RFC 7489.

   On a slightly different note, Section 2.2 also says this:

   “PSD DMARC includes all public domains above the organizational level in the tree, e.g., ".gov.uk".”

   Registration in .gov.uk is restricted (https://www.gov.uk/government/publications/naming-and-registering-government-websites). What exactly is meant by “public domains”?

   Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Jun 2019 13:49:13 -0700

> > >>records in some DNS zones, including some top-level domain zones.

As I understand it, we're in an interesting position here: ".com" can't
have a TXT record in that zone due to ICANN policy, and this ICANN policy
won't change without a (published or imminent) RFC that suggests allowing
such records would be of benefit to the community.  So the publication of
this even at experimental might obviate the need for such text in the
document.

Given your concern, I think we're talking about adding text that says
"There may be operational constraints that prevent any given operator's
participation in this experiment."  But isn't that an implicit caveat of
all experiments?

On the other hand, perhaps the largest benefit would be from the restricted
TLD operators if they were allowed to do so.

> Right now, PSD DMARC cannot be deployed

This part I agree with; by pointing out that this cannot be widely deployed
right away, we are highlighting that the results of the experiment could be
understated due to the restrictions Scott H. has identified.

> up a whole new RFC process.

I think it might be beneficial to point out somewhere in the document that
today's operational reality prevents this experiment from being deployed
globally.  However, if the experiment shows that PSD solves a real problem
at a large scale, it would be fodder for appropriate policy changes outside
of the IETF that would permit its ubiquitous deployment.

> better than 'hard coding' the current external policy in an RFC.

I concur.  Does anyone know of such a policy statement from ICANN?  I don't
recall it being present in, say, any of the DNS RFCs, but there are so many
of those now...

-MSK

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2019 11:52:16 +0100

>recall it being present in, say, any of the DNS RFCs, but there are so many

Hi from ICANN 65 in Marrakech.

The gTLD registry contracts say directly or indirectly what's allowed
in each TLD zone.  Here's the language in the base registry agreement
that the new TLDs all use:

https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1

For the older TLDs, notably .com, the contract refers to Consensus Policies,
which are at https://www.icann.org/resources/pages/registrars/consensus-policies-en

One of those policies is the Registry Services Evaluation Policy
(RSEP) which is at
https://www.icann.org/resources/pages/registries/rsep/policy-en

Here's the list of RSEP requests:

https://www.icann.org/resources/pages/rsep-2014-02-19-en

Adding a dmarc record to individual TLD would need an RSEP, for which
an RFC would likely be helpful but probably not essential.  The RSEP
process for things that are not politically controversial is not
particularly hard.

Adding them to all of the TLDs could be a new consensus policy, or
maybe a change to the base agreement.  How to do that is above my
pay grade.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 27 Jun 2019 11:23:40 +0000

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of John Levine
> Sent: Thursday, June 27, 2019 6:52 AM
> To: [email-masked]
> Cc: [email-masked]
> >I concur.  Does anyone know of such a policy statement from ICANN?  I
> >don't recall it being present in, say, any of the DNS RFCs, but there
> >are so many of those now...
>
> The gTLD registry contracts say directly or indirectly what's allowed in each
> TLD zone.  Here's the language in the base registry agreement that the new
> TLDs all use:
>
> Adding a dmarc record to individual TLD would need an RSEP, for which an
> RFC would likely be helpful but probably not essential.  The RSEP process for
> things that are not politically controversial is not particularly hard.
>
> Adding them to all of the TLDs could be a new consensus policy, or maybe a
> change to the base agreement.  How to do that is above my pay grade.

The ICANN minutiae is probably way more detail than is needed in the document. I'd be more comfortable if there were text in the Introduction along the lines of what Murray said in his last note (paraphrased here slightly): "Please note that today's operational and policy reality prevents this experiment from being deployed globally.  If the experiment shows that PSD solves a real problem at a large scale, the results could prove to be useful in the development of policies outside of the IETF that would permit its ubiquitous deployment".

Scott