Subject: [tcpinc] Internet-scale attack on TLS

From: ianG <[email-masked]>
Date: Sun, 26 Apr 2015 15:34:09 +0100

An attack on TCP/TLS has now been detected at broad scale, and traced 
back to the bug responsible (client-side Heartbleed) and the probable 
attacker (agency with massive pipe access, e.g. NSA).

This attack more fully informs the reason for the existence of the 
group.  It less directly informs the technical solutions, and indeed 
might just cause confusion as there is room for both sides to claim "I 
told you so!"  :)

http://cryptome.org/2015/04/goodcrypto-attacked.htm

... In early 2015 people were still downloading our ISO file for 
GoodCrypto. But suddenly installations stopped.

After a lot of checking we noticed that the downloads got HTTP 200 
result codes, but the lengths were all too short. This isn't supposed to 
happen. A 200 result means success. These weren't successful downloads, 
but the web logs said they were. Ordinary log checks didn't show the 
bug. ...

---

From: Christian Huitema <[email-masked]>
Date: Sun, 26 Apr 2015 18:36:35 +0000

> might just cause confusion as there is room for both sides to claim "I

+1.

What is the value of TCP-INC if it cannot defend against packet injection attacks?

-- Christian Huitema

> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: John Border <[email-masked]>
Date: Sun, 26 Apr 2015 18:50:05 +0000

Privacy

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Sunday, April 26, 2015 2:37 PM
To: ianG; [email-masked]
Subject: Re: [tcpinc] Internet-scale attack on TLS

+1.

-- Christian Huitema

> result codes, but the lengths were all too short. This isn't supposed 
> to happen. A 200 result means success. These weren't successful 
> downloads, but the web logs said they were. Ordinary log checks didn't 
> show the bug. ...
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Apr 2015 12:28:08 -0700

To the best of my knowledge, TCPINC cannot protect against packet
injection attacks by attackers who have complete control of the network
because they can just force you not to negotiate TCPINC. That's a
basic property of it being opportunistic, and you'd need preconfiguration,
some sort of secure advertisement, pinning, or the like to prevent it.

The best that I know how to arrange is that if the attacker is not
present and interfering with the initial handshake that subsequent
packet injections are not possible.

-Ekr

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 26 Apr 2015 12:31:52 -0700

Hmm ... This seems like a potential rathole. This is a MITM attack
(though I don't understand it fully), and TCPINC is expressly not
protecting against such attacks, right? I may still not understand the
value proposition of TCPINC, but that would be a different thread on a
different list, I think.  This attack, as several other attacks are bound
to be, seems to be out of scope for this wg.

---

From: David Mazieres <[email-masked]>
Date: Sun, 26 Apr 2015 17:49:01 -0700

> to be, seems to be out of scope for this wg.

The value proposition comes from separating the encryption from
authentication, because it makes it easier to test the two parts
independently.  It just so happens that both TCPINC proposals have this
property, so if ever either of them gets to the point that people are
doing certificate validation of the TCPINC session ID, the validation
code may be easier to test.  Also, people may use multiple techniques to
protect session IDs, such as a certificate and a password or two-factor
mechanism, mitigating the effects of forgetting to check the
certificate.  However, by the time this happens, TLS channel bindings
may be in more widespread use, too.

So I wouldn't say it's directly relevant to TCPINC's charter, so much as
a side benefit of getting to design a protocol in 2015 when we
understand these architectural issues better.

David

---

From: ianG <[email-masked]>
Date: Tue, 28 Apr 2015 13:53:32 +0100

On 26/04/2015 20:31 pm, Jana Iyengar wrote:
> protecting against such attacks, right?

Precisely.  Opportunistic security does not, should not and cannot 
protect against all attacks;  in this case, TCPINC doesn't protect 
against a direct MITM and would not have necessarily change the nature 
of the attach described in that post.

The debate that forms around this nexus is whether to protect against 
some active attacks, knowing that we cannot stop all active attacks.

> I may still not understand the
> value proposition of TCPINC,

There are approximately three mode of attack in the TCPINC/OS worldview:

1.  easy attack: passive surveillance.
2.  mild attack: MITM against Opportunistic Security protocol eg TCPINC
3.  heavy attack: bypass against a strong protocol like TLS.

TCPINC knocks out 1.  Huge win, because this is going on right now at 
Internet scale, and not only by NSA and China but also by every modern 
data-mining ISP.

TCPINC fails against 2.  But it makes it possible to detect - which is a 
win.  Not necessarily easy, but as implementations advance they will 
provide better diagnostics, and devs and sysadms will watch for the 
signs.  It is this result that the original post highlights -- they saw 
signs, they tracked it down and announced some form of attack.

TCPINC fails completely against 3, but TLS succeeds, which forces the 
attacker to use other "bypass" attacks which are more expensive and more 
detectable (hopefully).  The point here is that the information found in 
2 will increase the incentive to employ stronger security overall.  More 
information leading to clearer incentive is a win.

In a nutshell, the game is to force the attacker to at least MITM us, 
because then he's out in the open, visible.

> but that would be a different thread on a
> different list, I think.  This attack, as several other attacks are
> bound to be, seems to be out of scope for this wg.

Yeah, in the large, this is a topic for a different list/thread.  But 
the small direct link is that it is a very nice example [0] of what we 
are facing when we deal with the net overall.

iang

[0] there is some criticism elsewhere that the story is not accurate, 
that the attack was simply a bug in browsers.