shared secret alternative to DSA

[Nathan D. Bowen]

Paul Crowley wrote:

> Wow, thanks!  I promise to be a benevolent dictator; see the 
> ubiquitous posters showing me gazing into the future with benificent 
> vision.

History tells me it's purely ceremonial under the precise rules of a 
dictatorship, but I would certainly second the nomination.
*salute*

> I'm pushing quite hard for the shared secret based protocol here

I can see why. Now that I know what an HMAC is, I can't think of a 
single reason to prefer DSA. (Well, actually, Java's bulit-in DSA-SHA1 
behaves better than Java's built-in HMAC-SHA1, but that's Sun's problem, 
maybe my problem and Ken Horn's problem, but not OpenID's. And as Paul 
rightly states, fixing HMAC-SHA1 implementations on my own will be many 
times easier than fixing DSA implementations on my own.)

HMAC seems perfect for OpenID.

> I'm actually more concerned about the lifespan stuff and other 
> concerns raised in parts two and three, all of which is necessary no 
> matter which way this goes.  However everyone seems to be happy to 
> agree on those changes

I'll weigh in on that: my feeling from conversations on this list and in 
real life is:
    the lifespans are crucial if we want our trust policies to be 
justifiable
and
    we might not see any failures from the "::" separator any time soon 
-- however to be safe (especially in light of Martin's IPv6 observation) 
we might as well change it now, especially if we want the respect of our 
children.

>  HMAC-SHA1 is a thousand times faster.  It makes it possible to host 
> the world's most popular OpenID server on an old Pentium under the 
> stairs.  A three millisecond calculation is a noticeable burden; a two 
> microsecond HMAC-SHA1 one really isn't.
>
>>  CON:  secret value goes from idserver to consumer in the clear.
>
> This seems to be everyone's main stopping point.
>
> In one post you mentioned that sending secrets in the clear "looks 
> bad".    But to my eyes, sending public keys unauthenticated looks 
> worse. Either can make it look as if the security of the protocol 
> isn't very well considered, if we don't justify them explicitly.  Both 
> are justified only by our assumption that actually, doing bad things 
> to core internet connections is quite difficult.  Both are solved if 
> SSL is used.

Yep, this is my big stopping point. Brad's characterization of the issue 
helped me see why I've been misunderstanding the other perspectives on 
this question.

First of all, I'll admit that my gut works differently -- sending public 
keys unauthenticated looks better to me than does sending secrets in the 
clear. That's sort of because as long as DNS is working, OpenID by 
necessity will make a lot of assumptions about authenticity.

But here's the real reason:

Currently, I get the public key by making a request to a specific 
hostname -- DNS is the only thing that gets my blind faith.

If the secret is exchanged in the clear, there's more blind faith 
involved -- and it's not just about the "core internet". This is where I 
think I haven't been clear:

I don't think I move in particularly shady circles, but I know quite a 
few people who did a little experimental packet sniffing on their 
college dorm networks. Whenever I worked at an ISP, I occasionally saw a 
few packets I probably wasn't supposed to. On the other hand, I 
certainly never played the part of an active man-in-the-middle for my 
customers' encrypted sessions. I'd be too likely to get caught. This is 
why I think that for our purposes, sniffing (more difficult or not) will 
be more "likely" than spoofing.

I think we all can believe that every once in awhile some sysadmin with 
a grudge says to himself, "I wouldn't want to jeapordize my job by doing 
any 'real hacking', but I sniffed this secret key and I could take it 
home tonight and use it over my cable modem any time in the next 24 
hours... especially since I could use it to impersonate my 
ex-girlfriend." And I think his sort of attack is what we are the most 
interested in thwarting.

Brad is already exhibiting superhuman restraint by waiting before 
unleashing this stuff on the public. If I were him, it would already be 
too late. When he finally can't take it anymore, the installed base of 
OpenID identities will be measured in 7 figure numbers. The livejournal 
stats page says those identities will belong mostly to college-aged or 
near-college-aged folks.

That's why even if I agree with the assessment of the vulnerabilities of 
the core internet, I think the core internet is the least of our concerns.

I would go so far as to say that the almost-explicit role of OpenID is 
to protect college girls' blogs from their bitter ex-boyfriends whose 
fraternity brothers are the sysadmins on their campus networks. In other 
words, unlike credit card numbers which are attractive to anyone on the 
planet, a blog's attractiveness as a hacking target will increase with 
the proximity of the attacker. And in the situations that are likely 
with things like blogs, as proximity of the attacker increases, so does 
the likelihood of the attacker's friendship with someone in a position 
to sniff the network in question.

I assume that anyone could find a use for my credit card number. If I 
had a blog, on the other hand, it would be most interesting as a target 
for hackers that were my housemates, schoolmates, officemates, etc. 
They're the ones I would most likely piss off if I got drunk and said 
something stupid, and they know the people who would be the most 
affected by embarassing blog posts seemingly authenticated as my own. Or 
they would be the ones who made friends-only posts about what a jerk I 
am, trusting that I wasn't able to read them.

And the general public aside, my geek and pseduo-geek friends with 
homegrown blogs are the ones we have to convince to use OpenID. If they 
all wanted to use LiveJournal in the first place, OpenID wouldn't be 
necessary.