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

[Fernando Gont <[e-mail]>]

Joe,

On 17/12/20 20:35, Joseph Touch wrote:
> 
> 
>> On Dec 14, 2020, at 9:12 PM, Fernando Gont <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Flawed IDs introduce problems. IDs that are not flawed do not.
> 
> Christian has expressed much of my position, with the exception of the 
> following:

I don't know what's his "position". Reality is that we have been 
receiving objections against our document for things that are not even 
in our document.

I've explained that the requirements are in Section 5. Reqs #1-#2 simply 
spells out that every specs should nevertheless do. Req #3, says "if 
you've found issues, just suggest an algorithm that deals with it in the 
best possible way. Perios.




> IMO - protocols MUST NOT limit how IDs are selected or used. The issue 
> isn’t the protocol spec; it’s the implementation.

Current protocol specs not only do not spell out the interoperability 
requirements, but also over-specify the generation of their IDs.


Transient numeric IDs have interoperability constraints that you must 
comply with. When implementations enforce further requirements without 
an interoperability rationale *THAT* is a protocol limiting the IDs.

What we mean is:

#1: Spell out the interop req. i.e., tell us the properties that the IDs 
must have. -- we want to know the minium requirements the IDs need to 
comply to.

#2: Analyze the possible implications of such IDs.

#3: If you found any possible issues in #2, just suggest something to 
the implementer that complies with #1 and deals gracefully with #2.


We devote to protocol specs and have produced flawed specifications in 
this respect for a long time. Why should we expect every single 
implementer to do this analysis on their own to come up with a sensible 
algorithm?




> What I want to avoid is breaking the potential for IoT devices to use 
> these protocols simply because they can’t implement the approaches 
> described here.

Fair enough. Now when picking an algorithm, you'll probably have, say, 
the best option which might be more expensive and mitigate most/all 
issues, and, say, a lightweight version that e.g. mitigates some/most 
issues.

Explain the trade-offs of which, and suggest implementers when to use 
which ("this one is most sensible for constrained devices, and this one 
is sensible for the general case"). Done.



> I also want to avoid a receiver saying “hey, sender, you picked the IDs 
> badly, so I won’t connect to you”.

That's of course sensible. And that's why we have #1.

THe only way in which you can avoid this is when the interoperability 
requirements are clear. Now when talking about some of QUIC's IDs, and 
asking for why things are done, Christian response was, essentially, 
"oh, that's in the mail archive of the tons of discussions we have had".

That approach of coming up with requirements is doom to led to both 
interoperability problem (because you don't know what to comply with for 
things to work), and security/privacy issues (because there's no 
analysis of the implications of such IDs).

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