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

Adam Roach <> Wed, 04 December 2019 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CE541200E5; Tue, 3 Dec 2019 21:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J0R0EnJAGuB9; Tue, 3 Dec 2019 21:24:28 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D2081200D5; Tue, 3 Dec 2019 21:24:28 -0800 (PST)
Received: from Svantevit.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id xB45ONP0054799 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Dec 2019 23:24:25 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1575437067; bh=rKljTu6LbcjappwAYXrviq2ydv2gllrmkTPxKTDGo7s=; h=Subject:To:References:From:Date:In-Reply-To; b=hxkUJyjMDBwjkAqX00CLv3KlG5suQH5feE3nazjL/VgTwxmx53O9NYaxEV4e24/mc fbo1UR1yw1e/mGxJHYP2B+jiMIxkonE2QYpxWjpCwlsaR61uQHBYLZp2cy+i5QlNGO GNl93LOkjJqc2wHXUKYrSvj5FLT5e5e3yELu0wbc=
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: Dave Lawrence <>, The IESG <>,,,, "J.C. Jones" <>
References: <> <>
From: Adam Roach <>
Message-ID: <>
Date: Tue, 3 Dec 2019 23:24:18 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Dec 2019 05:24:29 -0000

[JC -- note for you at the very bottom]

On 12/3/19 4:27 PM, Dave Lawrence wrote:
> 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:
> 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.)

That would be all the more reason to formally update RFC 1035 to 
incorporate RFC 2119 terminology. I'll note that this document does go 
well beyond the simple task explained in its title to do some general 
unrelated housecleaning (cf. the high-order bit of the TTL), so it seems 
to have taken exactly this kind of broad document maintenance under its 

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

I'm copying JC Jones on this mail to seek his advice on this point.