<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 different attacks.<div><br></div><div>The concern is that given enough time and resources an attacker could recover a session-key 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. 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 poisoning attack against a RP to hijack the session key.</div><div><br></div><div>On the other hand given the vetting 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, SHA256 is better than SHA1, Checking the returned assertion against the discovered information is better than not.</div><div><br></div><div>Defense in depth is better than no defense. Nothing is perfect but you need to consider 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 <<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"> </span><a href="mailto:general@openid.net">general@openid.net</a><br>Message-ID: <<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 <br></blockquote><blockquote type="cite">openID 2.0 OPs to support HMAC-SHA256, they believe that HMAC-SHA1 is <br></blockquote><blockquote type="cite">sufficient. I think that if an RP ask for a SHA256 association they <br></blockquote><blockquote type="cite">should support it. (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 <br></blockquote><blockquote type="cite">are not required to. They may have a valid security reason not to <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 <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 <br></blockquote><blockquote type="cite">support HMAC-SHA256 and HMAC-SHA1 if they want to interoperate with <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"> </span></span></blockquote></div><br></div></body></html>