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

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Aug 2014 15:15:12 +0200

[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-masked] <[email-masked]> 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Aug 2014 14:20:16 +0100

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

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 18 Aug 2014 15:49:15 +0200

> (the use of a shared secret limits the scalability). 

That is of course correct.

> 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

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.

> 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

> 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

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 18 Aug 2014 15:56:03 +0200

tcpinc is probably another candiate to discuss this ID.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Aug 2014 15:56:07 +0200

On Mon, Aug 18, 2014 at 03:49:15PM +0200,
 Christian Grothoff <[email-masked]> wrote 

> Eh, this is a port knocking scheme.

You don't knock a single port and you still call it "port knocking"?
It seems a very broad definition.