At Tue, 4 Mar 2014 23:49:40 +0100, "Hosnieh Rafiee" <[email protected]> wrote:
> Thanks again for your comments. I just continue answering from where I > stopped. For a higher level points, it looks like we simply have to agree to disagree. I have no particular incentive to convince you on my view (and you don't necessarily have to convince me to get the proposal adopted), so I'll only answer specific points of the draft content: > > - 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? At least "update" is very confusing to me as it can be easily confused with dynamic DNS updates. It doesn't have to be "[AI]XFR", but at least I'd avoid the word "update" in this context. > > - 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. Ah, okay. I misunderstood the meaning. > I will remove "usually" and will not add any other words to avoid any > misinterpretations. This works for me. > > - In section 11.2: [...] > > 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'm afraid I don't understand this. I don't even understand what "types section" means. Maybe a detailed format of the message to be decrypted in Section 11.4 will help. -- JINMEI, Tatuya _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
