Subject: [DNSOP] Verifying TLD operator authorisation

From: Nick Johnson <[email-masked]>
Date: Fri, 14 Jun 2019 14:18:01 +1200

I'm working on a system that needs to authenticate a TLD owner/operator in
order to take specific actions. We had intended to handle this by requiring
them to publish a token in a TXT record under a subdomain of nic.tld, but
it's been brought to our attention that we can't rely on nic.tld being
owned by the TLD operators - this is only a reserved domain on ICANN
new-gTLDs, not on ccTLDs or older gTLDs.

An alternative is to require a message signed by the TLD's DNSSEC zone
signing key, but I'm uncertain whether it's practical for TLD operators to
sign arbitrary messages using their keys.

Are there domains that are globally reserved for the operator across all
TLDs? If not, does anyone have any recommendations on an alternative
authorisation or authentication mechanism?

-Nick Johnson

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 Jun 2019 19:30:10 -0700

On Jun 13, 2019, at 22:18, Nick Johnson
<nick=[email-masked]> wrote:

> I'm working on a system that needs to authenticate a TLD owner/operator in order to take specific actions.

Can you give an example of the actions?

When you say "owner/operator" what exactly do you mean?

> We had intended to handle this by requiring them to publish a token in a TXT record under a subdomain of nic.tld, but it's been brought to our attention that we can't rely on nic.tld being owned by the TLD operators - this is only a reserved domain on ICANN new-gTLDs, not on ccTLDs or older gTLDs.

Right.

> An alternative is to require a message signed by the TLD's DNSSEC zone signing key, but I'm uncertain whether it's practical for TLD operators to sign arbitrary messages using their keys.

It does sound like a bit of a stretch. Also, not all TLDs are signed,
and some of those that are have KSKs that are constrained by process
as to how they can use, so using them for a new purpose might be
expensive.

> Are there domains that are globally reserved for the operator across all TLDs?

The zone apex is the only owner name you can rely upon always
corresponding to a particular TLD, but don't expect it to be simple to
publish new and exciting things there in all cases.

> If not, does anyone have any recommendations on an alternative authorisation or authentication mechanism?

It's hard to make a useful suggestion without understanding what
you're trying to accomplish.

Joe

---

From: Nick Johnson <[email-masked]>
Date: Fri, 14 Jun 2019 14:38:11 +1200

> Can you give an example of the actions?

We build and maintain ENS, a naming system based on the Ethereum
blockchain. We're building a DNS integration that will permit any TLD
operator to claim and operate that TLD inside ENS. To do that, we need some
way for the owner or operator of the TLD to assert a public key that should
have control of the TLD in our system.

> When you say "owner/operator" what exactly do you mean?

Any party authorised by the TLD owner to take actions on their behalf. The
right to publish records to their zone, or to sign messages with their zone
key, seems like a reasonable proxy for that.

> > We had intended to handle this by requiring them to publish a token in a
> TXT record under a subdomain of nic.tld, but it's been brought to our
> attention that we can't rely on nic.tld being owned by the TLD operators -
> this is only a reserved domain on ICANN new-gTLDs, not on ccTLDs or older
> gTLDs.
>
> Right.
>

We're okay for now with not supporting unsigned zones, but the latter seems
like a definite issue. I don't have a lot of insight into how TLD operators
handle their signing keys, and I'm hoping others here can offer more
details on how difficult this might be.

> TLDs?

Indeed - it's my understanding that ICANN forbids publishing anything to
the root zone other than necessary records such as SOA, NS and DNSKEY.

> > If not, does anyone have any recommendations on an alternative

---

From: Rubens Kuhl <[email-masked]>
Date: Thu, 13 Jun 2019 23:51:02 -0300

> On 13 Jun 2019, at 23:18, Nick Johnson <nick=[email-masked]> wrote:
> 
> I'm working on a system that needs to authenticate a TLD owner/operator in order to take specific actions. We had intended to handle this by requiring them to publish a token in a TXT record under a subdomain of nic.tld, but it's been brought to our attention that we can't rely on nic.tld being owned by the TLD operators - this is only a reserved domain on ICANN new-gTLDs, not on ccTLDs or older gTLDs.
> 
> Are there domains that are globally reserved for the operator across all TLDs? If not, does anyone have any recommendations on an alternative authorisation or authentication mechanism?

All TLDs have admin and tech contacts published at https://www.iana.org/domains/root/db/[TLD].html <https://www.iana.org/domains/root/db/%5BTLD%5D.html> (or port-43 WHOIS if you prefer) ; send e-mail to both of them, both need to be clicked to confirm TLD ownership.
After that, use whatever mutual authentication system you feel like using.

Rubens

---

From: Nick Johnson <[email-masked]>
Date: Fri, 14 Jun 2019 14:56:49 +1200

On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl <[email-masked]> wrote:

> All TLDs have admin and tech contacts published at
> https://www.iana.org/domains/root/db/[TLD].html (or port-43 WHOIS if you
> prefer) ; send e-mail to both of them, both need to be clicked to confirm
> TLD ownership.

That would work, but we'd rather use a mechanism that can be publicly
verified by anyone.

-Nick

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 14 Jun 2019 00:02:15 -0300

> On 13 Jun 2019, at 23:56, Nick Johnson <[email-masked]> wrote:
> 
> On Fri, Jun 14, 2019 at 2:51 PM Rubens Kuhl <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 13 Jun 2019, at 23:18, Nick Johnson <nick=[email-masked] <mailto:nick=[email-masked]>> wrote:
>> 
> That would work, but we'd rather use a mechanism that can be publicly verified by anyone.

Like sending an e-mail to a mailman list archive after the process is completed ?

Rubens

---

From: Nick Johnson <[email-masked]>
Date: Fri, 14 Jun 2019 15:41:43 +1200

On Fri, Jun 14, 2019 at 3:02 PM Rubens Kuhl <[email-masked]> wrote:

>> On 13 Jun 2019, at 23:18, Nick Johnson <
>> nick=[email-masked]> wrote:
>>
>> I'm working on a system that needs to authenticate a TLD owner/operator
>> in order to take specific actions. We had intended to handle this by
>> requiring them to publish a token in a TXT record under a subdomain of
>> nic.tld, but it's been brought to our attention that we can't rely on
>> nic.tld being owned by the TLD operators - this is only a reserved domain
>> on ICANN new-gTLDs, not on ccTLDs or older gTLDs.
>>

Email isn't terribly secure - a mailmain list doesn't prove the email
really existed, or was sent by the purported senders.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 14 Jun 2019 09:12:00 +0200

Nick,

On 14/06/2019 04.18, Nick Johnson wrote:
> nic.tld being owned by the TLD operators - this is only a reserved 
> domain on ICANN new-gTLDs, not on ccTLDs or older gTLDs.
> 
> signing key, but I'm uncertain whether it's practical for TLD operators 
> to sign arbitrary messages using their keys
If people are using HSM running in restricted environments, then getting 
them to sign arbitrary records will be hard - by design!

What you're asking for is not something that exists today, so TLD 
operators are not going to have processes for it. That means that it's 
going to be impractical (meaning "this will require process and 
engineering changes, and therefore cost money") for some (if not all) 
TLD operators.

My own advice would be to design a system that works well for the early 
adopters - whichever TLD operators you are talking to now that might be 
interested. You can add additional mechanisms later. In the end you may 
end up with a dozen or so methods, but that shouldn't be surprising 
given the diversity of TLD operators.

One final note: DNSSEC is not really designed for historical 
attestations. It's designed to give you a trustworthy view of a small 
corner the DNS *right now*. This is a completely different requirement 
from blockchain where the idea is to be able to go back to any (?) 
historical transaction and verify it. So even if you can authenticate 
that someone holds the private material for a DNSKEY today, that won't 
mean anything to someone wanting to audit that 10 years from now. In 
terms of design, you need to find some way to convert the authentication 
that you get today into a historical record (like maybe requiring that a 
significant number of people verify the authentication and put that in 
your blockchain as the historical record).

Cheers,

--
Shane

---

From: Jim Reid <[email-masked]>
Date: Fri, 14 Jun 2019 13:40:08 +0100

> On 14 Jun 2019, at 03:18, Nick Johnson <nick=[email-masked]> wrote:
> 
> I'm working on a system that needs to authenticate a TLD owner/operator in order to take specific actions. We had intended to handle this by requiring them to publish a token in a TXT record

This assumes someone who is able to update the TLD has the authority or ability to change the TLD’s delegation. That’s not necessarily true. Think of registries who outsource their registry operations and/or DNS service to third parties. Such third parties might well be able to edit the zone file (or whatever) but that doesn’t necessarily mean the registry authorised or requested those changes.

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Fri, 14 Jun 2019 15:13:12 +0200

Would (GPG encrypted) email to the registered address to the authority
not be sufficient?  That would make sure the recipient is authorized and
must then cause the token to be 'delegated' as the second factor.

Greetings, el

On 2019-06-14 14:40 , Jim Reid wrote:
> 
> 
>> On 14 Jun 2019, at 03:18, Nick Johnson
>> I'm working on a system that needs to authenticate a TLD
>> owner/operator in order to take specific actions.  We had intended to
>> handle this by requiring them to publish a token in a TXT record
> 
> This assumes someone who is able to update the TLD has the authority
> or ability to change the TLD’s delegation.  That’s not necessarily
> true.  Think of registries who outsource their registry operations
> and/or DNS service to third parties.  Such third parties might well be
> able to edit the zone file (or whatever) but that doesn’t necessarily
> mean the registry authorised or requested those changes.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Dr. Eberhard W. Lisse          / Obstetrician & Gynaecologist (Saar)
[email-masked]            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421                  /
Bachbrecht, Namibia     ;____/

---

From: Jim Reid <[email-masked]>
Date: Fri, 14 Jun 2019 14:23:43 +0100

> On 14 Jun 2019, at 14:13, Dr Eberhard W Lisse <[email-masked]> wrote:
> 

If there was a secure* channel between the TLD registry and IANA like the GPG email you suggested, there wouldn’t really be a need to insert and check for some token in the TLD zone. Though as you say, that measure might be a useful way of adding 2FA.

* For some definition of secure.

In any case, I’m not sure this list is the right place to define or develop a solution for this issue. We probably don’t have a complete understanding of the problem space or the details of how IANA and TLD registries/SOs communicate with each other, what the requirements are, etc, etc.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 14 Jun 2019 15:29:59 +0200

> must then cause the token to be 'delegated' as the second factor.

What GPG key?  Sounds OK to me, *assuming* that "someone standardizes"
how to determine whether a GPG key has authority to decide such things. 
AFAIK the usual GPG trust approach is fully decentralized, so it will
generally give different results to different observers, which is
probably not desirable *here*.  I don't expect you meant to suggest e.g.
somehow using a KSK for signing an e-mail?

> If there was a secure* channel between the TLD registry and IANA
The original question isn't about a channel towards IANA, as far as I
understand it, but towards public, i.e. a signature that anyone should
be able to verify.

---

From: Nick Johnson <[email-masked]>
Date: Sun, 16 Jun 2019 11:35:41 +1200

> given the diversity of TLD operators.

This seems like good advice - thanks!

Our backup option is of course to manually authenticate and approve each
request. However, one concern we have is that this will make it impossible
to migrate to a more automated system later, since it would presumably
require existing TLDs to add support for whatever system we come up with.

> your blockchain as the historical record).

I could be missing something, but I don't see this as an issue here. When a
user makes a claim supported by a DNSSEC signed record, they submit the
record and the signature, along with any keys and signatures further up the
chain of trust required to validate it. Anyone can then come back later and
verify that the request was supported by a valid chain of trust at the time
of submission.

On Sat, Jun 15, 2019 at 12:40 AM Jim Reid <[email-masked]> wrote:

> requiring them to publish a token in a TXT record
>
> This assumes someone who is able to update the TLD has the authority or
> ability to change the TLD’s delegation. That’s not necessarily true. Think
> of registries who outsource their registry operations and/or DNS service to
> third parties. Such third parties might well be able to edit the zone file
> (or whatever) but that doesn’t necessarily mean the registry authorised or
> requested those changes.
>

I think that, if an outsourced registry operator is inserting DNS records
or making attestations not approved by the TLD owner, they have a problem
of much wider scope. I'm happy with a threat model that expects operators
to be faithfully executing the instructions of the TLD owners.

 On Sat, Jun 15, 2019 at 2:21 AM Stephane Bortzmeyer <[email-masked]>
wrote:

> On Fri, Jun 14, 2019 at 02:38:11PM +1200,
>  Nick Johnson <nick=[email-masked]> wrote
>  a message of 173 lines which said:
>
> You mean the TLD zone?

Sorry, yes I did.

---

From: Bjarni Rúnar Einarsson <[email-masked]>
Date: Tue, 18 Jun 2019 10:13:46 -0000

Hi Nick, everyone,

Nick Johnson <nick=[email-masked]> wrote:
> owner/operator in order to take specific actions. We had
> intended to handle this by requiring them to publish a token in
> a TXT record under a subdomain of nic.tld, but it's been
> brought to our attention that we can't rely on nic.tld being
> owned by the TLD operators - this is only a reserved domain on
> ICANN new-gTLDs, not on ccTLDs or older gTLDs.

The SOA record for a TLD contains two DNS names which should be
under the control of the NIC: that of the primary master
nameserver, and the e-mail of the responsible administrator
(which includes a domain name).

Intro: https://en.wikipedia.org/wiki/SOA_record

People on this list can probably comment on whether my above
assumption is correct, and whether those are good candidates for
what you have in mind.

Hope this helps,
 - Bjarni

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 Jun 2019 12:27:47 +0100

> On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson <[email-masked]> wrote:
> 
> under the control of the NIC ...

Being able to control a zone’s SOA record (or whatever) means just that. No more, no less. It doesn’t mean someone who has that ability also has the authority to change the zone’s delegation even though they can manipulate the zone contents.

Consider a registry that outsources authoritative DNS service. For instance one of the slave servers for .is could mess about with their copy of the zone file. [Admittedly breaking DNSSEC validation unless they also had access to the appropriate private key.] Modifying the SOA record doesn’t give that misbehaving slave provider authority to go to IANA and get the .is delegation changed even if they can make the SOA record or whatever “look right” in support of their bogus change request.

2FA on changes to TLD delegations is a good thing. However I doubt this can be done safely through a mechanism that relies on a magic token being present or absent from the TLD itself. That approach changes the threat model and introduces new attack vectors. These need careful consideration and testing. DNSSEC signing helps of course but isn’t necessarily a magic bullet: suppose the registry has also outsourced TLD signing.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 18 Jun 2019 15:56:06 +0200

Jim,

> Being able to control a zone’s SOA record (or whatever) means just that. No more, no less. It doesn’t mean someone who has that ability also has the authority to change the zone’s delegation even t…

You're basically arguing against ACME-style authentication.

While you are not necessarily wrong, people find the approach useful 
enough to not worry about who "really" owns a web server, and I suspect 
that a conscious decision can be made to not worry about who "really" 
owns a TLD in much the same way.

Cheers,

--
Shane

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 Jun 2019 15:12:04 +0100

> On 18 Jun 2019, at 14:56, Shane Kerr <[email-masked]> wrote:
> 

Shane, I’m not doing that. At least I don’t think so.

ACME-style authentication is a very good thing, provided its limitations are understood. Using that to demonstrate ownership or control of some zone is not unreasonable. However using ACME-style authentication in that way doesn’t necessarily prove someone has the authority to change the delegation of that zone - more so when the zone is a TLD. All I’m saying here is it’s unwise to make that assumption or build a TLD delegation validation mechanism around it.

---

From: Nick Johnson <[email-masked]>
Date: Thu, 20 Jun 2019 10:28:08 +1200

> (which includes a domain name).

This seems like an excellent idea - thanks! I'll wait to see what others
have to say.

On Tue, Jun 18, 2019 at 11:28 PM Jim Reid <[email-masked]> wrote:

> Being able to control a zone’s SOA record (or whatever) means just that.
> No more, no less. It doesn’t mean someone who has that ability also has the
> authority to change the zone’s delegation even though they can manipulate
> the zone contents.
>
> Consider a registry that outsources authoritative DNS service. For
> instance one of the slave servers for .is could mess about with their copy
> of the zone file. [Admittedly breaking DNSSEC validation unless they also
> had access to the appropriate private key.] Modifying the SOA record
> doesn’t give that misbehaving slave provider authority to go to IANA and
> get the .is delegation changed even if they can make the SOA record or
> whatever “look right” in support of their bogus change request.
>

I think I addressed this upthread: If someone has the ability to change a
zone's DNS records and generate valid DNSSEC signatures for them (which we
will be requiring and verifying), they're sufficiently 'in control' of the
zone that I'm comfortable treating them as the authorised user. If someone
malicious has that control, the TLD owner has much larger problems.

---

From: Joe Abley <[email-masked]>
Date: Wed, 19 Jun 2019 18:45:40 -0400

On 19 Jun 2019, at 18:28, Nick Johnson <nick=[email-masked]> wrote:

> On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson <[email-masked] <mailto:[email-masked]>> wrote:
> This seems like an excellent idea - thanks! I'll wait to see what others have to say.

I think you could probably build a heuristic around MNAME and RNAME that would work at least most of the time. However, there's no definitive identifier and there will always be exceptions you have to work around. Sometimes MNAME relates to a back-end registry provider, sometimes to a registry operator, and sometimes something else entirely. Ditto RNAME.

> I think I addressed this upthread: If someone has the ability to change a zone's DNS records and generate valid DNSSEC signatures for them (which we will be requiring and verifying), they're sufficiently 'in control' of the zone that I'm comfortable treating them as the authorised user. If someone malicious has that control, the TLD owner has much larger problems.

The organisation that generates the SOA/NS/A/AAAA RRSets in a delegation-only TLD zone is not always the same organisation that signs it. Also, not all signatures in a zone can be guaranteed to have been created by the same organisation. Also, not all TLDs are signed.

The contacts that the IANA relies upon to authorise changes for TLD operators can be found at whois.iana.org <http://whois.iana.org/>, for what that's worth, or in due course at the RDAP server specified in the object <https://data.iana.org/rdap/dns.json <https://data.iana.org/rdap/dns.json>>. But if you're looking for something reliable you can validate using DNSSEC, I think you're out of luck.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jun 2019 09:41:06 +1000

> On 20 Jun 2019, at 8:45 am, Joe Abley <[email-masked]> wrote:
> 
>> On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson <[email-masked]> wrote:
> The contacts that the IANA relies upon to authorise changes for TLD operators can be found at whois.iana.org, for what that's worth, or in due course at the RDAP server specified in the object <https://data.iana.org/rdap/dns.json>. But if you're looking for something reliable you can validate using DNSSEC, I think you're out of luck.

And if you try sending to them you find the email addresses are often
do not exist, bounce because the mailbox is full, are gatewayed to a
restricted distribution list, or just ignored.  Some do work though.
My experience maybe biased because I’m always reporting problems when I
send to them and if the operator hasn’t already noticed the problem
there is a good chance the contact is also broken.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 21 Jun 2019 09:33:33 -0400

If y'all care what gets published in a TLD, please take a look at
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
which is an experimental draft that will go into WGLC last call soon.
This was driven by wanting to add _dmarc records
into TLDs, per ICANN rules it needs to be an RFC.

Tim

(Murray Kucherawy, Seth Blank and myself may have something to do with the
DMARC working group management).

On Wed, Jun 19, 2019 at 7:41 PM Mark Andrews <[email-masked]> wrote:

> > I think you could probably build a heuristic around MNAME and RNAME that
> would work at least most of the time. However, there's no definitive
> identifier and there will always be exceptions you have to work around.
> Sometimes MNAME relates to a back-end registry provider, sometimes to a
> registry operator, and sometimes something else entirely. Ditto RNAME.
> >
> >> I think I addressed this upthread: If someone has the ability to change
> a zone's DNS records and generate valid DNSSEC signatures for them (which
> we will be requiring and verifying), they're sufficiently 'in control' of
> the zone that I'm comfortable treating them as the authorised user. If
> someone malicious has that control, the TLD owner has much larger problems.
> >
> > The organisation that generates the SOA/NS/A/AAAA RRSets in a
> delegation-only TLD zone is not always the same organisation that signs it.
> Also, not all signatures in a zone can be guaranteed to have been created
> by the same organisation. Also, not all TLDs are signed.
> >
> > The contacts that the IANA relies upon to authorise changes for TLD
> operators can be found at whois.iana.org, for what that's worth, or in
> due course at the RDAP server specified in the object <
> https://data.iana.org/rdap/dns.json>. But if you're looking for something
> reliable you can validate using DNSSEC, I think you're out of luck.
>

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 21 Jun 2019 10:07:10 -0400

>> > the root zone other than necessary records such as SOA, NS and DNSKEY.
The set of allowed RRTYPEs in a gTLD zone can (and does) change, given a
reasonable justification, and enough interest and pressure from the
registries.  For example, the last revision of the Registry Services
contract that ICANN put out[0] added a record for zone versioning
independent of the SOA record.

