[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, [email protected] <[email protected]> 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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
