Subject: 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

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Jan 2021 07:10:40 -0300

Paul,

On 31/12/20 14:42, Paul Wouters wrote:
> 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.

Do I need to repeat the list of sample flawed IDs from that 
draft-irtf-pearg-numeric-ids-history-04?

* Predictable TCP ISNs -> NOT IPv6 related
* Predictable transport protocol ephemeral ports -> NOT IPv6 related
* Predictable IPv4 Fragment Identification -> NOT IPv6 related
* Predictable DNS TxIDs -> NOT IPv6 related
* Flawed NTP REF-IDs -> NOT IPv6 related

And one could also add TCP timestamps and others to the list.

So, may I ask, once again, that you read tour I-Ds -- and if you did 
read them, that you read them again?

I don't think it helps this discussion if you make claims that one can 
easily refute by reading the document.

P.S.: And no, if you read our documents, it should be obvious that our 
documents have nothing to do with "compliant tests" for implementers, 
but rather with advice for protocol spec authors such that they produce 
a proper assessment of their transient numeric identifiers.

Happy New Year!

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Jan 2021 07:51:39 -0300

On 31/12/20 14:42, Paul Wouters wrote:
>> 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.

I have no idea how, if you did read the document, you can state that our 
document is the equivalent of "please be careful", when it has explicit 
and straightforward requirements for protocol spec authors:

  * Our document targets protocol spec authors, not protocol
    implementers (for instance, RFC3552 targets spec authors)

Our documents tries to get protocol spec authors to do an appropriate
specification and security assessment of the transient numeric
identifiers they employ.

If the resulting specs are better, so will your code. Or at the very
least, it will be pretty evident how/where you screwed up.

  * This document specifies requirements for the assessment of transient
    numeric identifiers. Protocol spec authors are expected to be aware
    about them (that's part of the point of formally updating RFC3552).

This way, if a spec is being progressed without a proper analysis, one
would expect that the wg or responsible AD will quickly spot flawed
numeric IDs, and point them to a document that explains what is expected
from the spec -- with the companion documents providing further details
and examples on how to do it.

In the worst case scenario, the Security AD can spot the problem during
IESG review, and point to this document, with guidance on the topic.

The earlier in the process flaws are spotted and fixed, the better (in 
so many different dimensions).

The end result is that the resulting protocol specifications will:

1) Spell out the interop requirements for their numeric IDs. -- so you 
(implementer) won't have to second-guess them.

2) have an appropriate vulnerability assessment of the
associated IDs

3) suggest an algorithm that you (implementer) can employ to generate 
the numeric IDs, in a way that they comply with the interoperability 
requirements in #1, while mitigating the issues found in #2 (if any).

The goal is to result in better protocol specifications, which in turn
will lead into better implementations.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Jan 2021 08:03:48 -0300

[....]
>> 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.

I believe he has been quite explicit.

The OpenBSD crew had to figure out (and fix!) flawed numeric IDs for 
many different protocols, on their own, because the protocol 
specifications that we (IETF) shipped were flawed in that respect. Doing 
so not only has taken them a lot of time and effort, but has also been 
non-trivial. This eventually had to be done independently by developers 
of different operating systems, and in same cases, choices made to fix 
the flaws led to interoperability issues.

So it's not hard to follow Theo when, given a very long history of 
flawed numeric IDs in our specs, when there's finally some effort to 
improve that, there's push-back from some folks on the basis of:

* Objecting things that are not part of our document (!)

* Arguing that since there's a spec coming that fails to follow our
   advice, the right thing to do is to shoot down the advice, rather than
   fixing the spec that has problems.

In your email, you claimed "It is [..] a really low bar that we should 
be already meeting at the IETF in general at this point."
Clearly, that bar has not been met, and is not being met. So this 
document tries to be as explicit as possible recommending protocol specs 
authors to meet that bar, and how to do it, such that we stop repeating 
the same mistakes over and over again.

Thanks,