Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG

[Florian Westphal <[e-mail]>]

Jacob Appelbaum <[e-mail]> wrote:
> No. I want to protect my TLS service from implementation exploitation.
> You cannot probe my TLS service for the next heartbleed without a
> shared secret.

So you won't accept e.g. smtp STARTTLS on your mail server?

Also, once this becomes widespread, people will add
--probe-all-isns switch to their port scanners....

It looks to me like this (I apologize In advance if this seems
offensive):

Q: - I want to run $service, but I don't want anyone to see it!
A: - don't run it.

Q: - But I need to access the service sometimes from random locations!
A: - protect it with a password/some other form of secret.

Q: - But then its visible to port scanners!
A: - So what?

Q: - But it allows people who have detected service presence
to try running exploits against it!
A: - If you really care, tunnel via ssh perhaps?

Q: But I really really want to hide the presence of all services,
i.e. all tcp ports should appear to be closed

A1: - There are portknock schemes to add obfuscation if you really want
this.

Q: - But I cannot use portknocking because....?
A: - ?

I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00,
but did not find any.  It talks about "pitfalls" of applications
trying to "reimplement tcp in user space".  Perhaps there
should be a paragraph as to why ra

But even assuming that there is a need for portknocking and/or
TCP Stealth:

- How does this relate to TCP-AO?
(The draft mentions tcp md5sig only, then disregards it as it
doesn't work in NATted environments)

[ I realize TCP AO has other issues esp. vs. the proposed stealth
  scheme, especially wrt. complexity.  Anything else? ]


Problems I see with the proposal (ignoring the TCP related issues
others pointed out and the "obscurity only" approach),
and a few questions:

- What about timing?  I.e. is response time different regarding
RST-from-closed-port vs. RST-from-stealth port?
- e.g., are hosts required to perform authentication even for
SYN-to-closed-port, etc?

- Your adversary may be able to do full passive monitoring of
all network traffic (also compare "replay" above), so whats the purpose
of "avoiding" active scans?

- Key Propagation (either your group is very very small, or I can
probably find the secret-secret-word via a web search...)

- Seems most services cannot use it since they have to accept
connections from (almost) anyone

In fact, this is one of the main problems that I see with the proposal;
its use seems severely limited; up to the point where its unusable in
practice.

Perhaps it would help to show specific usage examples
of how this would be deployed/where this is usable?

> > Another objection: the mechanism help only for a small fraction of use
> > cases. Especially when the server communicate with one or a few
> > clients where the "shared secret" is no problem. But especially in
> > these setups TLS client certificates could be used without any
> > problems.
> >
> 
> What happens in your example when there is exploitable code in the
> client certificate parsing code?

"What happens in your example when there is exploitable code in the
payload protection verification?"

[ Its rhetoric question.  I am aware of complexity difference. The point
is, do your really think its worth to add yet another layer -- which can
have issues both in the specification and the implementation -- rather than
e.g. slim down/fix security transport protocol specs and implementations? ]

Else, I guess I could argue that running your service via SCTP is "more
secure" since its "less likely to be found in scan..."