Re: [PATCH] TCP: add option for silent port knocking with integrityprotection

[Jacob Appelbaum]

Christian Grothoff:
> On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
>> I think that generally, I would prefer if the code didn't use MD5 but
>> otherwise, I don't see any real risk of adding an exploitable hole. It
>> seems silly to disable it by default though - ideally, I'd like a sysctl
>> to ensure that Tor could use this without making the user recompile
>> their kernel. That is more of a pain than running a userspace helper, I
>> think.
>>
>> All the best,
>> Jacob
> 
> Given that the output is truncated to 32 bits and that performance (SYN
> flood) is also a concern, AND that the original TCP SQN generation is
> also MD5-based (and we want to look the same), what disadvantage do you
> see over MD5?  Given the truncation to 32 bits, I don't think a stronger
> hash would do anything for us.

If we believe that MD5 is not secure, we should not use it. That others
use it is not a strong reason to use it. Everyone should stop using MD5
- especially truncated MD5. :)

> 
> As for it being disabled by default, we did this with respect to
> kernel submission guidelines which we understood said that features
> should _initially_ always be submitted with disabled-by-default
> (presumably so that until they have stabilized, nobody is harmed
> unless they explicitly activate the code).
> 

I think that is a fine reason at submission time but this should not be
the default state for very long.

> I don't see the point in having a sysctl, as applications have to
> explicitly request it anyway.

To have it supported and to have it enabled in the kernel are not
exactly the same thing. It would be nice if it was available to everyone
by default (likely with some CAP) and to enable it on a systemwide
basis, one could simply flip a sysctl. One also needs to use it in an
application, obviously.

All the best,
Jacob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/