Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Anders Kaseorg <andersk@mit.edu>]

I just ran into this timeout behavior myself while testing the new 
DNSSEC support in OpenWrt 14.07 (dnsmasq 2.71-4).  After staring at the 
problem for a few hours, I think there’s something wrong with your 
justification.

On 04/29/2014 09:22 AM, Simon Kelley wrote:
> To do that, we need to find proof (NSEC or NSEC3 records) that a DS
> doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in
> mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it
> doesn't know where the zone cuts are.
>
> The current strategy it to start at ds.test-ipv6.com and do DS queries.
> There are three possible results.
>
> unsigned NOERROR -> chop one label off the RHS and repeat
> DS record        -> definite Bad Guy activity, return BOGUS
> signed no DS record -> we expect unsigned original answer, return
> INSECURE result.ds.test-ipv6.com

This bottom-up algorithm also seems to have a security problem that’s 
just as bad as one with the top-down algorithm that you rejected below. 
  Consider the same department.campus.university.edu example, where 
campus and edu are signed zones, and university is not a zone.

• An attacker forges an evil response for A department, and forges an 
unsigned NODATA for DS department.
• dnsmasq chops off one label, and the attacker forges an unsigned 
NODATA for DS campus.
• dnsmasq chops off another label, and gets the legitimately signed 
NODATA for DS university.
• dnsmasq incorrectly concludes that everything inside university is 
expected to be unsigned, and returns the INSECURE evil response.

So if nothing else, the top-down algorithm seems less impractical and 
equally insecure.  And maybe we can fix it; see below.

> The other alternative approach is to start from the root and add labels,
> but that has a problem.
>
> Consider
>
> department.campus.university.edu
>
> where there are zone cuts between university and edu and between
> department and campus.
>
> All the zones are signed, so if we look up something under .department,
> we expect a signature, if we don't get it, we check
>
> DS .edu gives an answer
> DS university.edu gives secure NODATA
>
> secure no DS means that the original unsigned answer should be accepted,
> except that it shouldn't. There's no way to distinguish between secure
> lack of DS because we've reached an unsigned branch of the tree, and
> secure lack of DS because we're not at a zone cut, except if we know
> where the zone cuts are, and we don't.

Having just looked through RFC 5155 for clues: isn’t that the purpose of 
the NS type bit in the NSEC3 record?  In this example, DS university 
would give an NSEC3 record with the NS bit clear.  That signals that we 
should go down a level and query DS campus.  In this case we find a 
signed DS there.  But if we were to find an NSEC3 with the NS bit set, 
then we’d know that we’ve really found an unsigned zone and can stop 
going down.

Anders