DH Support and Marketing (was: DH Support Optional on Servers?)
Nathan D. Bowen
nbowen+yadis at andtonic.com
Tue Jun 21 21:21:56 PDT 2005
Paul Crowley wrote:
> Nathan D. Bowen wrote:
>> Is this correct? Servers are not required to support DH at all, and a
>> consumer requesting a DH session is only suggesting the use of DH,
>> regardless of whether the connection is otherwise protected from
> That's my intent. Note that anywhere the attacker can perform a
> protocol rollback attack, they can tamper with the DH session
> parameters and sniff the session that way.
Right, we're susceptible to the same active attacks with or without
I don't understand how that enters into a discussion on whether or not
to protect ourselves against passive eavesdroppers.
I assumed we would choose the option that protects us against
eavesdroppers and then move on to minimize our risk from active attackers.
Sharing a secret key for encryption is not a new problem, and there are
plenty of examples of solutions to that problem in existing protocols
This is honestly the first time I've encountered any advocacy for the
"just send it over unsecured HTTP" solution.
So even if we set aside the discussion of whether or not it's "safe" for
us to just send it over unsecured HTTP, can someone at least confirm or
deny that we're going against the grain here?
Is there some respected protocol in use on the Internet that uses
encryption but doesn't bother to protect the secret key?
Are there texts or articles on cryptology that contradict the
conventional wisdom that secret keys should only be transmitted over
If so, I'm obviously in desperate need of pointers to those resources,
and I'll happily study up.
If not, I can't think of a single benefit for OpenID in breaking from
the norm on this question.
Being an advocate for OpenID among my colleagues has become a chore now
that I have to also advocate for "optional encryption of secret keys".
Does anyone else have any experience with that? Have I overlooked a
really easy way to sell people on the idea of unencrypted secret key
For my purposes, I think I can sidestep the issue by using an
implementation that breaks from the spec by requiring DH, because my
current plans are for small private networks of sites.
I'm more concerned about people who hope to use OpenID truly distributed
in the wild. If we want to convince them to build their implementation
to this specification, we'll have to convince them that unencrypted
secret keys aren't so bad, despite what they probably think.
It sounds to me like a barrier to adoption that OpenID doesn't need.
More information about the yadis