[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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
