[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack

Christian Huitema huitema at huitema.net
Sun Aug 2 14:28:43 EDT 2015


 
On Sunday, August 2, 2015 8:20 AM, Tom Ritter
> To: ianG <iang at iang.org>
> ...
> On 1 August 2015 at 21:27, ianG <iang at iang.org> wrote:
> > Can anyone suggest a way to get around this?  I think this really puts a
> > marker on the map - you simply can't do a security/crypto protocol under
> > rough consensus in open committee, when there is an attacker out there
> > willing to put in the resources to stop it.
> >
> > Thoughts?
> 
> My opinion is that the rough consensus can be counter-balanced by
> "running code".  If the original group moves forward, deploys, gets
> early adopters, shows it's working, and perhaps wonder-of-wonders gets
> it picked up by one of the big behemoths that could jump-start
> deployment (maybe Google, or Akamai, or CloudFlare) - well they can
> document as an informational document at least.  And you can
> interoperate with the folks who have deployed.

That's what worked in previous similar scenarios, e.g. SNMP vs. CMIP, or OSPF vs. ISIS. 

Note that I cannot help associating IanG's message with the current state of the TCP crypto working group. And in that particular case, I don't believe there is much malice involved. 

The group started with a goal to "develop opportunistic encryption for all TCP connections," but quickly ran into two kinds of troubles. The first one was a need to traverse the hodge-podge of firewalls, inspectors and accelerators that we call "middle boxes." Turns out that if you want to do that, you have to leave TCP pretty much alone, and that negates most of the compelling advantages of the original "TCP Crypto" design. If you cannot secure the TCP protocol itself, you are bound to just insert a security filter on top of TCP, which brings the second issue.

We already know how to run a security filter on top of TCP. That's what SSL/TLS do. At that point, the obvious question is whether the original goal of "opportunistic encryption" is best achieved by just inserting TLS as a filter, or by developing a light weight filter that would be easier to insert -- where light weight means light weight negotiation, as the actual cost of encryption is pretty much constant in any proposal. 

There are bunches of arguments one way and the other, but they are all about implementation issues, not about anything drastic. For example, we don't want to encrypt twice, so any light weight filter would have to be disabled if the application actually runs TLS. We also want applications to be able to evolve from "opportunistic" to "strong" encryption, which means adding authentication. And that means either evolving a parallel authentication framework in top of the light-weight filter, or just switching to TLS. And then there is a question whether having two parallel technologies means twice more resiliency, or two times as many bugs.

So we are seeing two camps, not out of malice but because people weight different arguments differently. And yes, the only way out is to start deployments and see what happens.

By the way, there are actually three camps in the debate. The third camp is QUIC, the protocol designed at Google to subsume both TCP, TLS and the bottom layer of HTTP 2.0. 

-- Christian Huitema






More information about the cryptography mailing list