[OpenID] D-H vs SSL

[Andrew Arnott]

No.  It's not true for any association method that's defined in the spec,
whether SSL, DH or plain-text is used.  The OP entirely determines the
secret.  DH or SSL is only used to secure transmission of that secret to the
RP.
--
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 Ben Laurie <benl at google.com>

> On Thu, Mar 19, 2009 at 5:22 PM, Martin Atkins <mart at degeneration.co.uk>
> wrote:
> > Ben Laurie wrote:
> >>
> >> On Thu, Mar 19, 2009 at 2:17 PM, Andrew Arnott <andrewarnott at gmail.com>
> >> wrote:
> >>>
> >>> Maybe it's just me, but I don't like the terminology we're using.  DH
> and
> >>> SSL are only redundant when used together.
> >>
> >> I don't understand why. As I said, DH over SSL gives you a shared
> >> secret, which SSL alone does not. Of course there are cheaper ways to
> >> arrive at a shared secret over SSL, but that's not the point.
> >>
> >>>  Otherwise they're complementary.
> >>>  If SSL cannot be used, for whatever reason, DH is mandatory.
> >>
> >> But does not protect against MitM, and so is not equivalent. Which is
> >> not what "complementary" means to me.
> >>
> >
> > I believe what's being discussed here is using the secure channel to
> > exchange a shared secret in "cleartext" (as far as the application layer
> is
> > concerned).
> >
> > This is actually already permitted by the spec, but the spec does not say
> > that it is *required* to use the "cleartext" session mode when on a
> secure
> > channel. This is the change that I think is being proposed here.
>
> 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?
>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090319/506c817c/attachment-0002.htm>