DH Support and Marketing

[Nathan D. Bowen]

Paul Crowley wrote:

 > In this mail, you seem to be arguing for making DH mandatory on two 
grounds:
 >
 > (1) We should follow the norm
 >
 > (2) It makes advocacy easier.

Nope, I'm suggesting that if we're not going to follow the norm, then I 
(and some others) need help to make advocacy easier.

For instance, everyone seems to be on board with straying from the 
"norm" of SSL, because it's clear that requiring SSL would contradict 
the statement that "anybody can run their own site using OpenID, and 
anybody can be an OpenID server, and they all work with each other 
without having to register with or pay anybody to 'get started'."

To less sophisticated folks like me and my colleagues, it's hard to 
understand the logical leap from "not using SSL" to "not protecting the 
secret key at all". I'm begging for some help in answering questions 
about that.

 > Please return to this laudible practice of arguing on the basis of 
real security benefits.

My understanding of the sort of active attack that could compromise the 
DH exchange is as follows.

If my consumer thinks it's performing a DH agreement with a server, but 
it's really performing a DH agreement with Mallory (who in turn can 
negotiate with the server on "behalf" of the consumer), Mallory can 
obtain the secret key without alerting the consumer.

Mallory can then use that secret to generate signatures, and this too, 
won't alert the consumer.

But what OpenID has going for it here is that other signatures are 
expected to arrive along a different channel -- from UAs that presumably 
are not all compromised by Mallory at once. Unlike in the case where an 
unencrypted secret key is passively sniffed, we can make it possible to 
alert the consumer to this active attacak as soon as any other UA shows up.

Why not have the server include a hash of the consumer's DH public value 
in every identity token intended for that consumer? Say:
       consumer_fingerprint: SHA1(consumer_dh_public)
along with everything else it signs.

If Mallory compromised the initial key exchange, the server won't have 
the consumer's DH public value -- it will have Mallory's public value. 
The consumer won't be able to validate any tokens made with the 
compromised key, because it will be checking against 
SHA1(consumer_dh_public) but the server will be sending tokens created 
with SHA1(mallory_dh_public).

Even if we understand that the DH is unauthenticated and therefore 
vulnerable to a man-in-the-middle, some of us need help understanding 
why that leads to ditching our protection against eavesdroppers instead 
of mitigating our risk of damage from a man-in-the-middle.