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

[Adam Roach <[e-mail]>]

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


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.


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

/a