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

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 02 Dec 2019 23:17:15 -0800

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-serve-stale-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who put work into documenting this useful and apparently
well-deployed mechanism. I have a handful of comments on the current document.

---------------------------------------------------------------------------

§3:

>  Several recursive resolver operators, including Akamai, currently use
>  stale data for answers in some way.

This won't age well; and it's not clear why calling out Akamai amongst
the various DNS service providers is warranted. Suggest:

  At the time of this document's publication, several recursive resolver
  operators use stale data for answers in some way

(If the notion of citing Akamai is to indicate the scale of such operators,
I suggest "...operators, including large-scale operators, use stale...")

---------------------------------------------------------------------------

§4:

>  The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
>  amended to read:
>
>  TTL  a 32-bit unsigned integer number of seconds that specifies the
>     duration that the resource record MAY be cached before the source
>     of the information MUST again be consulted.  Zero values are
>     interpreted to mean that the RR can only be used for the
>     transaction in progress, and should not be cached.  Values SHOULD
>     be capped on the orders of days to weeks, with a recommended cap
>     of 604,800 seconds (seven days).  If the data is unable to be
>     authoritatively refreshed when the TTL expires, the record MAY be
>     used as though it is unexpired.  See the Section 5 and Section 6
>     sections for details.

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.

Nit: "See the Section 5 and Section 6 sections for details" is a very awkward
way to phrase the closing sentence.

More substantively: Sections 5 and 6 of RFC 1035 are "MASTER FILES" and "NAME
SERVER IMPLEMENTATION" respectively. Is this final sentence intended to refer to
those two sections? Or is it pointing to "Example Method" and "Implementation
Considerations" of this document? If the latter, please specifically cite this
document (e.g., "See Section 5 and Section 6 of [RFCXXXX] for details.")

---------------------------------------------------------------------------

§4:

>  therefor leave any previous state intact.  See Section 6 for a

Nit: "therefore"

---------------------------------------------------------------------------

§5:

>  When a request is received by a recursive resolver, it should start
>  the client response timer.

The passive tense in this sentence makes "it" linguistically ambiguous.
Suggest: "When the recursive resolver receives a request, it should start..."

---------------------------------------------------------------------------

§10:

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

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 3 Dec 2019 17:27:00 -0500

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

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Dec 2019 23:24:18 -0600

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

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

> your money. :)  That said, anyone have thoughts on how best to bring

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

/a

---

From: "J.C. Jones" <[email-masked]>
Date: Wed, 4 Dec 2019 15:54:36 -0700

All,

I think the CABForum is indeed the right mechanism to alert both CAs and
root programs to such a change, and then the root programs can include it
in their periodic notices to their included CAs -- which will then cover
all bases.

I would be happy to introduce the information to the CABForum's server
certificate mailing list, and indicate its origin of course. Alternatively,
anyone can email it to the CABForum Public List <[email-masked]>
directly and then the appropriate CABF Working Group Chair would be
responsible for forwarding it onward suitably. (Note: I'm a member of that
public list's recipients, so I could confirm it wasn't lost.) I think
either would be fine -- but if you'd like me to do the introducing, I'd
appreciate it if you could synthesize me a quick rundown of what CAs need
to know.

Cheers!
J.C.