Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

Stephane Bortzmeyer <bortzmeyer@nic.fr> Sat, 14 September 2019 12:33 UTC

Return-Path: <stephane@sources.org>
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 2CDE812008A; Sat, 14 Sep 2019 05:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 pFrEYc7aYfWP; Sat, 14 Sep 2019 05:33:09 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 8D5DC120077; Sat, 14 Sep 2019 05:33:09 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id B40B3A052F; Sat, 14 Sep 2019 14:33:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 949341908BD; Sat, 14 Sep 2019 14:29:18 +0200 (CEST)
Date: Sat, 14 Sep 2019 14:29:18 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Barry Leiba <barryleiba@computer.org>
Cc: draft-ietf-dnsop-serve-stale.all@ietf.org, dnsop@ietf.org
Message-ID: <20190914122918.oqgl22xzbegajlhw@sources.org>
References: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.9
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0jyt_gRtQ8g8zsr-JPa_ILOZHnE>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07
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: Sat, 14 Sep 2019 12:33:13 -0000

On Wed, Sep 11, 2019 at 12:06:23PM -0400,
 Barry Leiba <barryleiba@computer.org>; wrote 
 a message of 75 lines which said:

> I wonder if it makes sense to be more explicit here that one isn’t
> meant to keep using expired data forever, but is expected to keep
> trying to refresh it.  So, maybe?:
> 
> NEW
>       If the data is unable to be
>       authoritatively refreshed when the TTL expires, the record MAY be
>       used as though it is unexpired until an authoritative refresh is
>       successful.
> END

I think your proposed text is worse since it contradicts the current
draft, which limits the time during which you can serve stale answers
"The maximum stale timer should be configurable, and defines the
length of time after a record expires that it should be retained in
the cache.  The suggested value is between 1 and 3 days. [Even if you
cannot contact the authoritative servers, my note.]"

> Is another possible new security consideration that bad actors could
> DDoS authoritative servers with the explicit intent of having stale
> cached information used for longer, perhaps to extend the life of a
> cache-poisoning attack or some such?

Yes, seems right. Also reported by Viktor Dukhovni during the last
call. May be add at the end of section 10 "Attackers could be incited
to dDoS authoritative servers with the explicit intent of having stale
cached information used for longer. But if they have this capacity,
they probably could do much worse things than prolongating old data."