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

tcpinc is probably another candiate to discuss this ID.

On 18 August 2014 15:49, Christian Grothoff <grothoff@gnunet.org> wrote:
> 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,
>>  internet-drafts@ietf.org <internet-drafts@ietf.org> 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
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>