On Mon, Feb 26, 2018 at 5:40 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:

I'm still really struggling with the answer for #3. Here's the current answer:

> The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs is protected by the use of TSIG resource records as described in RFC 2845. In the unlikely event the root zone were to get corrupted during transfer it is signed by DNSSEC. One of the reasons that the root zone is signed is to enable the receiver of the zone or a resource record for a root zone record to know whether such corruption has occurred. One of the good arguments for having several operators and multiple servers per operator is to enable a requesting system to get the root zone or a resource record from another source.

My issues:

- I think "protected" can give the wrong impression because the TSIG key only authenticates the identify of the client/server, and does not validate the data. While it is factually correct to say that the zone transfer utilizes TSIG, it is not quite relevant to the question that was asked.

Hi Duane and others,

I don't think this is correct. TSIG authenticates an entire DNS message using a keyed hash (specifically HMAC-MD5, HMAC-SHA256, etc) computed over the message contents and some metadata. Assuming TSIG is being used to authenticate zone transfers, then each constituent DNS message in the zone transfer will have a TSIG signature placed in the OPT TSIG record. So in fact TSIG does protect zone transfers and will be able to detect corrupted transfers or MITM'd content.

It *may* also be able to authenticate the identity of the client and server, but that depends on configuration details - for symmetric TSIG this would need distinct keys shared between client and server pairs (which generally should always be done, otherwise TSIG clients could fake zone transfers to one another). For public key (SIG0) you just need unique public key credentials per server.

- I think its misleading to imply that RSOs are performing DNSSEC validation of received zones before serving them. AFAIK none are doing that.

And it's also impossible.

Paraphrasing what I said in my earlier note in this thread, which most people seemed to have ignored: DNSSEC can't validate the *full* contents of a zone if the zone has any non-authoritative data in it. This is abundantly true for the root zone (it has many child NS sets and glue address records - those don't have DNSSEC signatures so can't be validated). Nor was DNSSEC designed to fulfill that function.

Here's what RFC 4035, Section 4 says:

4. Services Not Provided by DNS Security

[....]

The DNS security extensions provide data and origin authentication

for DNS data. The mechanisms outlined above are not designed to

protect operations such as zone transfers and dynamic update

([RFC2136], [RFC3007]). Message authentication schemes described in

[RFC2845] and [RFC2931] address security operations that pertain to

these transactions.

Shumon Huque