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

[Hagen Paul Pfeifer <[e-mail]>]

On 19 August 2014 19:15, 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.

C'mon Jacob, this smells fishy! Let's assume you protect *your*
service from one potential TLS bugs, this is (partly) possible with
the mechanism described in the ID. But what happens in the meantime
with your https:// browsing, openvpn, ... communications? If you
assume bugs in TLS you must stop all your communications! TLS and
strong cryptography is the fundamental building block - when it is
broken the whole communication system is b0rken.

The other way, if you trust TLS you can also trust the TLS client
certificates mechanism as well.

I understand your objection but the "fix" feels wrong. We should do
everything we can to make TLS fast, clean and strong. But to repeat
myself: I see advantages and benefits and _if_ there are no major
disadvantages we can push things forward. Well, no need to answer
here, I got your point in detail and I want to make sure we discuss
all possibilities, using TLS client certificates is one alternative.

> It isn't abuse - we're even trying to make it a standard to ensure
> that it is well documented non-abusive behavior - rather different
> than most other port knocking, I'd add.

The ISN has 32 bits, reduce this space leads to problems in the past.
We must do everything to not open any other attack vectors regarding
TCP by mistake. If you *prove* that this will not lead to problems, I
will never ever mention the word "abuse" in an email to you! ;-)

Hagen