Hi Carsten, Thanks a lot for your comments. Please find my answer as follows
> 11.1 Generation of secret key (Page 17) > > > It is possible to use the current DNSKEY RR (RFC 3757) to send the > > public key of the DNS server. > My understanding of the DNSKEY RR is that (at least in the context of > DNSSEC) the DNSKEY RR is bound to a specific DNS zone, but not to a DNS > server. The draft indicates that the DNSKEY is somehow used to > identify/authenticate the DNS server. Which DNSKEY record would that be > (out of which zone)? The encrypted secret key is sent to the other node in TSIG RR in a same packet that CGA-TSIG is sent. So, there is no need for extra packet for sending the secret key. But for key exchange (in the confidentiality scenario), there is a need to send public key so that the other node can encrypt this secret key. I thought to use TKEY (which is not related to DNSSEC but related to TSIG) but as you mentioned about DNSKEY (The draft does not talk about this option), there is a need to modify TKEY RR to adapt to CGA-TSIG. So, I guess the best option here is something like the following scenario to avoid any changes to DNS RRs Node A wants to ask node B for its public key. Node A includes TSIG RR with the algorithm set to CGA-TSIGe and set the CGA-TSIG data length to zero. Node B receives this packet and check the algorithm type. Because it is CGA-TSIGe (CGA-TSIG with encryption), it does not assume to find any query or update in the DNS packet and consider this packet as asking for its public key. Node B, includes his public key in CGA-TSIG data structure of the packet and set the algorithm type to CGA-TSIGe. Node A receives this packet, since it was the answer to his own key request, it retrieves the public key of Node B from CGA-TSIG data structure, generates a secret key, encrypts this secret key with node B public key and encrypt the whole query request with this secret key and sign these messages with its own private key and include its own publickey and other CGA parameters in CGA-TSIG and sends this message to Node B. Node B Receives this message and process the verifications and decrypt the packet. So, in this case we no longer need to use any TKEY in first step as well. Any thought? > > It encrypts this > > secret key using the DNS server public key. This allows only the DNS > > server to decrypt this secret key. > > This implies some private key being online on the DNS server. Which private > key would that be? No it is not a private key. It uses different algorithm and it is only a random number that generates by Node A. However, Node A uses this value and AES algorithm (or any other symmetric algorithm) to encrypt the DNS message and put it back in the DNS sections (update, prerequisite, etc) > 11.2 DNS message generation (Page 17) > > > The node MUST encrypt all DNS message sections that required > > protections using the secret key generated in last section and AES > > symmetric algorithm. > > It is probably not good to hardcode an particular cipher algorithm (AES). Right. I need to consider an algorithm type in CGA-TSIG data structure for symmetric algorithm. I will include it to the draft. > Probably more questions will come up once I read the draft again and work > with the proof-of-concept implementation. Thank you again, Best, Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
