Subject: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Thu, 05 Nov 2015 17:20:18 -0800

The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state 
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-ogud-dnsop-maintain-ds/

---

From: Shane Kerr <[email-masked]>
Date: Fri, 6 Nov 2015 11:55:06 +0900

Dear dnsop working group,

On Thu, 05 Nov 2015 17:20:18 -0800

> https://datatracker.ietf.org/doc/draft-ogud-dnsop-maintain-ds/

First, I definitely think that this should be a working group document.

Second, some comments about the draft (with the hope that it does get
adopted):

* I think "all 0" CDS/CDNSKEY indicating desire for deletion is fine.
  Defining a DNSKEY algorithm that does not actually define a DNSKEY
  algorithm is a bit weird.

* Perhaps a paragraph clarifying behavior when there is the "all 0"
  CDS/CDNSKEY AND another CDS/CDNSKEY record is a good idea?
  Something like:

    If any other CDS/CDNSKEY record is present in a zone, then the
    CDS/CDNSKEY records indicating deletion MUST be ignored.   

* The acceptance criteria for new CDS records seem less like a protocol
  definition and more like an exploration of possible approaches.
  Probably this is because that is what they are? :P Does it make sense
  to define more detail? I kind of think "yes", but since there is no
  deployment experience it's likely that it would all be incorrect.

* I don't see much motivation for "Acceptance policy via authenticated
  channel". It seems like if you have access to such a channel you may
  as well just provide the DS record? Or is the idea that you make it so
  that the administrator for a zone doesn't need to cut/paste DS
  information but can just check a "delegate this" box?

* Perhaps "Accept with challenge" should provide some advice on how
  this works. For example, a TXT record with a unique key for each zone
  (or customer) seems like a good recommendation. It might also make
  sense if each child domain (or customer) has a unique ownername to
  look for, to prevent 3rd parties from detecting such bootstrapping.
  (Yes a 3rd party can see the CDS update followed by the DS update,
  but they won't know the verification used.) Also to note that after
  the trust is established that the challenge record should no longer
  be necessary and can be removed.

Sayōnara!

--
Shane

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Nov 2015 11:49:19 -0500

> On Nov 5, 2015, at 9:55 PM, Shane Kerr <[email-masked]> wrote:
> 

Shane, 
good suggestion we will adopt it, maybe with some rewording. 

>  deployment experience it's likely that it would all be incorrect.

You are right it is a protocol exploration as we have nothing but what has shown to be difficult to deploy. 
And hopefully you are also wrong on if this advise will be ignored, I hope it will become the bases
of many operations. 

>  information but can just check a "delegate this" box?

Well the idea is a that a DNS operator can Identify the request that the CDS/CDNSKEY processing by parent is started. 
possibly even handing over the expected records. 
In my employers case the acceptance policy is we give the people that are willing to work with us the list of keys we will sign with, 
because that is a short list. 

>  be necessary and can be removed.

There are many different ways to do this
a) generate a random name with a  <type>  record with defined content 
b) put a <type> record at a fixed name with random content 
c) require resigning the CDS/CDNSKEY record with defined expiration time 
etc. it is just a question of imagination what people come up with. 
If the working group wants to recommend one standard way, that is fine. 
Text welcome 

> —

Olafur

---

From: Jan Včelák <[email-masked]>
Date: Sun, 8 Nov 2015 21:49:56 +0100

> If the working group wants to recommend one standard way, that is fine. 

The value determined by the parent need not be random but can actually
authenticate the CDS RDATA content. What about something like this:

--8<--

Parent instructs the requestor to add a TXT RR into the zone with owner
name matching the zone name prefixed with the '_cds' label. The RDATA of
the record contain a value determined by the parent and provided to the
client by a secure channel (e.g. domain registration system).

The parent constructs the value as follows:

HEX(HMAC-SHA256-64(parent_secret, cds_owner|cds_rdata))

Where:

- HEX is a conversion from binary to lowercase hexadecimal digits.
- HMAC-SHA256-64 is an authentication code as specified in RFC 6234.
- server_secret is a cryptographically strong secret key known only
  to the parent.
- cds_owner is the wire format representation of the child zone name
  in the canonical form.
- cds_rdata is the wire format representation of the CDS RDATA in the
  canonical form.

--8<--

However, this trust establishing dance still requires interaction with
the parent via an out-of-band channel. So there is a little difference
from giving the parent the initial DS records directly.

Cheers,

Jan

---

From: Jacques Latour <[email-masked]>
Date: Tue, 17 Nov 2015 18:31:39 +0000

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Jan Vcelák
> Sent: November-08-15 3:50 PM
> To: Olafur Gudmundsson; Shane Kerr
> Cc: [email-masked]
> Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds
> in state "Candidate for WG Adoption"
> 
> > c) require resigning the CDS/CDNSKEY record with defined expiration
> > time etc. it is just a question of imagination what people come up with.
> Parent instructs the requestor to add a TXT RR into the zone with owner name
> matching the zone name prefixed with the '_cds' label. The RDATA of the record
> contain a value determined by the parent and provided to the client by a secure
> channel (e.g. domain registration system).
> 
> However, this trust establishing dance still requires interaction with the parent
> via an out-of-band channel. So there is a little difference from giving the parent
> the initial DS records directly.
> 

Jan, this is exactly where we started and ended up where we are today;

We originally started looking at a trust dance with secret keys and out of band key exchange, it's not what we were looking for since we're trying to avoid any out of band exchange. However, the outcome of this process would prove the DNS operator is in control of the child zone, here I'm not sure we need to trust that the DNS operator is in control of the child zone, we need to prove DNS Operator control, not trust.

* When a registrant submits a DS record via RRR/EPP to the registry, we (registry) trust the registrant to submit a DS, we have no proof it's the right/correct DS. (compromised registrant credentials, bad cut and paste)

Then we looked at simpler trust/proof dances with/without challenge token as TXT record " _delegate DNSKEY ID ChallengeToken", again, this proves the DNS operator is in control of the child zone, and that it proved it interacted with the parent to get the challenge token. We also looked at having just an initial CDS record instead of a TXT record as a proof of control.

For the initial bootstrap, we don't need to prove the registrant controls the child, we need to prove the DNS Operator controls the zone.   The trust was established during the domain registration process, and subsequently the registrant delegated operation of the zone to the DNS Operator.

Something like that, we'll have flexibility on the method to prove control (API) to meet the parents' requirements.

Jack

> Cheers,
> 
> Jan
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop