Current draft only details the value of trust roots, not encryption strength.
What's 'correct' for one may not be 'correct' for another. Security assumptions rarely make a good foundation for specs. If the protocol is subject to such a huge hole it should be spelled out. Hans -----Original Message----- From: Recordon, David Sent: Thursday, February 08, 2007 11:38 PM Pacific Standard Time To: Granqvist, Hans; David Fuelling Cc: [email protected]; [EMAIL PROTECTED] Subject: RE: [OpenID] OpenId Association Timeout Recommendations I don't think it is a reasonable assumption to make that people are going to be running SSL with a NULL cipher suite in these situations. I think the spec is quite clear in the fact that you need to do TLS/SSL right in order for it to matter. So yes, there are MITM attacks if you're on an untrusted network and not correctly using TLS/SSL. --David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Thursday, February 08, 2007 10:29 AM To: David Fuelling Cc: [email protected]; [EMAIL PROTECTED] Subject: Re: [OpenID] OpenId Association Timeout Recommendations > However, the spec seems to indicate that if SSL/TLS is used, then > Direct Verification is ok (Section 15.1.2, first line of 2nd > paragraph). Do you agree? In principle, yes, I do. But SSL is such an ephemeral notion. For instance, you can run SSL with NULL cipher suites so that traffic goes in the clear. To me, it seems that a RP that knows how to properly set up and use SSL to verify the OP (with PKI trust processing) would probably want to equally properly OpenID-associate. The original intent of DV was for usage scenarios ("ajax") where proper SSL is not normally nor easily available nor implementable. -Hans _______________________________________________ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general
_______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
