Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG

[Daniel Borkmann <[e-mail]>]

On 08/20/2014 03:43 PM, Jacob Appelbaum wrote:
> On 8/19/14, Florian Westphal <[e-mail]> wrote:
[...]
>> - Your adversary may be able to do full passive monitoring of
>> all network traffic (also compare "replay" above), so whats the purpose
>> of "avoiding" active scans?
>
> Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC
> do active scans when their full passive monitoring isn't enough. This
> hampers that angle of information gathering. It also ensures that even
[...]

Ok, but for the majority of use cases, lets presume that you'd
pass one of these secretly hidden taps located at some cooperative
IX. Assuming the worst case that some passive adversary has access
to enough taps distributed at convenient locations, did a previous
active port scan and knows that from your machine port 22 is closed.
Later, it observes a two-way flow to port 22 to that machine and the
existence of the service is of course nevertheless revealed.

You might be able then to 'mitigate' actual access to the service
a bit, but then again 32 bit is perhaps a limited sense of 'security'.
It would also be required that machines running more than one service
have /all/ services somewhat protected by TCP stealth, otherwise an
attacker moves on with the next service as an attack vector. Again,
if also services over other transport protocols are used on the
machines (that cannot make use of TCP stealth), an attacker might
first probe for these as an easier target to get in.

Key propagation is certainly an issue I assume; you might also want
to consider to rotate them etc; large public sites most likely cannot
make use of TCP stealth, and the larger a group becomes, the more weak
points might arise (including humans) to disclose the shared secret
somehow. Then again, it might also not be worth it for pubkeys as it
would significantly increase computational complexity on the server
side and we're only talking about 32 bit ...

/offtopic here, but wouldn't it then be better to work towards full
encryption like CurveCP et al is trying to solve ...