[RSSAC Caucus] Metrics: Correctness of data

[Fred Baker]

I'm happy enough to use your draft. I haven't read it yet, but one hopes it will have no shortage of review.

I do see a threat in services acting as RSOs - whether recognized and in the root hints or not - delivering data that is unsigned or signed by another party. We know that it's happening right now, and it's pretty basic to root service.

> On Jul 25, 2019, at 11:34 AM, Wessels, Duane <dwessels at verisign.com> wrote:
> 
> Hi Fred,
> 
> I have a couple of comments.
> 
> The "Who is answering my queries" research is indeed interesting.  It focuses on interception between stub and recursive, and looks only at large recursive providers.  I don't think we should draw the conclusion that the level of interception observed there (10-30%) also exists in the recursive-to-authoritative path.
> 
> What you propose with respect to checksum sounds an awful lot like the zone message digest internet draft (aka ZONEMD) that I and others have been working on.  https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-00.  
> 
> As envisioned in the ZONEMD draft, a name server would verify the digest before loading the zone for service.  If I understand your proposal correctly, you're thinking more along the lines of calculating the digest on demand when it is queried for.  I suppose we'd have to have a conversation with operators and implementors if they wanted to incur the CPU hit for that. 
> 
> IMO such checks could alert us to unwanted changes made by malicious third parties.  However, if an RSO itself desired to serve incorrect data then it could do so while still providing good checksums.  I'm not sure there is a reasonable way to catch those, and I don't think this work party should try to do so at this time.
> 
> DW
> 
> 
> 
> 
>> On Jul 23, 2019, at 7:06 PM, Fred Baker <fred at isc.org> wrote:
>> 
>> On Jul 22, 2019, at 1:46 AM, Fred Baker <fred at isc.org> wrote:
>>> I think there may also be value in proving that the RSO in question delivers *all* of the resource records that IANA includes in a zone transfer, and that it delivers *only* the resource records that the IANA would include in a zone transfer.
>> 
>> Let me follow up on this. I'm looking at two reports:
>> 
>> https://dl.acm.org/authorize.cfm?key=N687421 from https://irtf.org/anrw/2019/program.html
>> 
>> Reports in the DoH space about downloading the IANA zone and distributing it in that fashion, and the service also being used to store TXT records used by botnets (https://www.bleepingcomputer.com/news/security/new-spam-campaign-controlled-by-attackers-via-dns-txt-records/). 
>> 
>> The first is not quite an assertion that it is known that DNS requests and/or responses are being changed in flight, but it states that the researchers in question had a "large" service to test against that was doing that. DNSSEC is probably the proper test for that - data changes in flight would no longer have a valid DNSSEC signature.
>> 
>> The second reports that the Google DOH server is being used as a repository and server for TXT records controlling botnets. I'm certain that Google would immediately respond that it is not their intention to support that. That said, there is evidence that it is in fact the case.
>> 
>> A relatively simple solution to that might be to take a note out of the OSPF MIB, which reports a checksum the LSA Database. I imagine that a DNS server might hold more than one zone, and *a* zone that it holds might be the TXT records in question. But when a DNS Server is queried, the request doesn't specify a zone; it merely asks whether the server has a resource record for the indicated name. So I find myself thinking of something a little more complicated than a statement regarding the root zone. Imagine:
>> 
>>  A response listing the zones stored at the server (presumably attained by an XFR), 
>>  and for each such zone, 
>>       The relevant sequence number,
>>       the number of RRs held, and 
>>       an MD5 checksum of those RRs. 
>>  For the purposes of the checksum, the TTL in each record needs to be zeroed.
>> 
>> The probe can now ask for that table and compare it to what it believes to be correct. It could also contain the sequence number of the dataset transferred in the XFR.
>> 
>> Like the OSPF LSA Database, this should at least in theory be a quick and almost null check - "do you have the right answer? OK, yup". However, in the unusual case that the answer is incorrect we can know quickly and without a lot of doubt.
>> 
>> If there is support for that, I'd be happy to sketch text into the Google Doc.
>> _______________________________________________
>> rssac-caucus mailing list
>> rssac-caucus at icann.org
>> https://mm.icann.org/mailman/listinfo/rssac-caucus
>> 
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>