Re: [DNSOP] Verifying TLD operator authorisation

[Nick Johnson <[e-mail]>]

On Fri, Jun 14, 2019 at 7:12 PM Shane Kerr <[e-mail]>
wrote:

> Nick,
>
> On 14/06/2019 04.18, Nick Johnson 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.
> >
> > 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
> 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.
>

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.


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

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 <[e-mail]> wrote:

>
>
> > On 14 Jun 2019, at 03:18, Nick Johnson <nick=
> [e-mail]> 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.
>

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 <[e-mail]>
wrote:

> On Fri, Jun 14, 2019 at 02:38:11PM +1200,
>  Nick Johnson <nick=[e-mail]> wrote
>  a message of 173 lines which said:
>
> > Indeed - it's my understanding that ICANN forbids publishing anything to
> > the root zone other than necessary records such as SOA, NS and DNSKEY.
>
> You mean the TLD zone?


Sorry, yes I did.