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

[Christian Huitema <[e-mail]>]

On 12/14/2020 10:34 AM, Russ Housley wrote:
> 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