[OpenID] Reconsidering http://openid different from https://openid

[Johnny Bufu]

On 19-Sep-07, at 12:24 PM, George Fletcher wrote:
> Johnny Bufu wrote:
>>
>> On 19-Sep-07, at 7:07 AM, George Fletcher wrote:
>>
>>> But isn't that a choice of the RP?  The RP could allow the user  
>>> to select an option that says that only https identifiers are  
>>> allowed.  That would protect the user from the attack of someone  
>>> using an http identifier.  This could be the default option and  
>>> the user could turn it off if they want.
>>
>> OpenID being user-centric, and the user being the "owner" of the  
>> identifier, I'd say it should be the user's choice.
>>
> If the user selects that only HTTPS identifiers are to be used...  
> how is the user not in control?

If the RP doesn't prompt the user (because it doesn't care between  
the difference, etc), the user doesn't have the choice to trigger the  
prompt or otherwise convey that the HTTP/HTTPS difference is  
important to them.

> I agree that many users might not understand the difference, but  
> the user choice doesn't have to be described at the technology  
> level.  It could be like the IE "security slider".
>> I can see two issues with what you're proposing:
>> - how many users will have the knowledge to make the right choice  
>> when prompted by the RP?
>> - the user has no choice at those RPs who don't care about HTTP/ 
>> HTTPS differences, and don't prompt the user for making the choice.
>>
>> I agree the RPs should be allowed to decide authorization and  
>> policies, but my feeling is that the protocol should put the user  
>> in control over features that impact the security of the identifiers.
>>
> For those RPs that don't care, the user can always use whichever  
> they want.  The user can always use a HTTPS identifier at all  
> sites.  In fact, they may chose not to interact with any site that  
> doesn't support an HTTPS identifier.

At the same time, their HTTPS identity will be vulnerable to DNS  
attacks, thus negating the security advantages of HTTPS / TLS.

> If we are taking a choice away, it is the choice to have two  
> different accounts at an RP where the only difference is HTTP vs  
> HTTPS.  Is that a bad choice to take away?

That's not the only one. The other is the choice not to degrade the  
security of HTTPS identifiers to the one associated with HTTP  
identifiers, at a global level.

>>> I agree that if an https identifier exists, then an http  
>>> identifier with a different OP should not be allowed.
>>
>> How is an RP able to tell that a HTTPS identifier exists, when the  
>> attacker presents the HTTP identifier for the first time to it,  
>> after having compromised the DNS such that the HTTPS identifier is  
>> no longer reachable?
> You are right. It can't.

I consider this a show stopper, and believe this is the point that  
Josh wanted to make initially: the attacker would be able to  
impersonate the user at RPs that haven't seen the HTTPS identifier  
before, or at RPs that don't care about the difference.

> It might try and do some resolution when it does receive a HTTPS  
> identifier that matches an existing HTTP identifier.  This again  
> could be an RP policy.  Due to association handles, the RP should  
> know which OP authenticated the existing account identifier.  The  
> RP could use that knowledge to "merge" or "block" the HTTPS based  
> attempt.
>>
>>> It seems like it should be possible to "upgrade" an http to and  
>>> https identifier (provided some criteria is met; e.g. the same OP  
>>> is used for both identifiers?, the same association handle is  
>>> used for both?).
>>
>> Yes, upgrading would be great if it can be made to work nicely.
> So what is hindering the process from "working nicely"?  If the OP  
> is the same, and the association handle is the same, then both are  
> verified by the same OP.  I guess the only other "requirement"  
> would be for the OP to make a statement that the two identifiers  
> are really the same.

RP adoption I guess? RPs can prompt the users and consolidate two  
accounts associated with HTTP and HTTPS identifiers today if they so  
desire, even without any change to the OpenID spec. They will still  
be treating the two identifiers as different as far as the OpenID  
protocol is concerned, just bind them to the same RP account.

> Of course, this would cause a problem if the user is running their  
> own web site and wants to use a different OP for "secure"  
> transactions vs "insecure" transactions. Meaning http:// 
> alice.personal.example resolves to one OP and https:// 
> alice.personal.example resolves to a more secure but different OP.   
> However, this is a small edge case and supporting it seems like it  
> adds more complications than it solves.
>>
>>> However, if an https identifier exists (i.e. the user explicitly  
>>> used an https identifier in the past) then an http identifier  
>>> shouldn't be accepted.  If the user chose to use https at least  
>>> once in the past, why would the RP want to allow the user to now  
>>> use http for the same identifier?
>>
>> If I stop paying for a dedicated IP address and a certificate, I  
>> won't be able to use http://my.blog.com/ as my (new) identifier at  
>> the RPs where I've used https://my.blog.com/ ?
> This I agree is a problem... but then your (new) http://my.blog.com  
> would be a new identity at the RPs so you would have lost all your  
> data anyway (in the current spec).

Yes - if I loose my identity, I loose the data associated with it.  
The RP policy you are proposing also prevents me from starting over  
with a new identity backed by the same domain name.

> I believe what Johannes was proposing would allow you to actually  
> get to your data at the RP. Though then you have the security/ 
> spoofing points you pointed out.

Yes, it does so by degrading the security of HTTPS identifiers to HTTP.

> I guess I have to wonder, how many of the "mass market" consumers  
> will run their own OP, or their own web site that they use as the  
> OpenID.

Blogs delegating to third-party OPs would be affected as well.

> Also, to be "secure" doesn't the whole delegation chain have to be  
> over HTTPS?  If I have https://alice.personal.example and it  
> delegates to http://op.example with an id of http:// 
> alice.op.example, wouldn't the same DNS spoofing hacks apply?

Yes, I agree here.


Johnny