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

Barry Leiba <barryleiba@computer.org> Sat, 14 September 2019 12:46 UTC

Return-Path: <barryleiba@gmail.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 04A0812008A; Sat, 14 Sep 2019 05:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.923
X-Spam-Level:
X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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 cmbTARJbfn4z; Sat, 14 Sep 2019 05:46:25 -0700 (PDT)
Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E02B120077; Sat, 14 Sep 2019 05:46:25 -0700 (PDT)
Received: by mail-io1-f67.google.com with SMTP id b19so8650067iob.4; Sat, 14 Sep 2019 05:46:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+E69Afo/C5Fna+Dg3G82u9sFqwXw3zoNQprJxZoK900=; b=Ra/u9AKAmf+msj4bWr2LlXfEUMlMx4oO6Rp6y2U4ywalmGJnEhSQ4nJmp27s1TknX7 s5UaxsB7V5dDnoGMbuUrk9nePenzJW1hTrjnpU1BtSekVU7sL7kQAYk8A+WXK43x0+dx no4wB7UCgMF7LmkiChCume3gzdqkvxqsgRepsImkcExPxNc4V0ls2F5VRG0M6CSTIjAy 0mb5GASMKr1+l4wjX3lCmhggQm4Yv7S37hUiXBS8LSIO0zDXNne4xlYM6B53JYZLExof fl5JpIRni2udhI+arLO4XsQ4Skpid0xkhJJhiWo+2mhZvAnzK6BZn3uR044NPyQ7qmiB 7V6Q==
X-Gm-Message-State: APjAAAUQWJoeqXvPNLFSP8LXuoyvNppyusJ4MlrsxIye2sSP33rx+rZs K8w76/2CqD1WGrzypa3lqAJAf9xRg68CqBi0Z+I=
X-Google-Smtp-Source: APXvYqxsu/LhazgwaJ3LnlDZQx5nlGz2L4bT6+d9PSo3oXXLbs5LfHS2rDPYtnNf5T/FPflZE1Hbfot9JEI7JlhjJTM=
X-Received: by 2002:a6b:7709:: with SMTP id n9mr5785933iom.187.1568465184543; Sat, 14 Sep 2019 05:46:24 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com> <20190914122918.oqgl22xzbegajlhw@sources.org>
In-Reply-To: <20190914122918.oqgl22xzbegajlhw@sources.org>
From: Barry Leiba <barryleiba@computer.org>
Date: Sat, 14 Sep 2019 08:46:12 -0400
Message-ID: <CALaySJ+x2vMW3R0m+PES-BjqrPQ-wuZWfFO2nrnME-uxHzHptQ@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: draft-ietf-dnsop-serve-stale.all@ietf.org, dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BruyoEkx22-mygRJyrVMHRoSfZ0>
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:46:27 -0000

> > 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.]"

Yes, true.  So maybe add "for a period of time or" before "until" in
my suggestion.  Or see if you can come up with better wording.  If you
really think it doesn't need to be qualified here because the rest of
the document takes care of it, I won't push it further.  I just think
it best to say *something* here that doesn't make it sound like an
entirely open-ended "MAY".

> > 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."

Other than that "prolongating" isn't a word (use "prolonging the life
of"), that's probably OK.  Maybe add that the benefit outweighs the
risk, or some such, and then we'll see what the Sec ADs think.

Barry


Barry