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

Peter van Dijk <peter.van.dijk@powerdns.com> Tue, 18 May 2021 09:39 UTC

Return-Path: <peter.van.dijk@powerdns.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE983A14F7; Tue, 18 May 2021 02:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pONt1GwgzoOM; Tue, 18 May 2021 02:39:21 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62643A14F5; Tue, 18 May 2021 02:39:20 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 15A806A0DF; Tue, 18 May 2021 11:39:18 +0200 (CEST)
Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id NZuKBEaLo2DoFgAA3c6Kzw (envelope-from <peter.van.dijk@powerdns.com>); Tue, 18 May 2021 11:39:18 +0200
Message-ID: <a9be56834fd99d1d65c6781000877ab2b5ebb462.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-nsec-ttl@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com
Date: Tue, 18 May 2021 11:39:17 +0200
In-Reply-To: <162126301878.6110.17012836155352242589@ietfa.amsl.com>
References: <162126301878.6110.17012836155352242589@ietfa.amsl.com>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WAh-uYLMxC9On6UExOkQ1tjVk3w>
Subject: Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 09:39:26 -0000

Hello Roman,

On Mon, 2021-05-17 at 07:50 -0700, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> 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/?

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

>   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?

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/