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. - At least to me, the traditional TSIG would be sufficient to protect zone transfers. Usually we expect cooperation between primary and secondary servers (they are often even the same administrator), so it doesn't have to be public key based mechanism. - To protect dynamic updates, my general understanding is that the major barrier is not the underlying authentication mechanism but that many server administrators simply don't want to allow their clients to update the zone. When the administrator can accept that operation, and it's only for AAAA or PTR, I guess they would even accept weaker but more easier to use mechanisms such as BIND 9's "tcp-self" update-policy (yes, this is a hack and not really secure for security purists, but doesn't require any protocol modification). - To protect query/response exchanges between a stub and a recursive server, cga-tsig still requires some manual setup, whether it's a public key/certificate of the router or DHCPv6 server, or manual installation of the recursive server address (see the email thread). Then it doesn't seem to be very advantageous compared to SIG(0). - For confidentiality, CGA-TSIGe may or may not be a better approach than other known candidate solutions (I've simply not fully understood all pros and cons among the possible solutions). One thing I've noticed is that if the server's public key is published in the form of DNSKEY, we might simply use the DNSSEC infrastructure to validate the key (I understand the corresponding zone may not always be signed and/or possible to validate). There may be some specific niche cases where cga-tsig is really advantageous than other alternatives, but as a general mechanism it doesn't seem to be attractive enough to justify the introduction of new protocol and the disadvantage of not supporting IPv4. Some specific comments on the draft: - 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. - 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. - 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. - 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? 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. -- JINMEI, Tatuya _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
