Hello, Russ, On 14/12/20 15:34, Russ Housley wrote: [....]
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.I do not think the real message here is how to write security considerations regarding transient identifiers.
The whole point of this document is indeed to do an appropriate security assessment of transient numeric IDs that should be part of the Security Considerations section.
In general, transient numeric IDs are required to have specific properties (otherwise, we'd simply use a PRNG). Of course, these requirements constrain the extent to which an implementation may randomize the associated numeric ID.
In order to be able to do an appropriate security analysis, we first need to know what are the associated interoperability requirements that the IDs must comply to. That's the #1 thing to understand -- without these requirements being explicit, it's impossible to do an appropriate analysis (because we don't know the constraints). Given these interoperability requirements, one can do an analysis of the possible implications of these IDs (e.g., information that might leak). And given that analysis, a proper algorithm can to be suggested, and the selection can be backed with a proper analysis.
All this boils down to "We need to produce IDs with these properties. These are the possible issues that might arising from our identifiers. And we suggest to use this algorithm because, given the interoperability properties that they must have, that's the best we have been able to come up with, avoiding as many issues as possible".
The above is meant to be part of the "Security Considerations" section, and thanks to the appropriate analysis, will also result in more appropriate IDs being employed. And will also make it easier for reviewers to spot when inappropriate IDs are being employed.
Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
