It's precisely the correct word. Prisoner's dilemma are simple, mathematically. This was one. OpenBSD defected. The joke's on the security researcher, though, since this doesn't appear to have been their first time [1][2].
Robert Axelrod outlined, in his 1984 classic The Evolution of Cooperation [3] four requirements for a successful iterative prisoner's dilemma strategy. One is retaliating. Security researchers are letting OpenBSD play an iterating game as if it's an N=1, i.e. they're not retaliating. Given the community is playing "always cooperate," OpenBSD's best move is actually "always defect".
[1] https://lwn.net/Articles/726585/ thank you 0x0 [a]
[2] https://lwn.net/Articles/726580/ thank you 0x0 [a]
[a] https://news.ycombinator.com/item?id=15481980
[1] https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation
Real life is messier than any model.
https://www.quantamagazine.org/in-game-theory-no-clear-path-...
I'm mostly here just to correct misstatements of facts. You're welcome to your own interpretation, game theory optimization, etc.
You also can not guarantee me that no one who gets this information early is not working for a bad actor.
I was informed on July 15.
The first embargo period was already quite long, until end of August. Then CERT got involved, and the embargo was extended until today.
You can connect the dots.
I doubt that I knew something the NSA/CIA weren't aware of.
There's only a few courses of actions. One is to sit quietly and let everyone eventually do the solution. And that doesn't work. No fire under peoples' asses, and the work is delayed.
The other, is to release it promptly. Then, at least we can decide to triage by turning down X service (even if wifi), requiring another factor like tunnel-login or what have you.
But truthfully, defect in a Prisoners Game played out here was the best choice. The rest of the community is "agree".
If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.
I've been doing that for years and recommend others do so as well.
The rise of HTTPS nearly everywhere helps mitigate things a bit. This same type of exploit 5 years ago would wreak havoc exploited at the local Starbucks WiFI.
Think about it in a different way: What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out about it (they would know immediately) and use it to target users/activists?
But pretending as though co-ordination of any kind is somehow bad (and then resorting to emotional arguments and so on) is pretty reckless.
> even users of non-proprietary projects
Actually many FOSS projects get only notified on the disclosure date.
Hiding the vulnerability for such a long time makes more harm good. The vulnerability can potentially be exploited by security agencies that necessarily know about them and could also be leaked to a bad actor by an employee of one the vendors.
Hopefully WPA2 isn't that important, but potentially security sensitive users trusted something that was known by some to be vulnerable for 3 months! Bad actors could have used it against them.
The embargo resulted in potentially bad actors knowing about the issue, but not vulnerable users.
Do you seriously expect the other billions of people on the planet to be that great too?
No. I also don't expect them to choose device based on security. That is very bad as vendors won't care about patching their older devices (look at Android devices, home routers...) and vendors won't care about patching their flagship devices fast as they have the possibility to request very long embargos.
Making compromises for those vendors and giving more time for security agencies and other bad actors to silently exploit the vulnerabilities (where FOSS projects would have made patches for users that care) is not the way to go. That philosophy actually makes everybody less safe.
If you don't agree with an embargo and decide to break it, that's on you. But the consequence is that you shouldn't be surprised if next time you're informed later, or not at all. What OpenBSD proponents and developers are doing right now, is damage control. It may work this time, it may work next time, but it won't keep working every time so pick your fights right. It isn't the first debacle OpenBSD has with full disclosure either (hint: OpenSSH).
There are also millions upon millions of devices which won't get patched. Given the vulnerability is apparently the most vulnerable on Linux and hence Android, do you think all the smartphones running Android 4.3, 4.4, 5.0, and 6.0 will be patched [1]?
[1] https://en.wikipedia.org/wiki/Android_(operating_system)#Pla...
0 - https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309b... 1 - https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea...
The patch has obviously an explicit description:
"State transition errors could cause reinstallation of old WPA keys."
It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued.
My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.
The whole thing is a shit show and really I'm rather more behind OpenBSD's approach.
Edit just to expand on this as someone deleted a post ....
----
It's slightly more complicated than the prisoner's dilemma. The prisoner's dilemma doesn't account for a large facet of the problem which is being discussed here. If all the good parties participate and coordinate then we're better off. The problem is there are outlying circumstances which means that not everyone will be included:
1. If someone kicks someone out (OpenBSD) on political whim playing CYA, they no longer benefit.
2. If a party is not let in, they no longer benefit.
3. If someone is unaware of it, they don't benefit.
This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
The first thing the people outside of the club find is they wake up on Monday morning and have to clear up a shitstorm of monumental proportions with less resources than the monopolised vendors who've had time to deal with it.
Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid.
No bullshit please - you guys do a wonderful job of avoiding it and stamping on it when it does turn up. Keep up the good work :)
> This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule.
Not necessarily. It turns into a monopoly of those who can show themselves to be credible partners. This exhibits incumbency bias which in social context we call track record. It's not nearly as exclusionary as you're making it out to be.
> Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid
This is common in trust problems. You don't need to be 100% sure everyone you're dealing with is trustworthy to work with them because we don't live in a single-iteration game. Again, iterations of retaliation and forgiveness remove the need to have 100% certainty about a player's intentions.
No one is credible here. The very nature of a closed agreement of secrecy between arbitrary parties is the opposite of credibility.
Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities until after the embargo date or (b) refuse to give any information unless they sign a binding non-disclosure agreement committing them to the deadline under pain of penalty. (The latter is an option because it appears, in this case, they broke the spirit if not letter of the agreement. The solution to that problem is legalese.)
I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did.
The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me.
(edit: typo)
If Mathy was concerned, why did he wait to notify CERT? Should that not have been the first priority?
Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.
TL; DR OpenBSD acted rationally if they'd prefer to go it alone, which seems to be their culture. To their credit, it's worked pretty well so far. But you can't have your cake and eat it too. If they prefer a mad scramble after public disclosure, they'll get it. But they shouldn't get early notice from responsible researchers.
I don't believe that embargo is healthy or responsible! If anything its a monopolising factor.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: "In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging". Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.