Re: [secdir] Secdir review of draft-ietf-tsvwg-port-randomization-06.txt

[Fernando Gont <[e-mail]>]

Hello, Charlie,

Thanks so much for your feedback! Comments in-line....


> Detailed security-relevant comments:
> 
> p13 para 2: says random must return integers in the range 0 - (2^n-1)
> where n>15. Larger values of n (e.g. n=31) are preferred, since
> otherwise distribution when reduced mod num_ephemeral will not be
> uniform.

Would requiring random() to return 32-bit random values address this
comment?



> p16 para 2: suggests use of MD5, which is fine from the point of view
> of documenting current practice, and in fact is cryptographically
> just fine in this context. 
> Nevertheless, crypto weenies the world
> over will pounce on you if it looks like you're suggesting that
> people use it. It's probably better to just suggest "some
> cryptographic hash function", or if you have to suggest something
> specific, perhaps SHA-256. 

My take on this is that as we're just obfuscating port numbers, MD5 is
good enough. But please let me know if you argue that we should
s/MD5/SHA-256/.....



> The appendix at the end should specify the
> hash algorithm used by existing implementations.

You mean Appendix A? If so, we could probably just indicate that Linux
uses MD5 for the hash-based port randomization algorithm.


> Your sample code in many cases, but in particular on page 17 figure 5
> ignores the possibility of integer overflow when incrementing things
> (e.g. table[index]++). The results of modular arithmetic when one of
> the operands is negative is language dependent, and in ANSI C is not
> defined, so this code could corrupt memory (unless the values being
> incremented are unsigned).

All operands are assumed to be unsigned. Please let me know if I should
clarify this.



> p20 para 2: suggests use of a 32 bit key, which has exploitable
> security problems even though MD5 is fine. 64 bits is a bare minimum,
> and since bits are cheap someone should really use 128.

Ok, I'll s/32/128/



> p24 para 3: Since the local offset function is a cryptographic hash
> reduced to a small number of bits, there will be identical offsets
> for different inputs and they are generally harmless. If they
> occurred at greater frequency than would be expected by chance, the
> port-offset mechanism proposed in this document would have a reduced
> effect.

Ok. I'll tweak the text.



> p24 para 4: Similarly, seeding the random number generator with a
> good  source of randomness will make an implementation more secure,
> but "must" is a bit strong.

Not sure what you mean. This para just refers to the quality of random
numbers. i.e., that if your going to use only random numbers for the
secret key, they should be "good enough" (with "good enough" being RFC4086)



> Detailed non-security relevant comments:
> 
> The document is titled "Transport Protocol Port Randomization
> Recommendations", but it doesn't really make recommendations. It
> enumerates current practice and calls out the pros and cons, but it
> doesn't really recommend what an implementer should do. That's
> probably OK, but it seemed a bit odd.

How about "Transport Protocol Port Randomization", instead?



> p6 last para section 1: Given that this document never uses SHOULD,
> MUST, ... outside of this paragraph, does it really need this
> paragraph and the reference to RFC 2119?

It does. See Section 3.2 and Section 3.3.




> p7 end of section 2.1 says ports in the range 49152-65535 are meant
> for the selection of ephemeral ports p12 1st para says:  "ephemeral
> port selection algorithms should use the whole range 1024-49151". Is
> this saying you should use port numbers not intended for this use? Do
> you mean should use the whole range 1024-65535?

The later: the text should say "...port selection algorithms should use
the whole range 1024-49151" (I screwed up the text in my last rev....
will fix this).


> 
> Typos:
> 
> p12 line 2: "is not affected is not affected" -> "is not affected" 

Fixed.


> p13 para 2 line 2: "interger" -> "integer" p16 para 3: "chosen as
> random as possible" -> "chosen to be as random as possible" p20 para
> 3: "reasonable" -> "reasonably"

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1