Dueling Fingers
Originally uploaded by nklingenstein The wireless networking may have been problematic, but the human networking was excellent. Spirited argument between friends (see picture) is always great fun.
]]>
I've been at a networking conference this week. If you've sent me mail and I haven't replied, the above indicates why. Normal service will be resumed in a day or so.
]]>This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.
RFC 5241 for the whole thing.
]]>There are some interesting statistics in there (for example, the high degree to which the fairly young JANET Server Certificate Service has already taken off) but the other theme of the talk was that there is an awful lot going on that we probably can't understand without a lot more direct interaction with the membership.
I've also uploaded the slides to slideshare, if you'd like to give that a try.
]]>I made an audio recording of the presentation. I ran "a bit long" on the day (70 minutes), but once I have edited out the coughing and some of the rambling I'll post a synchronised audio+slides version.
Links referenced during the talk:
]]>GTD and OmniFocus won't magically rescue you from being disorganised (they certainly haven't entirely done that for me) but I've found that some of the GTD principles that OmniFocus allows you to implement really do lead to some level of stress reduction:
Get everything that's on your mind out of your head and into a trusted system.
Plan in terms of small, concrete, actionable steps.
Concentrate on the next available action for your current context.
You probably can't plan multi-person mega-projects this way, but that's not what this product is for. If you're trying to hold together a lot of smaller projects, it can be pretty much ideal. There's a 14-day trial available.
]]>The idea is pretty self-explanatory if you've heard of the concept of a tiger team elsewhere: this is a "reality" show in which the heroes break real-world security systems using a combination of technology, brass neck and dumpster diving. Rather like Mission: Impossible but without Peter Graves and (so far) without the rubber masks. What's not to like?
Unfortunately, I can't see any evidence that this series will be shown anywhere here in the UK, but you can stream the pilot episode from the cable channel's web site, at least for now. It's interesting to watch the ways in which the target's (fairly good) security fails when approached in the right way, and the presentation isn't too grating even for my sensitive British ears. Some of what you see is obviously re-enactment, but I guess that's "reality" TV for you.
]]>On the other hand, I do sometimes wonder about rating my posts in terms of a new metric: how many Wikipedia entries would you have to reference to explain this to the man on the Clapham omnibus?
One of my favourite cartoon sites — xkcd.com — also finds the need to peg the MOTCO-meter once in a while. Responsible Behavior is a good example; I have to rate it a four at least:
Do you agree? More interestingly, what do you think the answer will be in ten years?
]]>![[thawte Web of Trust notary seal]](http://www.iay.org.uk/identity/seal_wot.gif)
I am now a (very junior) notary in the thawte Web of Trust. An assurance from me is worth 10 points towards the 50 required for a personal e-mail certificate with your own name on it.
More details are available for those who are interested.
]]>What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.
It's possible that this is accidental; if it is deliberate, the prime suspects are the NSA, who have been pushing to get this algorithm adopted for some time. So much for the usual outsider's paranoia about how the evil TLA might be compromising our cryptography for their own nefarious ends. That's not the scary part, though; the really scary part is the thought that perhaps that isn't what is going on:
If this story leaves you confused, join the club. I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
Shumow and Ferguson's presentation (.pdf) is short, and although there are some squiggly letters in it you don't need to understand the mathematics of elliptic curves to follow the argument.
I look forward to seeing how this one plays out.
(Via Schneier on Security.)
]]>
I knew the seafood here in San Diego was supposed to be pretty good, but apparently it's also important to hang on to some during natural disasters.
]]>
I've been promising myself a set of properly prepared MOO cards since I got some free samples a year ago.
I finally got round to doing this; the cards arrived just in time for my trip to the Internet2 Fall Member Meeting, and literally an hour before the postal strike started.
For this batch, I went through a lot of old images looking for images that would work in the 70mm by 28mm format; most of the results are still crops from much larger images, though. One thing I found very helpful this time round is that you can download a Photoshop template for the card format, including guides to help you allow for a safe area and off-card bleed.
I've uploaded all the images I used for this batch as a flickr set for anyone who is interested; they are CC-licensed, so feel free to use them for your own cards if you like them.
]]><!-- MicroID for '/' variant of URL --> <meta name="microid" content="mailto+http:sha1:b887e662ed3d811e665ef4a034e018a521a5467d" /> <!-- MicroID for '/index.html' variant of URL --> <meta name="microid" content="mailto+http:sha1:ed938d07588303f4eeee45adfef090221e0c692e" />
A MicroID is a very simple way of making a verifiable statement about the ownership of a page. The specification goes into more detail, but essentially the value you see is constructed by independently hashing your e-mail address and the URL of the page in question, concatenating those results and then hashing once more.
The way you use a MicroID in practice is as supporting evidence for a claim of ownership to some third party who already knows your e-mail address. If you say "I own that page" to such a third party, they can compute the same MicroID value from your e-mail address and the page's URL and then check for a match within the page's <meta name="microid"> headers. You can see this claim checking by looking at the "verified" links in my claimID profile.
MicroID is an improvement on the perhaps more obvious approach of just embedding your e-mail address in the page because it doesn't reveal your e-mail address to things like spam address harvesters. It also improves on a simple hash of the e-mail address by including the URL in the calculation because all pages owned by the same e-mail address are thereby given different MicroIDs. This in turn means that pages can't be grouped together, even anonymously, by web spiders. Looked at from this point of view, a MicroID is a salted hash of the e-mail address.
I'm pretty sure that you could do the same job with one or even two less hash operations (for example, the URL is known by definition, so hashing it serves no purpose that I can see), but for static pages performance is not a concern. If I was running a large content site with dynamically generated pages, though, this aspect of MicroID might put me off a little.
Note that although a MicroID looks a little like a digital signature (of the URL) it really isn't; in particular, a MicroID can easily be repudiated because anyone knowing your e-mail address can generate MicroID values "for" you and put them on any pages they please. In other words, you can use it to help confirm ownership of something by a claimant, but not to prove ownership by someone who denies the connection.
Generating the MicroID values for blog pages in particular was made simpler for me by Phil Windley's MicroID plugin for Moveable Type. I did have to tweak it a little to correspond to the current MicroID spec, as Phil's plugin as distributed generates what is now thought of as a "legacy" format lacking the scheme and algorithm specifiers.
]]>As an experiment, I've narrated the unused slides and they are now available for download in one of the following formats:
The presentation is a little under 20 minutes long. Please let me have feedback if you find this kind of thing useful, or for that matter if you find my voice too soporific or annoying. I'm considering doing more along these lines, and it would help to know in advance whether I'd be wasting my time.
Gearheads can read on for technical details…
]]> I've been meaning to get round to this project for some time; what finally prompted me to complete it was the release of Apple's Keynote '08 presentation software, which finally allows recording an audio track synchronised with slide timings. I'm sure the PowerPoint users in the audience are snickering at this point; they've had this ability for ages.Of course, I ran into a couple of bugs along the way, the most annoying one being that you can't export a movie from a presentation that you've backed up at any point, for example to re-do a slide you fluffed delivery of.
In any case, it turns out that I make enough mistakes in narration to need a lot of post-production work to avoid sounding like an idiot with a terminal respiratory disease. So my current workflow for each major section goes a little like this:
On the hardware side, I'm using a Sennheiser e815S microphone and an M-Audio Fast Track USB interface. Which is to say, I'm using the cheapest non-junk bundle I could find a year or so back. While this is far from professional studio audio standard in any sense, it is a huge step above either a built-in microphone or one of those desktop microphones that used to come with PC sound cards.
The biggest problems I've had with sound quality from this setup have all been rookie mistakes; for example, the golden ears among my readership will easily discern a quality jump in the recording at the start of the "Trust" section. Before that point, I had the microphone on a metal desk stand which meant that it was picking up keyboard and other noise through the stand. From "Trust" onwards, the microphone was mounted on a photographic tripod pretending to be a microphone boom by having its legs splayed out in interesting ways and weighted with lumps of metal. Far from ideal, but it makes a surprisingly large difference to the sound. If I do any more of this kind of thing, top of my list is a proper boom-style microphone stand.
]]>(Via Matt Blaze.)
]]>