DH Support and Marketing
Nathan D. Bowen
nbowen+yadis at andtonic.com
Wed Jun 22 12:05:06 PDT 2005
Paul Crowley wrote:
> In this mail, you seem to be arguing for making DH mandatory on two
> (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
> 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:
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
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.
More information about the yadis