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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello

On 12/14/20 1:51 PM, Joseph Touch wrote:
>> "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. 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?
> 

What pseudo obfuscation methods are you referring to?

Sorry ut specifying an algorithm for generation of IDs is not obfuscation.

As for cryptography, yes it MAY or MAY NOT help depending on the
specific protocol on which it applies, how it is applied and what
properties are supposed to be warranted by its application.

Cryptography is not magical dust that fixes everything.

> 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.”

That would be bad guidance, in this thread I've shown at least one
example of how that failed.

-ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux