With all the hype, my plan was initially to not attend Dan's talk and go to something more interesting. My next thought was that most of the talk get completely dissected after BH anyway, so I would rather take advantage of the 'being there' factor and go watch the soap opera unfurl live.

He started off pretty well, gave some insight into how he had discovered the flaw, how the sooper sekret multi-vendor discussions had gone etc. He pointed out that Pieter de Boer was the first to 'rediscover' the bug 51hrs later. He also showed an awesome video of the patch rates around the world.

I was interested that by speaking to Trustwave, the fear and loathing of PCI was used to drive many corporates into patching.As Dan pointed out 'probably the first time compliance has been used to accomplish anything useful.' I'd restate that as 'probably the first time compliance has been used to drive rapid response to a tangential security incident.'

After that things went downhill. Dan decided to use the rest of the talk to provide illustrative situations of what a MITM can do. He went on at length describing all of the various protocols, services etc. that can be MITM'ed. He also pointed out that bugs don't need to be 'sploited in isolation which gave him more time to go into scenarios. He could have used this time to go into more interesting discussions around the usability of DNSSEC, practically solutions, more details about the bug etc. Anyone who knows what a MITM is should have been bored.

During this time I started to get irritated, but I mean really physically irritated. I couldn't work out why, until I realised it was some element of his stage personality that was pissing me off. At first I ignored this as me just being judgemental of a socially akward geek with a podium and media; and chided myself. However, after unpacking this in rants at anyone who would listen during the course of BH and DC I realised what was bugging me.

Dan was show boating. His entire approach to the thing was show boating. His 'wait for blackhat' plea, which irked me because it was just too obviously a media stunt combined with his 'ra ra, hand wave' presentation made it very clear. What's worse, his claim that he was trying to help people and get things fixed ASAP was hurt by his method of disclosure. By the end of the talk, I had switched to red pen (I wan in rant mode) to document why I felt his disclosure method was at fault for the 90 day patch window.

There are two things required for patches to be deployed, a working patch, and a willingness to install the patch. To drive the willingness, security people (or admins charged with patch responsibility) need to understand the risk so they can make a proper risk decision relevant for their circumstance and organisation. Dan's work to coordinate the release of the patch was great, we got multiple patches all at once without in-the-wild exploits. However, how urgent was this patch? Should we divert resources from existing stuff to test and deploy it? Is there a significant risk difference between external DNS and internal DNS etc.? The delay in patching NAT'ted DNS servers illustrates how this lack of information hurt patching. When a client phoned me to ask how urgent the patch was, all I could say was I'm not sure and to include it as part of the normal test/deploy cycle. If we had this information, if the security community had it, we could have properly understood the bug and known what the risk was.

This does make Dan look a little hypocritical. The reason I choose hypocrisy and not 'a failure of unintended consequences' if for two reasons. The first is that Dan actively crusaded to keep discussion off public lists, this goes far beyond whatever NDAs he was probably slapped with. When one hippy posted to full-disclosure with a hypothesis, Dan personally mailed him and asked him not to discuss this stuff publicly. While it is silly to tell one of the most inquisitive communities in the world not to talk about something, it is antagonistic to the goals of 'get everyone to patch' as well (because it prevents an intelligent risk-based decision from being made). I also don't think Dan has an excuse for not understanding models of disclosure and their implications. We've seen vendors semi-secretly patch bugs before, and we know the outcomes, and the debate is a couple of decades down the line. Finally, the reason I think Dan should take responsibility for this criticism is because he made such a big play to put himself in the centre of it.

I'm probably being a little unfair to someone who spent a lot of time working on something and who in the end got the world a little safer (and who I have never met personally). So take this as a commentary on his methods and media image, and not him personally. Ideally, take this as a lesson of how not to disclose bugs, ever.