Question re prevention of enumeration with DNSSEC (NSEC3, etc.)

Sun May 8 17:48:15 UTC 2022

On Fri, May 06, 2022 at 9:18 PM, Mukund Sivaraman <muks at mukund.org> wrote:

> On Fri, May 06, 2022 at 08:58:51PM -0400, Amir Herzberg wrote:
>
> Hi NANOGers,
>
> I have a small question re DNSSEC `proof of non-existence' records: NSEC,
> NSEC3 and the (dead?) NSEC5 proposal.
>
> <begin background (probably known to all/most):> NSEC3 was motivated as a
> method to prevent Zone enumeration, then Berenstein showed its defense is
> pretty weak. RFC7129 (White Lies) prevents this enumeration attack but
> requires online signing with the zone's key, which introduces another
> vulnerability and, of course, overhead of online-signing. NSEC5 was
> proposed to prevent enumeration without online signing, so arguably more
> secure than RFC7129, but has comparable online overhead and appears `dead';
> the I-D expired (last update July'17).
>
> Note that NSEC3 also supports `opt-out', which reduces overhead for
> adoptions in domains with many non-adopting ASes, and I believe is not
> supported by NSEC.
> <end background>
>
> Questions:
> - Do you find zone enumeration a real concern?
>
> The answer to this would vary depending on who is asked, so it's not clear
> how you would use such answers. It may be a concern to some, may not be a
> concern to others.
>
> If zone enumeration was not a real concern, NSEC3 would not exist.
>

Ackchyually, that's only partly true — a significant amount of the driver
(some would say hte large majority) behind NSEC3 was that it  supports
"opt-out". This was important in very large, delegation-centric zones (e.g
like .com), where the vast majority of delegations were initially not
signed. This allows just signing the signed delegation and the holes
between them, and not all of the unsigned delegations.

This was also before things like passive DNS services existed, etc., and
the "secrecy" of a zone was viewed more as an actual thing...

>From RFC5155:
"A second problem is that the cost to cryptographically secure
   delegations to unsigned zones is high, relative to the perceived
   security benefit, in two cases: large, delegation-centric zones, and
   zones where insecure delegations will be updated rapidly.  In these
   cases, the costs of maintaining the NSEC RR chain may be extremely
   high and use of the "Opt-Out" convention may be more appropriate (for
   these unsecured zones)."

However, public DNS is a public tree and so we should have limited
> expectations for hiding names in it.
>
> - Do you think the white-lies countermeasure is sufficient and fine, or do
> you have security and/or performance concern (or just think it's
> pointless)?
> - and the final question... would you think an alternative to NSEC5 which
> will be more efficient and simpler would be of potential practical
> importance, or just a nice academic `exercise'?
>
> I'm really unsure about these questions - esp. the last one - and your
> feedback may help me decide on the importance of this line of research.
> Just fun or of possible practical importance?
>
> These questions may be better posed to the dnsop at ietf.org and
> dns-operations at dns-oarc.net mailing lists, as you'll get more relevant
> answers from people who work in the DNS industry.
>

Yes, +1, etc.!

W

> Mukund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220508/339d4b70/attachment.html>