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

[Jacob Appelbaum <[e-mail]>]

On 8/19/14, Hagen Paul Pfeifer <[e-mail]> wrote:
> 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.

No, it isn't. It isn't a zero sum game. We are trying to protect
against people port scanning - that an authorized user may abuse a
service is another issue - we do not protect against it, except that
you may revoke that user's ability to exploit the service, of course.

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

This is false. I use heartbleed as the example.

>
> 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.
>

We should do both. It would be nice if TCP helped us with this
realistic issue - services are exploitable, let us mitigate the
problem with authentication for specific services at a different
layer. We can authenticate the use of a service in a forward
compatible manner and that is what the draft seeks to standardize.

>> 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! ;-)

The ISN is still 32bits. We do not reduce the space and the entropy of
the space does not change. There are corner cases where a passive
observer may replay a packet as if it was normal TCP. Thus in the
worst case, we're as bad as TCP is in every case, all the time.

All the best,
Jacob