DH Support and Marketing

[Nathan D. Bowen]

Paul Crowley wrote:

 > My point about advocacy stands.

I think I understood your point about advocacy, but I'm still asking for 
help.

You seem quite confident that it will be okay for OpenID to send 
unencrypted secret keys without worrying about eavesdroppers.

Please understand that this idea can be counterintuitive to others -- 
understandably so, I think, given the conventional wisdom about handling 
secret keys.

I would not ask you to compromise the protocol's security just to make 
it more intuitive.

I would ask (and am asking) for your help in explaining the security 
benefits of allowing the unencrypted option, because I don't understand 
it and I'm having trouble explaining it to others.

If the unencrypted option is only a red flag to "those who don't know 
much about it", I've got a feeling that it will be a red flag for a lot 
of potential implementors.

 > I'm not proposing we ditch DH, I'm proposing we make it optional.  What
 > practical advantage of making it mandatory do you anticipate?

Maybe this should wait, since the following may only make sense given my 
view that it's preferable to protect a secret key from eavesdropping. If 
I come to understand that encryption won't be advantageous, I'm sure I 
wouldn't consider it advantageous to mandate it.

I'll explain the practical advantage I anticipate, with the caveat that 
I'm starting from the preconceptions stated above.

I see it as an issue of interoperability (the "they all work with each 
other" part from the OpenID homepage).

If consumers have the option to request cleartext key exchanges, a 
server can't protect its keys from eavesdroppers without occasionally 
turning away spec-compliant consumers (or dropping the cash for SSL).

If servers have the option to ignore a request for encryption, a 
consumer can't protect all its servers' keys without occasionally 
turning away spec-compliant servers.

Whether or not the use of encryption is mandated, I at least assumed 
that OpenID would mandate that servers support encryption when it's 
requested. This would give consumers cleartext if they insist on 
cleartext and encryption if they insist on encryption.

To me, SSL seems like a needlessly expensive option. But at least SSL 
provides a server-side option to people like me. If servers can ignore 
consumers' requests for encryption, there's no consumer-side option that 
guarantees encryption to people like me.

I thought the compromise was to ensure that concerned parties could use 
encryption if they desired, and I'm disappointed to see that the 
compromise only allows consumers to suggest encryption and hope for the 
best.