[security] Please convince me not to ban SSL (OP's)

[Breno de Medeiros]

This discussion also assumes that it is not possible to serve signed
discovery documents.

If OpenID decides to support the new discovery mechanisms proposed by
the XRI TC, the path to obtaining a discovery document is irrelevant,
what is relevant is the RP security posture. RPs could:

1. Only accept delegation and signin through secured discovery (which
here means that the recovered discovery documents are signed with
authoritative keys).
2. Accept both types of delegation, but assign to different URLs
different security profiles (depending on how the authentication takes
place) and prevent security level downgrades.
3. Accept all types of delegation and ignore any security signals.

Of course, each of the above postures is also possible today by
attaching security semantics to the scheme (HTTP/HTTPS). However,
because most user URLs are HTTP, it would mean that RPs that take
posture 1 would strongly limit the OPs/user URLs that can be used to
sign in to their sites. A signed, cached document can be much more
scalable for OPs/Users that cannot afford the deployment costs of an
SSL infrastructure.  The security is probably also better, because
AFAIK web server defacements are more frequent events than private key
compromises.

On Fri, May 8, 2009 at 11:42 AM, SitG Admin
<sysadmin at shadowsinthegarden.com> wrote:
>> I don't understand what you're suggesting.  If you ban both HTTP and
>> HTTPS OP what's left?
>
> I don't want to unconditionally ban HTTPS OP's, just when they're delegated
> to by a non-HTTPS URI.
>
>> I think its more helpful to think in terms of a spectrum of threats.
>> Using HTTPS for the OP but not for the identity URI is more secure
>> than using HTTP for both and less secure than using HTTPS for both.
>
> But secure against *what*?
>
> What's the attack here? What are we defending against, exactly?
>
> If the OP uses SSL that helps the user, but not us, except indirectly if
> we're worried about the user giving away their credentials to a fake OP (in
> the coffee shop model, as you said), and if their URI *doesn't* use SSL then
> the user has an illusion of security, one which may be reinforced by their
> OP.
>
> If you store data at my site (even inadvertently, indirectly, through the
> ACL that reveals which pages *I* thought you would have an interest in),
> data which is later retrievable by you, it is also retrievable by anyone who
> can *convince* me that they are you - and this attack does not care one whit
> whether your OP is using SSL or not, since your OP will never be involved.
>
> The user is concerned with attackers being able to spoof their Identity at
> *any* site, by stealing the credentials they use at their OP; the user
> *might* care little whether attackers can spoof their Identity at a specific
> RP, but if they store any personal data there they should care greatly!
>
> If the user is being reassured by their OP that they are "secure" because
> that OP uses SSL, then the user has a false sense of security. If the user
> has an HTTP URI and a HTTP OP, they probably understand the risks and are
> willing to take them. I can always assign an explanation to their ACL (even
> make the page default on first login) to make sure.
>
> -Shade toys with the idea of caching IP addresses for OP's, then throwing a
> fit if it suddenly doesn't match up
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)