<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 3:23 AM, Feng Hao <span dir="ltr"><<a href="mailto:feng.hao@newcastle.ac.uk" target="_blank">feng.hao@newcastle.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div><div>
<div>
<p class="MsoNormal"> * PAKE for the web has been attempted in TLS (RFC 5054) with little interest from browsers or sites. Partly this is a layering problem (username in clear, too early in the connection, and the TLS terminator is the wrong place for client
auth). But there are deeper UI problems: browsers would have to display an unspoofable dialog; users would have to be trained to enter certain passwords only into this dialog; and sites would lose control of login UI. Client auth for the web seems likely
to evolve in other directions (e.g. password managers, 2-factor, federation).<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,112,192)">The web UI is indeed a major issue. It should be possible for the web browser to add a trusted UI for entering passwords (e.g., possibly in the address bar
next to the web address where you click to find out the certificate details). But still, the question is how to educate ordinary users to *only* use this trusted interface for password entry. If a phishing website displays a password field in the web page
and asks users to enter the password, then the PAKE mechanism is entirely bypassed and becomes useless.</span></p></div></div></div></div></div></div></blockquote><div><br></div><div>Yeah, because of these difficulties browsers don't seem interested:</div>
<div><br></div><div><a href="http://www.ietf.org/mail-archive/web/tls/current/msg11586.html" target="_blank">http://www.ietf.org/mail-archive/web/tls/current/msg11586.html</a><br></div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt"><div><div><div>
<div>
<p class="MsoNormal"> * SSH already has J-PAKE which (I think?) is rarely used, though I'm not sure why. If part of the reason is performance, is there room for improvement here?<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,112,192)">I don’t think performance is any issue. I guess the main concern may be that J-PAKE has not been formally standardized. I submitted an initial proposal (<a href="http://homepages.cs.ncl.ac.uk/feng.hao/files/RationaleForJPAKE.pdf" target="_blank">http://homepages.cs.ncl.ac.uk/feng.hao/files/RationaleForJPAKE.pdf</a>)
to the UK standards committee meeting last month in Feb, and it passed the preliminary review; next month, I’m going to present J-PAKE, as the UK input, to ISO/IEC at the international SC27 meeting (<a href="http://www.sc27.hk/" target="_blank">http://www.sc27.hk/</a>).</span></p>
</div></div></div></div></div></div></blockquote><div><br></div><div><div>Hmm. It seems J-PAKE wasn't compiled into OpenSSH by default, and was removed entirely ~2 months ago?</div>
<div><br></div><div><a href="http://comments.gmane.org/gmane.os.openbsd.cvs/127043" target="_blank">http://comments.gmane.org/gmane.os.openbsd.cvs/127043</a></div><div><br></div><div>I believe OpenSSH has made curve25519 their default key exchange, so they seem willing to support crypto that isn't blessed by "official" standards. I'd be surprised if approval by "ISO/IEC 11770-4" (which I'd never heard of) makes a difference.</div>
<div><br></div><div><a href="http://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/" target="_blank">http://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/</a></div>
<div><br></div><div>Perhaps PAKE isn't desirable for SSH? If anyone knows the right people to ask at OpenSSH, I'd like to know their thinking.</div></div><div><br></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt">
<div><div><div>
<div>
<p class="MsoNormal"> * IEEE 802.11s I think has standardized on "Simultaneous Authentication of Equals" (aka Dragonfly) as an EC PAKE. I don't know if it's seen real deployment, nor do I understand the "mesh networking" scenario it's being used for, which
seems different from just authenticating a client to an AP. Anyone know more?<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:rgb(0,112,192)">I don’t think the EC version of Dragonfly is fully specified. It is derived from SPEKE, and has the same issues as SPEKE when it comes to both DL and EC implementations (the file in the above link gives a bit
more details).</span></p></div></div></div></div></div></div></blockquote><div><br></div><div><div>Are you claiming that EC-Dragonfly in 802.11s is not "fully specified"?</div><div><br></div><div>I just downloaded 802.11s ($260!). It seems to fully describe Dragonfly over "FFC" and "ECC" groups. In fact, NIST P-256 is the mandatory-to-implement group.</div>
<div><br></div><div><a href="http://standards.ieee.org/findstds/standard/802.11s-2011.html" target="_blank">http://standards.ieee.org/findstds/standard/802.11s-2011.html</a></div><div><br></div><div>What I don't know is how much deployment this is seeing?</div>
</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt"><div><div><div><div><p class="MsoNormal">Anyways, it's not clear that there are strong-enough use cases to motivate a good discussion and keep it on track. Though I wish there were! PAKEs are cool, it seems like they should be useful somewhere.<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,112,192)">I believe there are useful use cases in certain applications. Currently, I’m supervising an undergraduate student project. The student is developing a secure
messaging app for Android. The app establishes a secure E2E communication channel with another Android phone user via a google cloud after both users enter the same short code at two phones. The encryption is end-to-end, so no third parties, including Google,
ISP etc, are able to eavesdrop. The app is based on J-PAKE (using the existing boucycastle implementation). We plan to release the app for free when the project is done, possibly, in the next 2-3 months.</span></p></div>
</div></div></div></div></div></blockquote><div><br></div><div>[You also wrote, later]:</div><div>"""</div><div><span style="color:rgb(0,112,192);font-family:Calibri,sans-serif;font-size:14.44444465637207px">They may speak over the phone: hey, do you still remember the day when we went to see that scary movie together? Let’s use that date as the password to start secure chatting now so no one will know what we are talking about.</span><br>
</div><div><span style="color:rgb(0,112,192);font-family:Calibri,sans-serif;font-size:14.44444465637207px">"""</span></div><div><div><br></div></div><div>OK, so this is basically the OTR / Socialist Millionaire's case:</div>
<div><br></div><div><a href="http://www.cypherpunks.ca/~iang/pubs/impauth.pdf">http://www.cypherpunks.ca/~iang/pubs/impauth.pdf</a><br></div><div><br></div><div>I don't know whether that's been a good user experience or not, perhaps that's a question for the "messaging" list...</div>
<div><br></div><div><br></div><div>Trevor</div><div><br></div></div></div></div>