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

[Paul Wouters <[e-mail]>]

On Tue, 29 Dec 2020, Fernando Gont wrote:

> So I certainly agree that this is "a really low bar that we  should be 
> already meeting at the IETF in general at this point", and probably also that 
> "It is obvious to those who care".
>
> But then, may I ask:
>
> 1) How you explain the timelines in 
> https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-04 ?


It seems the tail of the last 15 years all refer to IPv6, so perhaps
that area needs to write up a specific document that allows implementors
to verify their implementation's use of numeric identifiers. That is,
explicitly list the fields and how to safely generate them.

> 2) How do you explain that a preliminar inspection of the core QUIC spec also 
> fails in this regard? (e.g., connection-IDs)

Do you think publishing this document will change how the QUIC working
group will act in the future? I am sceptical.

> 3) What the "controversy" is all about?

That I'm a little confused about too. I don't follow Theo de Raadt's
reasoning of the end of the world. Before I read the draft, I was
expecting people to object to certain avoiding of random fields because
those are abused for privacy reasons (eg user tracking) but I found
none of that in the actual draft documents.

> Is it that nobody cares? Is it that the topic is not that obvious? Anything 
> else?

I can only speak for myself. I found the document in question to
basically say the equivalent of "please be careful", and that is not
very useful to me as implementor. I cannot go and check my code after
reading the draft, and I dont really feel that writing new drafts would
be affected by having read this document. That is why I say that this
low bar is kind of already met. If we are not meeting this low bar,
adding a new draft document isn't going to change this either.

>>  Section 5 bullet 3 points to another document. It is almost as if bullet
>>  point 1 and 2 could be part of the introduction there.
>>
>>  Once you do these two things, this draft is basically scaffolding
>>  without content.
>
> Please do read the document.

I had :P I might have confused reading the mentioning of hash algorithms
between the three related documents. I had read all three.

> And, indeed, many flaws have to do with protocol specs over-specifying their 
> transient numeric IDs. And the reader/reviewer somehow needs to assume that 
> there's a reason for which the spec specifies the IDs in the way it does, 
> instead of quickly realizing that the spec is over-specifying its transient 
> numeric IDs.

I find the word over-specifying a bit strange. If it is specified in the
RFC, you have to do it to interop or to get the at-the-time deemed
required security. Implementors should not think "Is this over-specified?"
If there is an error in the spec, a new RFC should update the current
RFC and fix it. If everyone starts second guessing over-specification,
then we are doing more harm than good by ending up with non-compliant
and non-interoperating implementations.

> And item #3 *of course* points to another document! -- Because we don't 
> require you to pick any of the algorithms in 
> https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation

Sure. I am not saying it is wrong. I am just saying there isn't much
content in this draft compared to all the boilerplate. Which makes me
think this document's little content could be better split over the
other two documents.

> It's puzzles me that you portray this document as doing lot of handwaving. 
> Because what's in this document is essentially the process that I followed to 
> improve e.g. IPv6 stable IIDs (RFC7217), TCP sequence numbers (RFC6528), 
> transport protocol ephemeral ports (RFC6056), IPv6 Frag IDs (RFC7739), and 
> IPv6 temporary IIDs (rfc4941bis).

I guess we have a difference audience in mind. You seem to be targetting
IETF draft authors, while I'm thinking of implementors.

Paul