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

[Christian Grothoff <[e-mail]>]

On 08/19/2014 08:07 PM, Hagen Paul Pfeifer 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.

Well, that pretty much sums up what I have been saying in the past to
the IETF: https://gnunet.org/strint2014gnunet

And yes, I do not like SSH, TLS, GPG or X.509.  But we cannot fix
everything at once, and sometimes a hot fix can be useful.  TCP Stealth
is just that: a small fix to a small problem, it does not try to solve
everything.

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

You clearly also deliberately missunderstand the difference between
design / specification / mechanism, and the reality of an implementation.

> I understand your objection but the "fix" feels wrong. We should do
> everything we can to make TLS fast, clean and strong.

Then standardize TCPCurve.  In the meantime, this is about TCP, not
TLS.  And the service I would see this use with most is SSH, not HTTPS.

> 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 do not propose a reduction of the space, only under some unfortunate
and clearly undesirable circumstances with several of the entropy
sources being unavailable this may happen, and even then I do not
believe the problem is quite as big as you make it out to be.

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

Prove is a strong word.  Now, I would not mind if the standard included
some strong wording on using a random TSval in combination with TCP
Stealth by default.  But, as was pointed out, due to some NATs messing
with TSvals, we decided to keep it optional, as opposed to mandatory.
But I think that is a point I would be open to discuss, as it is really
a trade-off.

Happy hacking!

Christian