Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Dave Lawrence <tale@dd.org> Tue, 03 December 2019 22:27 UTC

Return-Path: <tale@dd.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 7F25B12004D; Tue, 3 Dec 2019 14:27:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lIgZwYY--F2R; Tue, 3 Dec 2019 14:27:05 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9DD12003F; Tue, 3 Dec 2019 14:27:02 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id BB53CB8C62; Tue, 3 Dec 2019 17:27:00 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24038.57652.748207.835678@gro.dd.org>
Date: Tue, 3 Dec 2019 17:27:00 -0500
From: Dave Lawrence <tale@dd.org>
To: "The IESG" <iesg@ietf.org>, draft-ietf-dnsop-serve-stale@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
In-Reply-To: <157535743570.1893.17344031020923882056.idtracker@ietfa.amsl.com>
References: <157535743570.1893.17344031020923882056.idtracker@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iUjWdZlFwOXHerZacUZ8jk5HI4w>
Subject: Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (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, 03 Dec 2019 22:27:06 -0000

Thank you very much for your review, Adam.  I have incorporated your
feedback into the document (which is not yet pushed to datatracker).

Here's the diff:

https://github.com/vttale/serve-stale/commit/3ae0f4e5f79e0b326608beaa77b74a1efe62663c

Adam Roach via Datatracker writes:
> The addition of what I must presume is intended to be RFC 2119
> language to a document that doesn't cite RFC 2119 seems
> questionable.  I would suggest either explicitly adding RFC 2119
> boilerplate to RFC 1035 as part of this update, or using plain
> English language to convey the same concepts as are intended.

I definitely agree it is questionable, and if something needs to be
done to resolve this then your first suggestion is the one that is
more agreeable to me personally, but I can also see how that too is
questionable and might get some pushback.  It's a bit of a weird
situation. 

It is perhaps worth noting that several other RFCs that have updated
1035, starting with 3658, have already used 2119 normative keywords.
So in spirit it's already there, just not with an explicit remark in
any of the that formally puts the boilerplate on 1035 itself.  (And,
in the end, that means 1035 is a weird hodge-podge of old world and new.)

> >  A proposed mitigation is that certificate authorities
> >  should fully look up each name starting at the DNS root for every
> >  name lookup.  Alternatively, CAs should use a resolver that is not
> >  serving stale data.
> 
> This seems like a perfectly good solution, although I wonder how
> many CAs are likely to read this document. If I were the type to
> engage in wagering, I'd put all of my money on "zero." I'm not sure
> specific action is called for prior to publication of this document
> as an RFC, but it seems that additional publicity of this issue and
> the way that serve-stale interacts with it -- e.g., to CAB Forum and
> its members -- is warranted.

Completely agree, except to the point that if it were known that there
was money riding on it then someone at a CA would read it just to take
your money. :)  That said, anyone have thoughts on how best to bring
it to their attention?