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

[Stephane Bortzmeyer <[e-mail]>]

[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). 

* "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"?

* May be a security analysis comparing it to port knocking? 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).

* 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.)

* 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?

* "6. Integraton with Applications" should be Integration