Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice

[Benjamin Kaduk <[e-mail]>]

Hi Russ,

On Fri, Dec 11, 2020 at 11:52:43AM -0500, Russ Housley wrote:
> Fernando:
> 
> >>> On Wed, Dec 09, 2020 at 04:09:07PM -0500, Russ Housley wrote:
> >>>> I have to comments.
> >>>> 
> >>>> 1) I do not see this document as a BCP.  Despite the inclusion of the boilerplate, there is not a single MUST in the document.  I have no objection to an Informational RFC.
> >>> 
> >>> The assumption/expectation was that this would become part of BCP 72 along
> >>> with RFC 3552.  Do you think it should be a standalone document, or can you
> >>> propose normative language that would make it more appropriate as a BCP?
> >> I'd advise an Informational document. 
> > 
> > FWIW, our intent is to have a BCP document that is part of (i.e., updates) BCP72.  Given that flawed transient identifiers have plagued most IETF protocols we can think of, we believe the topic deserves a BCP.
> > 
> > 
> >> I think an additional section with normative text would be needed or additional normative paragraphs after each of the problem descriptions would be needed.
> > 
> > Could you please elaborate?
> 
> It is not a Best Current Practice if the document does not provide MUST and SHOULD statements for implementers to follow.
> 
> The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.

RFC 3552 is pretty sparing with normative language, with most of the key
requirements living in its Section 5 ("Writing Security Considerations
Sections"), which boil down to "you are obligated to accurately depict the
security properties of your protocol, and here are a list of specific
things that are extra-mandatory to consider".  However, RFC 3552 also has a
substantial list of "Common Issues" in its Section 4 and subsections.  My
question to you, is what mechanism(s) you would consider appropriate to add
to the list of "Common Issues".  I think it's pretty clear that a full-on
"bis" document should be able to add to (or or remove from, I suppose) the
list, but what else?  Please consider that as a separate question from
whether these issues would merit inclusion in the RFC 3552 §5 list of
mandatory-to-consider topics -- we may well need to consider that question
as well, in the course of this IETF LC, but I would prefer to hear answers
to the first question at this point.

Thanks,

Ben