Subject: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 17 May 2021 07:50:18 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-nsec-ttl-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank to Tiru Reddy for the SECDIR review.

Section 5.  Per:

An attacker can prevent future records from appearing in a cache by
   seeding the cache with queries that cause NSEC or NSEC3 responses to
   be cached, for aggressive use purposes.  This document reduces the
   impact of that attack in cases where the NSEC or NSEC3 TTL is higher
   than the zone operator intended.

Shouldn’t this text read s/An attacker can prevent future records/An attacker
can delay future records/?  Per Section 9 of RFC8198, “If the resolver is
making aggressive use of NSEC/NSEC3, one successful attack would be able to
suppress many queries for new names, up to the negative TTL."  If the timing is
right, this delay could be indefinite.  Isn't the mitigation provided here that
the attacker needs to seed the cache more often?

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 18 May 2021 11:39:17 +0200

Hello Roman,

On Mon, 2021-05-17 at 07:50 -0700, Roman Danyliw via Datatracker wrote:
> can delay future records/?

That's right, it should read that. I have updated my local copy.

>   Per Section 9 of RFC8198, “If the resolver is

The delay is never indefinite. The mitigation provided here is that the limit to that delay is lowered, and indeed also, that the attacker might need to seed more often to implement the attack at all.

Thanks!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/