You can get a new RRTYPE reserved for your purposes quite easily[1].  With
that, you could run a trial with some early-adopting ccTLDs (not
constrained by ICANN's Registry Services contract) to demonstrate the
utility of your scheme.  If it's attractive enough to warrant the internal
process and development costs to deploy, and the ICANN lobbying efforts,
then the gTLD operators could have it added to the contract.

Whatever your deployment method, you will need to demonstrate some benefit
to the registries if you want them to adopt your scheme.  Making changes to
their process isn't cheap, and there is no such thing as a one-off cost;
everything added to their operation needs to be maintained and monitored,
which incurs an ongoing cost.

[0]: Exhibit A, §1.1 <
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf
[1]: <https://tools.ietf.org/html/rfc6895#section-3.1.1>

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2019 23:08:13 -0400

In article <CADyWQ+HVYAfVE0WSEPAG7Zz_OL+uM4DmHRLn6Y=[email-masked]> you write:
>-=-=-=-=-=-

I'm not thrilled about it since I would prefer that we nerd harder on
the general domain boundary problems (the ones for which we all use
the PSL), but PSD for its particular use case of name trees seems
pretty harmless.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 22 Jun 2019 19:14:09 -0400

John

I totally agree with you we need to Nerd Harder one the problem space, and
folks are trying.
But one way we Nerd Harder is to do experiments like this and study how it
works, and
use that moving forward.

I've been talking to folks over the past months on this problem space
trying to grapple with
quantifying what other folks see.   Part of this reason is that my employer
has this problem,
and while my boss and I have noodled on the idea off and of for the past
year, my feeling
is that our Java developers will decide to solve this problem for their use
case, and it will
be done in their way makes their life easier and everyone else's life
harder.   I'd like to
be in front of the problem, leading them toward my promised land than
chasing them from behind
nipping at their heels.

Talking as a chair, I see this more of an Application of DNS Problem than a
DNS Operations Problem,
but I'm willing to be convinced otherwise.  This means, the work may be out
of scope for DNSOP.

I do feel that whatever solution the IETF works we, we have to first accept
that it will *not* replace
the Public Suffix List initially.  The PSL is a W3C entity, and while I
feel they will look honestly at what
the IETF may create, they are free to adopt or not adopt it for the PSL,
and the IETF needs to
accept that.

We've not only have to solve the problem, we need to make a convincing case
for the W3C to adopt.
I find the IETF is great at the former, and struggles at times with the
latter.

Tim
(mostly speaking as myself)

---

From: "John R Levine" <[email-masked]>
Date: 22 Jun 2019 22:27:14 -0400

> trying to grapple with quantifying what other folks see.  Part of this 
> reason is that my employer has this problem, ...

Sorry, it's not clear what "this problem" is in context.  Applying DMARC 
across all of a TLD or public 2LD (what PSD does)?

PSD can clearly do what it's intended to if DMARC code implements it, and 
since the number of DMARC libraries can be counted on one's fingers, that 
seems plausible.  But the bigger issue of identifying single-owner domains 
at various level, and something that scales better than downloading a text 
file remain open.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 24 Jun 2019 12:01:38 +0200 (CEST)

Il 20 giugno 2019 00:28 Nick Johnson <nick=[email-masked]> ha scritto:

I hate being the engineer that sold his soul to the dark side of policy talks, and also it's not fully clear what you want to do after establishing this technical link between ICANN's root and your alternative namespace, but I would really recommend you to have someone competent make a proper legal/policy analysis of your plans.

For example, if after adding existing ICANN-rooted TLDs under ENS your users will be able to perform anything resembling a domain registration or transfer, that is likely to be highly regulated by ICANN contracts and/or, for ccTLDs in several countries, by national laws; breaking those rules could expose you and the registry to serious issues. If you add that this has to do with "blockchain" - a politically sensitive and vaguely regulated topic in many parts of the world - the likelihood of politicians discovering this, not understanding it and screaming at the registry, for example, is definitely not zero.

Also, checking technical proof of control of a zone is not a legally valid way to conclude a contract with its owner, and you'd be much better off if you had a legally authorized representative of the registry sign an appropriate piece of paper with you (or at least go through T&Cs in a web procedure). Otherwise, in case of problems, the registry could claim that they never actually consented to this and that you basically hacked them with the unauthorized help of one of their suppliers or employees.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy