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

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Jan Vcelák
> Sent: November-08-15 3:50 PM
> To: Olafur Gudmundsson; Shane Kerr
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds
> in state "Candidate for WG Adoption"
> 
> >> * 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.
> >
> > 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
> 
> 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.
> 

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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop