<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The message signature and transport encryption protect against&nbsp;different&nbsp;attacks.<div><br></div><div>The concern is that given enough time and resources an attacker could recover a&nbsp;session-key&nbsp;given the well documented weaknesses in SHA1.</div><div>Even with the known weakness this would be incredibly difficult if the keys are rotated regularly. &nbsp;SSL can't protect against this.</div><div><br></div><div>Without SSL protecting the discovery step I would opt for the much easier DNS&nbsp;poisoning&nbsp;attack against a RP to hijack the session key.</div><div><br></div><div>On the other hand given the&nbsp;vetting&nbsp;practices of some CAs it is not impossible to imagine that a cert could not be acquired for almost any domain.</div><div><br></div><div>So SSL is better than no ssl, &nbsp;SHA256 is better than SHA1, &nbsp;Checking the&nbsp;returned&nbsp;assertion against the&nbsp;discovered&nbsp;information is better than not.</div><div><br></div><div>Defense in depth is better than no&nbsp;defense. &nbsp;Nothing is perfect but you need to&nbsp;consider&nbsp;the security and cost of the whole system vs the value of what you are protecting.</div><div><br></div><div>Regards</div><div>John Bradley</div><div><br></div><div><div><div>On 2-Apr-09, at 11:20 PM, <a href="mailto:general-request@openid.net">general-request@openid.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Message: 6<br>Date: Thu, 2 Apr 2009 23:10:19 -0700 (PDT)<br>From: santrajan &lt;<a href="mailto:santrajan@gmail.com">santrajan@gmail.com</a>><br>Subject: Re: [OpenID] My 2 Cents to the OpenID foundation<br>To:<span class="Apple-converted-space">&nbsp;</span><a href="mailto:general@openid.net">general@openid.net</a><br>Message-ID: &lt;<a href="mailto:22862548.post@talk.nabble.com">22862548.post@talk.nabble.com</a>><br>Content-Type: text/plain; charset=us-ascii<br><br><br>I am surprised that a large OP like myspace has chosen not to use transport<br>layer security at their endpoint. SHA1 would have a been a lesser risk if<br>they had chosen to do so.<br><br><br>John Bradley-7 wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yahoo and I have an ongoing disagreement over the requirement for &nbsp;<br></blockquote><blockquote type="cite">openID 2.0 OPs to support HMAC-SHA256, &nbsp;they believe that HMAC-SHA1 is &nbsp;<br></blockquote><blockquote type="cite">sufficient. I think that if an RP ask for a SHA256 association they &nbsp;<br></blockquote><blockquote type="cite">should support it. &nbsp;(Allen feel free to defend yourself:)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think it would be a good idea for myspace to support both but they &nbsp;<br></blockquote><blockquote type="cite">are not required to. &nbsp;They may have a valid security reason not to &nbsp;<br></blockquote><blockquote type="cite">allow fallback to HMAC-SHA1.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I could buy that argument more easily than forcing an RP to a smaller &nbsp;<br></blockquote><blockquote type="cite">hash.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So my take on it for what it is worth, is that openID 2.0 RPs must &nbsp;<br></blockquote><blockquote type="cite">support HMAC-SHA256 and HMAC-SHA1 if they want to interoperate with &nbsp;<br></blockquote><blockquote type="cite">all OPs.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br>--<span class="Apple-converted-space">&nbsp;</span></span></blockquote></div><br></div></body></html>