[rssac-caucus] FOR REVIEW: RSSAC FAQ

[Warren Kumari]

On Mon, Feb 26, 2018 at 7:12 PM, Wessels, Duane via rssac-caucus
<rssac-caucus at icann.org> wrote:
>
>> On Feb 26, 2018, at 3:57 PM, Shumon Huque <shuque at gmail.com> wrote:
>>
>>
>> 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.
>
> Ah, thanks for clarifying that.  I should've read the TSIG RFC more carefully.  I withdraw my objection to "protected"!
>
> another attempt:
>
> The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs occurs via the DNS zone transfer protocols (AXFR in RFC 5936 and IXFR in RFC 1995).  These zone transfer messages are protected by the use of TSIG resource records as described in RFC 2845. This is a reliable protocol and we are not aware of any incidents of data corruption.  Furthermore, since the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators.  RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.
>
>

Looks good to me. I still think that we should s/of TSIG resource
records/of TSIG/ -- TSIG uses RRs, but they are hidden, and I'm
concerned someone will go digging for them -- but, I don't really
care.
W

>> 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.
>
> Yes, agreed.  I did gloss over that point.
>
> DW
>
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf