that ess in 'https'

[David Strauss]

1. If the https page exists, it's only one fetch.
2. The http redirect you suggest would result in two fetches for the
https case (granted, they'd be more automated because of the redirect)
and only one for the http case. This would optimize for the http case,
which I hope isn't the common one. We should "make the common case
fast," as the CS design rule goes.
3. Fetching http first allows an easier compromise of the system: all
the attacker needs to do is forge the http page so there's no redirect.
The "fetching https first" method would require blocking the https fetch
and forging the http page to be compromised. Granted, it's not much harder.
4. The "fetch https first" method wouldn't break existing RPs. In fact,
I'd approach the method as a recommended practice more than a requirement.
5. A redirect to the https page would break RPs that can't fetch https
pages. This may not be a problem if we begin requiring RPs to have
https-fetching capability.

- David

Recordon, David wrote:
> My concern with "try https first" is it adds another required fetch for each RP.
>  
> --David
> 
> ________________________________
> 
> From: yadis-bounces at lists.danga.com on behalf of David Strauss
> Sent: Tue 6/27/2006 3:00 PM
> To: Martin Atkins
> Cc: yadis at lists.danga.com
> Subject: Re: that ess in 'https'
> 
> 
> 
> Martin Atkins wrote:
>> David Strauss wrote:
>> I think my favourite solution right now is to require relying parties to
>> support SSL and then use the existing "canonicalization through
>> redirection" feature of OpenID to solve this problem. The problem that
>> doesn't address is where an identity provider starts off on cleartext
>> and migrates to SSL, which admittedly I don't have a good answer to.
> 
> I don't like the redirection system because it still makes an insecure
> hop. It would be more secure to try the https scheme first. I don't see
> why people are resistant to this. The only restriction is that you can't
> have different identities distinguished only by scheme.
> 
> 
> 
>