Re: [perpass] TCP Stealth (Was: I-D Action: draft-kirsch-ietf-tcp-stealth-00.txt

[Christian Grothoff <[e-mail]>]

On 08/18/2014 03:15 PM, Stephane Bortzmeyer wrote:
> [The I-D does not indicate, apparently, a mailing list for discussion
> of the idea. Trying on perpass. Suggestions of a better venue are
> welcome.]
> 
> On Thu, Aug 14, 2014 at 11:41:06PM -0700,
>  [e-mail] <[e-mail]> wrote 
>  a message of 49 lines which said:
> 
>>         Title           : TCP Stealth
>>         Authors         : Julian Kirsch
>>                           Christian Grothoff
>>                           Jacob Appelbaum
>>                           Holger Kenn
>> 	Filename        : draft-kirsch-ietf-tcp-stealth-00.txt
> 
> IMHO, very good idea for an important problem. I would like this
> work to move forward (an independant RFC with status Experimental, may
> be?)
> 
> A few suggestions/remarks:
> 
> * May be a remark about the fact that it is intended for small groups
> (the use of a shared secret limits the scalability). 

That is of course correct.

> * "If the token is incorrect, the operating system pretends that the
> port is closed." If the port is closed, the server will reply with a
> RST. Not very stealth. You meant "If the token is incorrect, the
> operating system won't reply at all"?

We intend the OS to react in the same way as it does for all other ports
where no service is listening.  If the OS policy is to send a RST, it
should also send a RST if the authentication fails If the OS policy is
to drop, it should also drop if the authentication fails.  Stealth here
is about being as indistinguishable as possible from an "ordinary"
closed port.

> * May be a security analysis comparing it to port knocking? 

Eh, this is a port knocking scheme.

> If I'm
> correct, TCP stealth provides min(32, N) bits of secret (32 being the
> size of the ISN and N the number of bits in the shared secret) while
> port knocking provides 16*N bits (N being the number of ports to
> knock).

That depends on the type of port knocking scheme deployed. You could in
theory implement a knock with a 512 byte UDP packet and have a huge
shared secret.  Naturally, if you talk about a knock where just the
destination port is derived from the knock secret, then your analysis is
correct.  But again, there are many ways to implement knocking in general.

> * May be a mention of SPA <http://www.cipherdyne.org/fwknop/>, which
> is closer from TCP Stealth than port-knocking? (The biggest difference
> is that SPA is not stealth, Eve knows you're using SPA.)

There are other differences; for a more detailed analysis I would
suggest you use Julian's Master's thesis, not the RFC. The MS thesis is
freely available at https://gnunet.org/kirsch2014knock

> * Why MD5? I assume that TCP Stealth has no cryptographic agility
> since there is no room to indicate the crypto algorithm (while staying
> stealth) but why MD5, despite RFC 6151?

As (I hope) the thesis explains, MD5 is used for ISN calculations
already, from ISN to SYN flooding protections.  And once reduced to 32
bits, there is no real security advantage of other hash functions, but
there is a speed (and maybe indistinguishability advantage) for MD5.

> * "6. Integraton with Applications" should be Integration

Ack. Fixed in Git, thanks!

-Christian