Hiya,

This list would be ok I guess though a thread has been
started on tcpinc and tcpm. I suspect that tcpm is
probably the best overall, as its there where the folks
who'd be best able to comment would be found I think.

S.


On 18/08/14 14:15, 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,
>  [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
> 
> 

_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to