DH Support and Marketing
Nathan D. Bowen
nbowen+yadis at andtonic.com
Thu Jun 23 15:16:03 PDT 2005
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
> 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
> 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
> request over an unencrypted connection, wouldn't that be up to the
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?"
More information about the yadis