[OpenID] D-H vs SSL

[Peter Williams]

What is that price?

Its zero, today. DDNS registers the current DHCP address from the DOCSIS/DSLAM multiplexor at the CO, and one uses the wifi router to define ones persistent domain suitable for https URI.

I know folks are trained to think in VeriSign mantra (that all CA work has to be a giant national infrastructure- with entierprise corporate practices and trillion dollar warranties. Bbut don't fall into that trap - in a UCI space. Just think like of home wifi router, as your OP (or the vanity discovery point).

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Allen Tom
Sent: Thursday, March 19, 2009 11:57 AM
To: Andrew Arnott; OpenID List
Cc: Martin Atkins
Subject: Re: [OpenID] D-H vs SSL

The DIY ethic of OpenID is also one of its main strengths, as as Johannes pointed out, there are plenty of scenarios where someone might want to run an OP without HTTPS. For instance, I'm not willing to pay the price to support HTTPS on my own personal domain.

As I mentioned earlier, I only brought up DH because I felt that it could be something that could be removed from the core spec, with the goal of making the spec lighter. Given the discussion so far, it looks like there are good reasons for keeping DH in the spec.

Allen


Andrew Arnott wrote:
Well, the spec allows for session types to be implemented that are not defined in the spec.  If DH is ever removed from the OpenID spec, I hope the spec can reference another DH spec that keeps it alive as a spec that people can optionally implement.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

2009/3/19 Allen Tom <atom at yahoo-inc.com<mailto:atom at yahoo-inc.com>>
If we consider OAuth's secret exchange mechanism for HMAC-SHA1 sigs,

 *   OAuth Service Providers usually issue a Consumer Secret to the developer, without any input from the developer. (hopefully via HTTPS)
 *   OAuth Request Token and Access Token secrets are issued by the Service Provider to the Consumer (also, hopefully via HTTPS), without any input from the Consumer
Returning cleartext secrets via HTTPS would be consistent with OAuth.

Although DH on top of SSL is safer than cleartext and SSL, is the overhead of having the spec discuss DH worth it? If the OP is unable to generate a strong secret on its own, or if the transport layer between the RP and OP cannot be secured using HTTPS, then arguably the entire system has issues.

I only mention DH, not because I have an issue with DH, but because one of OpenID's most desirable traits is its relative simplicity. The spec is pretty straightforward, and it's not all that hard to implement. Sites that want a richer (and more complicated) SSO protocol standard have alternatives that are already in production and are widely used.

Allen


Ben Laurie wrote:


Ah. I see.



So, I am going to be lazy, because I have not checked the spec, but

its considered good practice when establishing a shared secret for

both sides to contribute to that secret. Is that true for the

cleartext secret?





_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090319/597fb619/attachment-0002.htm>