Ben: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.I do not think the real message here is how to write security considerations regarding transient identifiers. I also agree with EKR's position.
I also think that EKR has a point.
I think there are two main issues in the document: it does not
distinguish between identifiers that are "visible on the wire" and
those that are only visible by the endpoints; and, it suggests an
overly specific identifier generation algorithm. The document also
suffers from trying to fit different kinds of protocol parameters
in a single abstract category, the "Transient Numeric Identifier".
This feels somewhat artificial.
Fixing the lack of distinction between "visible on the wire" and "visible by the end-points" would require fixing the section 3 regarding "issues". The current list of issues feels theoretical and detached from the actual attacks. It lists:
o Protocol specifications that under-specify the requirements for
their identifiers
o Protocol specifications that over-specify their identifiers
o Protocol implementations that simply fail to comply with the
specified requirements
That list of issues seems somewhat self-referential, another way
of saying "protocols that do not comply with the recommendations
in this document". If we want to provide guidance, we should
instead look at categories of attacks enabled by classic mistakes,
such as injection attacks, correlation attacks, or spoofing
attacks. That's the point at which we can make a distinction
between "visible on the wire" and not -- injection attacks,
correlation attacks and spoofing attacks by third parties are
mitigated if the identifier is not visible, but spoofing attacks
by the connected peer are not.
EKR mentions how much the document is at odd with recent practice, like the design of QUIC. QUIC does use a number of identifiers: connection identifiers, packet numbers, stream numbers, data offsets within streams. If that document had been available before the design of QUIC, would it have help development? My personal opinion is no, it would not have make the protocol better. It might have created a hurdle during the last call reviews, forcing the developers to discuss why they would not comply with the recommendation in this draft, and creating additional delays in the process for little practical result.
I don't think that the document should be published as is.
-- Christian Huitema
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
