Hi again, Thanks again for your comments. I just continue answering from where I stopped.
> On top of a preliminary Q&A at the dnsop/dnsext lists > (http://www.ietf.org/mail-archive/web/dnsop/current/msg11252.html) > here are a bit more detailed comments on the draft of mine. > > Overall, the advantage of this approach doesn't seem to be very > convincing to > me: > - It's IPv6 only. While I'm a strong lover of IPv6, it's not > realistic (or efficient) to consider a solution for DNS security > that doesn't work for IPv4. I am also thinking about expanding it for IPv4. One possible solution is using the mapping of IPv4 and IPv6. It means use the hash of public key the same way as we use in IPv6 for IPv4. It will not have the same security as exist for IPv6 but it is securer than many current approaches for IPv4. However, I am not quite agree with your point because we are in transition time. It is true that all networks needs to support both IPv4 and IPv6 but there is only some mechanisms that works in both cases. Often, there is a separate policies for the use in IPv4 and IPv6. This is what can be considered here too. Since I do not think the node asks at the same time both IPv4 and IPv6, Does it? So, if it is IPv4, one can use any available mechanism in IPv4 and if it is IPv6, then it can answer use CGA-TSIG. Again, that mapping can also solve this problem. <snip> > - In section 1.1, second paragraph: > > If DNSSEC (RFC 6840) or TSIG, as a security mechanism is in use, then > the problem would be the manual step required for the configuration. > For instance, when a DNSSEC needs to sign the zone offline. The > public key verification in DNSSEC creates chicken and eggs situation. > In other words, the key for verifying messages should be obtained > from DNSSEC server itself. This is why the query requestor needed to > ask other DNS servers up to top level in root to be able to verify > the key. If this does not happen, DNSSEC is vulnerable to IP spoofing > attack. This problem could easily be handled by the use of CGA-TSIG > as a means of providing the proof of IP address ownership. > > I don't understand what this paragraph tries to claim. If the "problem" is that > the validator needs to somehow install some trust anchor (usually at the root > zone and with some manual operation) securely, that's certainly an > operational issue. But I don't understand how CGA-TSIG could solve this. > Whatever it means, we still need to get the server's address securely, so it > seems to simply shift the need for setup somewhere to the need for setup > somewhere else. This paragraph explains that neither DNSSEC nor TSIG can avoid IP spoofing. DNSSEC only can avoid it if a node checks the keys up to the root level in a chain of TAs. Also it explains that for every configuration of TSIG, one needs a manual step while CGA-TSIG eliminates this manual step. As explained in the draft, in zone transfer scenario, one only needs to add the IP address of the authorized zone updater to the zone file. If any of those authorize updater changes its IP address, CGA-TSIG handle this process and no further process is needed. No administrator allows zone transfer from anonymous updater and they need to set up a trust. This drafts also explains other scenarios such as a resolver scenario. This part is what DNSSEC also cannot address it at the moment because the resolver needs to response to anonymous queries. So, there are many questions such as how to do the key exchange of the resolver with anonymous nodes all over the internet. Neither DNSSEC nor TSIG provides the data confidentiality but CGA-TSIG can provide this the same way that can provide the data integrity. It is not as complicated as if it wants to handle in other protocols. So it is not only decreasing the administration process or I call it human intervention (human intervention is a well-known attacks and open the doors to new attacks on DNS servers) but also several other observations that the current protocols are not able to handle it or cannot handle it with a few efforts. > - In Section 5, it uses the term "DNS update (message)" in many places > in the context of zone transfer. example: > > [...] When the DNS update message is processed, the slave DNS > server can authenticate the master DNS server based on the source IP > address and then, prove the ownership of this address by use of the > CGA-TSIG option from the TSIG RR. > > I suspect these "update" should actually be [AI]XFR. IMHO, this is a mechanism or an approach to update a zone file. What I meant in the document is to update a zone file and not different what mechanism is in use either the node wants to use incremental update or the other approach. This is why I used "update" word and not [AI]XFR. IF DNS people thinks it is better to use that word, then I just follow. Any thought? > - In section 11.2: > > [...] It excludes TSIG RDATA (That usually added in > the additional section of the DNS messages) from the encryption text. > > A TSIG RR must "always" be in the additional section, not just > "usually" per RFC2845. I guess, here is misunderstanding of the meaning. What I meant here is that the DNS server does not always include TSIG RRs to DNS messages if there is no security in use. I will remove "usually" and will not add any other words to avoid any misinterpretations. > - In section 11.2: > > The node MUST encrypt all DNS message sections that required > protections using the secret key generated in last section and AES > symmetric algorithm. It excludes TSIG RDATA (That usually added in > the additional section of the DNS messages) from the encryption text. > > Does this mean, for example, the encrypted message contains some > encrypted data (maybe encrypted header, question, answer, authority > sections) followed by the additional section in plain text? If so, > how can we decrypt it as described in Section 11.4? Yes, with the secret key and the use of symmetric algorithm, the values that the verifier nodes can obtain from the MAC section of the TSIG RR when the algorithm type is CGA-TSIGe > The DNS server retrieves the secret key from MAC field. It then > decrypts this secret key using its own private key. > > If some or all of the preceding sections are encrypted, the > receiving server cannot even identify the location of the additional > section, where the TSGI RR is located. This can be addressed with > some minor extension, but it's not clear from the draft, and if it > wants to be an interoperable specification, such details are > crucial. The types section is not encrypted. Only the content of each section are encrypted. So for instance Type|length|reserve| no encryption but other parts encrypted except additional section I will clarify this in the new version. Thanks again, Best, Hosnieh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
