Subject: [hybi] Red team v Blue team - security analysis?

From: Greg Wilkins <[email-masked]>
Date: Sat, 9 Oct 2010 11:50:19 +1100

This whole cross protocol vulnerability discussion has become horribly
confused, as we are all mixing up WS->HTTP, HTTP->WS, WS->DNS, plus
hosted environment, handshake vulnerabilities, framing vulnerabilities
etc. etc. There are lots of description of partial or potential
attacks, but the whole discussion is lacking focus and detailed
analysis.

Maybe we need a red team vs blue team approach.   The red team
proposes some detailed attacks and the blue team responds with a
detailed description of the defence.   The red team then get's to
replay their attacks, but with an if-only-software-flaw of their
choosing, the blue team then responds.   We can then repeat for 2
if-only's etc.

Players can bat for both teams if they want.

Thoughts?

---

From: Dave Cridland <[email-masked]>
Date: Sat, 09 Oct 2010 13:03:47 +0100

> Thoughts?

Who's going to be team captains, and will I get picked last *again*?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Maciej Stachowiak <[email-masked]>
Date: Sat, 09 Oct 2010 20:00:25 -0700

> Players can bat for both teams if they want.

A few thoughts:

1) Attempting to find ways to break a proposed protocol seems like a good thing to do. I am not sure we need "teams" to do it. Everyone should be trying to find holes, including in protocols they themselves advocate. I'm particularly skeptical of designating people to play defense. That sounds like a recipe for getting emotionally attached to a system that may or may not work.

1) "Red Team" testing seems like a more useful approach for a deployed live system than for a protocol design that exists only on paper. Whether an attack works is unambiguous on a live system - it does or it doesn't. There is more room for ambiguity when proposed attacks are against something described in words. Maybe we should built prototype implementations and try to find attacks for real.

3) If we have several protocols and don't identify a fully working attack against any of them, what then? We'll have to fall back to other factors, such as:
   a) Are there "almost working" attacks that bypass some but not all of the intended protection? These should be cause for worry.
   b) Are there solid arguments that prove security invariants about the protocol? That can be somewhat more solid than the "we haven't found an attack yet" standard.
   c) Are there security properties which can be proven through formal modeling?
   d) What is the performance impact of a particular protocol, in terms of computation cost, memory use requirements, network round trips, etc?
   e) Is there a significant likely ease-of-implementation benefit to a particular approach?
   f) Does the protocol design make it easier or harder to make implementation mistakes? Are errors of implementation that may lead to security holes likely to be caught?

I think we should be thinking about (3.a-f) above at the same time as we look for holes. It would help to have a detailed description of each proposed handshake, to the point that we could determine the exact bytes that would be sent on the wire, or even do prototype implementations for experimental purposes.

Regards,
Maciej

---

From: Vivek Khurana <[email-masked]>
Date: Sun, 10 Oct 2010 11:03:40 +0530

> I think we should be thinking about (3.a-f) above at the same time as we look for holes. It would help to have a detailed description of each proposed handshake, to the point that we could determin…

+1 for this approach.

In past I have noticed that developing a protocol along with a sample
implementation/prototype is a better way to find security loopholes.
My thoughts on finding security loopholes is to divide into 3 teams,
protocol writers, developers and attackers. Developers can develop a
protocol as per the specification written by protocol writers and
attackers can try to break into the prototype.
 This will reduce the amount of guessing involved into modeling the
protocol. Though I am not sure if this approach is acceptable to W3C.

regards
Vivek
-- 
The hidden harmony is better than the obvious!!