[rssac-caucus] FOR REVIEW: RSSAC FAQ

[Shumon Huque]

On Mon, Feb 26, 2018 at 5:40 PM, Wessels, Duane via rssac-caucus <
rssac-caucus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20180226/5d24a169/attachment.html>