Minutes From Meeting Today

[David Strauss]

It would be more secure to have the RP attempt to fetch the secure page
first without waiting for a cue from Yadis. Given the naming conventions
you've mentioned, the RP can (usually) automatically figure out the
secure version's address.

You could attack an implementation of your proposal by substituting an
identity page that merely *doesn't* point to a secure counterpart,
forcing the RP to use the specified rogue OpenID server because it
wouldn't even know of a secure version to try.

If the RP itself attempts to fetch the secure page first without relying
on an insecure Yadis directory, an attack would have to block access to
the secure page /and/ substitute the insecure page to point to a rogue
authentication server.

Second, it's unnecessary to compare the secure and insecure pages. Once
you've downloaded a trusted, signed copy of the identity page, it
doesn't matter whether the insecure page is accurate. I guess the only
benefit of comparison would be warning the user that someone is
unsuccessfully trying to steal their identity. But you'd never be able
to warn the user of a successful attack because the secure page wouldn't
even be accessed for comparison.

- David

Recordon, David wrote:
> Considering the XRDS files used in Yadis are supposed to remain simple,
> I'd lean toward ignoring normalization and latterly run the contents
> through something like md5sum and compare the hashes.  Obviously doing
> it the "right way", just using md5sum as an example.
> 
> Maybe find a way to augment the Yadis file to say it has an equivalent
> identity URL.  Only allow http://X.example.com:Y/Z to point to
> https://X.example.com:Y/Z or http://X.example.com:Y/Z.  Then the RP
> fetches what the user typed in, grabs the Yadis file, if if points to a
> more secure (hard to define if this also allows changing the port) URL
> which fits the pattern rules (same URL with only the scheme or port
> changing) then the RP fetches that URL, gets its Yadis file, it should
> include an SSL pointer to itself (remember they should be the same
> file), then the RP compares the resulting hashes.  If they are the same,
> it uses the more secure URL, if different it alerts the user of a
> possible attack.
> 
> Something like that, at least as a 10pm concept?
> 
> --David
> 
> -----Original Message-----
> From: Granqvist, Hans 
> Sent: Monday, June 26, 2006 10:18 PM
> To: Recordon, David; Martin Atkins; yadis at lists.danga.com
> Subject: RE: Minutes From Meeting Today
> 
>> Could it be argued that if you hash the Yadis file returned at both 
>> non-SSL and SSL and it is the same then they should be treated the 
>> same?
> 
> I like the idea, if it's possible to overcome the usual
> c14n/normalization issues.
> 
> Your solution would nip in the bud more esoteric issues of "do
> https://abc.com and https://abc.com:8443 differ"
> 
> Hans
>