>> * 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. Cheers, Jan _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
