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

Hello, Joe,

On 14/12/20 13:51, Joseph Touch wrote:
[...]
>>> +1
>>> I don’t like the idea of over-specification to provide partial 
>>> privacy or security.
>>
>> Our document says:
>>
>>   1.  Clearly specify the interoperability requirements for the
>>       aforementioned identifiers (e.g., required properties such as
>>       uniqueness, along with the failure severity if such properties
>>       are not met).
>>
>>   2.  Provide a security and privacy analysis of the aforementioned
>>       identifiers.
>>
>>   3.  Recommend an algorithm for generating the aforementioned
>>       identifiers that mitigates security and privacy issues, such as
>>       those discussed in [I-D.irtf-pearg-numeric-ids-generation].
>>
>>
>> "1" asks specifications to spell out the interoperability requirements 
>> for the IDs.
>>
>> "2" explicitly  asks specifications to do an appropriate analysis of 
>> the security and privacy implications of the IDs.
>>
>> "3" means: "based on the analysis you did in #2, recommend an 
>> algorithm that mitigates the identified issues" (i.e., "do what you 
>> need to do, in the best way you can").
> 
> #3 jumps to an algorithm.

Of course! What's the point of having every implementer do the necessary 
work to come up with an algorithm to comply with the interoperability 
implications, without causing trouble?

Haven't we learned anything from history?

Every single ID I can think of has had a flawed recommendation in a 
spec, and/or a flawed implementation:

* ephemeral port numbers
* IPv6 IIDs
* IPv4 Frag ID
* IPv6 Frag ID
* TCP sequence numbers
* DNS TID

... you name them.


It's quite surprising that given the bad record, we are even discussing 
this. --  unless there's any interest in having vulnerable specs and/or 
implementations.




> In your other post, you say that:
> 
>    "in cases where protocols require cryptographic
>     algorithms to provide confidentiality and integrity (ie.
>     authenticated encryption) of the transient identifier fields some of
>     the inherent weaknesses in transient ID generation *may* be
>     mitigated.”
> 
> MAY - really? So basically you’re comfortable recommending these 
> pseudo-obfuscation methods, but refer to cryptographic algs as MAY?

Yes, may -- as in possibility (i.e., "could", should I say?).

QUIC employs cryptographic methods. Yet the connection-IDs are not 
encrypted.  And even if they were, if an implementation were to generate 
CIDs based on e.g., a global counter, that would leak out (to the remote 
endpoint) the number of connections that have been established.

So yes, crypto does not necessarily solve all problems, as it should be 
evident.



> What it ought to say, first line of the doc, is “if your protocol 
> expects or uses cryptographic protection means, stop reading here; 
> you’re fine.”

No. IMO, it needs to say what it says: "Do the right thing, because 
there's plenty of evidence that when you don't, you'll screw up. Allways 
fail on the safe side".

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