Subject: Re: [tcpinc] Forcing the restart of a TCPINC connection

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Feb 2015 07:25:22 +0100

below...

El 11/02/15 a las 06:04, Martin Thomson escribió:
> On 10 February 2015 at 21:52, marcelo bagnulo braun <[email-masked]> wrote:
>> C decides then to send a FIN (or a RST) with the expectation to force the
>> restart of the connection.
> Unless peers are authenticated somehow, or peers are able to make some
> sort of commitment to a key, then this seems like a plausible attack.
> I guess that it falls under the "active" umbrella though.
>
>

but the potential concern here is that the attacker can choose for which
established connection he wants to disable the encryption and eavesdrop.
if you protect the FIN and the RST bit, even with unauthticated key, it
is not possible to do this once the DH exchange has ocurred.

I mean, if we protect the FIN and RST bit,s once the security
association between the endpoints has ocurred, an external attacker is
unable to disable the encryption, i believe.

---

From: David Mazieres <[email-masked]>
Date: Tue, 10 Feb 2015 23:55:14 -0800

> unable to disable the encryption, i believe.

I agree, which is why I would like to see an option for protecting such
metadata.  I do think the FIN and RST should be considered separately,
though, because FIN is easier to deal with and arguably worse.  RST is
potentially more controversial, so we would ideally have both options
selectable by the administrator, default to something conservative but
in the end let users and administrators vote with their configuration...

David

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Feb 2015 10:07:26 +1100

> in the end let users and administrators vote with their configuration...

Both need to be protected equally to mitigate the attack. Fail to
protect either and attackers will use that one.  The difference is in
the consequences of protection.  We could see a lot more connections
enter zombie states if RST is protected (and protection is insisted
upon); protecting FIN maybe less so.

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Feb 2015 15:32:58 -0800

> upon); protecting FIN maybe less so.

See rfc5925, section 7.7

The solution is to:

	a) protect RSTs (vs. not protecting them)

	b) require connections use TCP keepalives

(b) protects against zombie states.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Feb 2015 08:42:11 +0100

El 12/02/15 a las 00:07, Martin Thomson escribió:
> protect either and attackers will use that one.

agree

>   The difference is in
i guess that depends on the solution we pick, but yes, protecting RSTs 
is more challenging.

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Feb 2015 08:02:10 -0800

> i guess that depends on the solution we pick, but yes, protecting RSTs

It really isn't, as per my other post. This was solved during the 
development of TCP-AO, and the methods are not specific to that option.

Joe

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Feb 2015 15:04:02 +0200

> is not possible to do this once the DH exchange has ocurred.

It is still active attack. With active attacks the attacker, can also
act as man in the middle for every single connection if he feels like.
To be able to pick one of the encrypted connections and only do man in
the middle against that is not that big change.

Also with active attack attacker can also simply drop all packets
having suitable selectors, thus causing the connection to timeout and
then he can again do the same attack. 

> unable to disable the encryption, i believe.

Not true. If he adds filter that will drop all those TCP packets, and
then forces them to go to plain text connection (for example doing
active attack and removing the tcpinc signaling), or act as
man-in-the-middle.

If you want to protect against active attack you need policy which
will authenticate the other end and which do not allow any
unauthenticated unencrypted connections between peer.

For that kind of uses, you simply need to use TLS, IPsec or SSH...

Note, that dropping all frames is easier if we enforce the tcp header
protection, as attacker can simply configure one of the routers to do
something for the header which will cause message authentication of
the tcp header to fail. For example flip the PSH bit in router. This
will most likely go unnoticed for unencrypted connections, but will
break all connections that will try to verify the TCP header flags... 
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Feb 2015 18:17:53 +0000

Tero,

> unauthenticated unencrypted connections between peer.

I don't believe that is entirely true.

With an s/protect against/prevent/ it would be true.

Prevention is not the only form of protection.

I wonder is that a source of some of the difficulty in getting to
agreement about this.

If one has protection against a passive attack and if that is used
in almost all cases then that makes the cases where it is not used
interesting, and possibly things to investigate. We saw exactly
that pattern happen with an ISP that was causing SMTP/STARTTLS
to fall back to cleartext recently.

So passive protection is also some level of protection against
active attacks that are easily spotted, such as those that cause
a fallback to cleartext.

(And in principle, with D-H used, there may be ways to detect
that Alice and Bob have ended up with different shared secrets,
though tcpinc is maybe the hardest cases for making that work.
And that's another day's work anyway.)

Cheers,
S.

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 14 Feb 2015 18:55:02 +0200

> Prevention is not the only form of protection.

I do not think preventing is correct either, as we do not really
prevent or protect against, we can simply detect the active attacks,
and stop communications....

> interesting, and possibly things to investigate.

When most of the people will safely ignore the broken lock and big
warnings which come up when the authentication of the connection fails
on methods which do require authentication like TLS, how do you expect
anybody to really bother whether invisible behind the scenes method
like tcpinc would suddenly sometimes fall back to clear text... 

> We saw exactly that pattern happen with an ISP that was causing
> SMTP/STARTTLS to fall back to cleartext recently.

Or the dropping to the cleartext when using postfix + openssl 1.0.1g
and talking to the unpatched ironport. At least sendmail users did get
complains that mails do not work anymore as it considered handshake
failure as temporary error and did not fall back to cleartext if other
end claimed to support TLS. I think most of the postfix users never
even noticed that issue. At least several places in Finland are still
using unpatched ironports...

> active attacks that are easily spotted, such as those that cause

Regardless whether we protect FIN or RST, the fact that two peers did
talk with tcpinc and then next connection got dropped to cleartext, or
got its key changed, should cause some kind of audit event. Whether
anybody is ever noticing that audit event does not really matter. 
-- 
[email-masked]

---

From: ianG <[email-masked]>
Date: Sat, 14 Feb 2015 18:00:56 +0000

> and stop communications....

Right, it's hard to see how one can 'prevent' an active attack as both 
sides presumably have the option to stop communications entirely, and 
that is only a loss for us.

Terminology matters, if only to help against silly arguments.  In the 
risk world, we talk about 'mitigating' an attack rather than preventing 
it.  In this sense, we mitigate active attacks by logging.

That's a sort of recognition in risk world that no attack can actually 
be stopped entirely, and economics matters.  Something that is more true 
in the physical world than say the cryptographic world.

> like tcpinc would suddenly sometimes fall back to clear text...

Right.  This is really not about protecting or mitigating from 99.9% to 
99.95%.  It's about leaving enough of a trail such that anyone who does 
do the obvious RFC-advised tricks will eventually be outed.

> using unpatched ironports...

This is working well.  I've noticed that every second free wifi in some 
public space is MITMing and consequently it all breaks down.

> anybody is ever noticing that audit event does not really matter.

+1

iang