DH Support and Marketing

[Nathan D. Bowen]

Brian Smith wrote:

 > On Wed, 22 Jun 2005, Nathan D. Bowen wrote:
 >
 >> I would ask (and am asking) for your help in explaining the security
 >> benefits of allowing the unencrypted option
 >
 > The way I understood it, from emails earlier in the mailing list 
archives,
 > is that it's optional because in the case where you do have SSL on the
 > connection it's a little redundant.

I had the same understanding -- that the option to exchange keys in the 
clear was intended for connections that are already encrypted with SSL.

Paul explains (later in this thread) that an additional purpose is to 
make things easier on server implementors who can't or won't support DH, 
whether or not they will use SSL.

It's clear now that my confusion was due to the fact that the 
unencrypted option can't be considered solely in terms of real security 
benefits, because the purpose of that option is to provide 
non-security-related benefits: a reduction in CPU work or easier 
implementation (in the latter case, with at least some net *loss* in 
security).

 > I've yet to see a generic way for a CGI/PHP script to know whether the
 > connection was already secure or not.

I was thinking that since the consumer:
   - initiates the connection
   - knows whether it's connecting with http or https
   - knows whether its https library validated the server's cert
   - has the option to request DH

then the consumer can choose to send a DH request for http or to send a 
non-DH request for https. It should also refuse to negotiate with a 
server whose SSL cert doesn't validate (always a good reason to refuse 
negotiation, OpenID or otherwise).

The trouble that remains for me is that my consumer isn't guaranteed a 
DH *response* when it requests DH -- even over unencrypted HTTP.

 > If a consumer wants to refuse negotiating with a server that ignores 
the DH
 > request over an unencrypted connection, wouldn't that be up to the 
consumer?

If this part of the spec doesn't change before it's finalized, my 
consumer might very well bail out in that circumstance, but "the option 
not to interoperate" isn't as attractive to me as "the option to ensure 
the use of encryption".

So for now, I'm hoping that changes can be made to ensure that 
implementors (even those who prefer DH) will find the spec acceptable 
enough to prevent them from turning away spec-compliant peers. Any 
public OpenID implementation has a vested interest in expecting 
interoperability with all other compliant implementations.

 > Otherwise, DH is certainly much better than nothing.

I'm with you there. The remaining questions seem to be "how *much* 
better than nothing?" and "Who should be allowed to insist on DH while 
retaining the expectation of interoperability? Everybody? Consumers 
only? Or nobody?"