DH Support and Marketing (was: DH Support Optional on Servers?)

[Nathan D. Bowen]

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 
>> eavesdropping?
>
> 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 
requiring DH.

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 
and texts.

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 
secure channels?

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 
exchange?

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.