Re: removing keygen from HTML
Harry Halpin <[email protected]> Wed, 8 Jun 2016 02:28:13 -1000
| Newsgroups | gmane.org.w3c.tag |
|---|---|
| Message-ID | <CAE1ny+7q=_z98h7Wqt_qmu_gzoU_OfjNOxakKfGF7AmTFbbLCg@mail.gmail.com> |
--001a113e1eaa70aaf50534c370fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2016 at 9:26 AM, Reto Gm=C3=BCr <[email protected]> wrote: > On Tue, 31 May 2016, at 14:12, Harry Halpin wrote: > > > > On Tue, May 31, 2016 at 1:40 AM, Reto Gm=C3=BCr <[email protected]> wrote: > > > > On Tue, 31 May 2016, at 10:04, Harry Halpin wrote: > > I do not know anyone from the cryptographic or security community that > would support keeping <keygen>. Indeed, the default response from the > security/crypto community would be to drop <keygen> due to legacy usage o= f > MD5 and violation of security boundaries (SOP). > > > That would also be my response if I was employed by the NSA and wanted to > prevent technologies that allow user controlled strong cryptography and > decentralized networks of trust (as enabled by webId). > > > > Reto, > That was both an idiotic and offensive statement. Can you explain how > amateur crypto and home-brewed protocols that no-one in the security or > crypto community reviewed or supports is the way to fight the NSA? > > I had no intent to be offensive, so I would like to apologize for that. > Then you should not imply someone works for the NSA. So you should apologize - please follow the links as to avoid throwing out such accusations on a public mailing list. I used the term 'idiotic' to describe the idea that removing <keygen> and enforcing SOP are somehow NSA plots. In detail, we do know that insofar as crypto, used correctly and with privacy-enhancing technologies and resistance to traffic analysis, is the best way to prevent mass surveillance. SOP and extensions like CSP, SRI, etc. is the one thing that prevents arbitrary Javascript from unknown sources running in your browser, which would be a NSA dream. <keygen>, as noted is one of the few cross-origin features that manipulates browser state and violates SOP, and thus browser vendors are trying to do the right thing in terms of security and privacy by deprecating it. New W3C standards (that the TAG should both know about and support via technical review) such as WebCrypto and Web Authentication allow cryptographic authentication and cryptographic primitives to be used without violating SOP or relying on soon-to-be deprecated parts of HTML. > However, I don't apologize for the idiotic part. I'm sure keygen has many > flaws in its design, yet it allowed idiots like me to create key-pairs > without the secret key ever leaving the browser and to be able to share t= he > public key (or its hash) so that others can confirm my identity (as it > happens with WebId). If there is now an easy and elegant replacement API > that gives the user more control while still allowing what keygen allowed > I'm happy with that. > The W3C membership and myself of course support one-factor cryptographic authentication without the secret key ever leaving the browser (or better yet, never being accessed by the browser). WebCrypto allows secret keys to be non-extractable and so private from server, and Web Authentication allows access to long-term keys stored outside the browser in a way that respects SOP and never gives a browser access to the private key material. Again, both you and the TAG should be aware of WebCrypto and Web Authentication. W3C members of course support These are elegant APIs that have browser vendor support and have analysis by cryptographers and the wider Web Security community. These standards have been communicated to the TAG and WebID+TLS community years ago to give them enough time to update their protocols to not use <keygen>. It is not the fault of the browser community that WebID+TLS fans have not updated their protocols, and the use of a non-standard protocol by a few dozen people should not hold up progress that helps the security and privacy of the Web. Thus, I have poltely asked browsers not to remove <keygen> until Web Authentication is in browsers, which should be by end of the year. > > But if keygen is removed before a replacement is there,this is at very > least sending the wrong signal. Rather than contemptuously writing about > home-brewd protocols please provide home-brewer with alternatives. Idiots > like me that didn't realize that md5 is vulnerable to differential modula= r > attacks are happy to change to a more secure hashing algorithm. However > just closing the door of keygen, saying that the experts are working > doesn't seem to be a way to encourage people with an appropriate cognitiv= e > model of the cryptographic infrastructure to go on hacking on more secure > ways of communicating and managing identities. I would like a majority of > people to understand how public and private keys are used, know how to si= gn > and encrypt and be competent when making decisions about trusting a party= . > Removing keygen doesn't seem to promote this, however defining new > standards that make applications like WebId easier, more elegant and more > secure certainly does. > See above. > Cheers, > Reto > > > Myself and many others support strong cryptography and decentralized > networks of trust, and fully support that effort. Rather than attribute t= he > use of broken technology to protocols to NSA, it's also possibly due to > lack of education. > > Thus, you may want to look at: > > 1) MD5 security issues are well-known and documented: > http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf > 2) In practice, the WebID+TLS community should use modern crypto and the > Web Security model rather than attempt to build on top of an broken, > obscure, and unstandardised browser behaviour. If you want to fight the N= SA > by building new protocols on the Web, I recommend taking a class that > explains how Web security works. Videos are available from this MIT cours= e > explain modern Web Security, including the Same Origin Policy: > https://www.youtube.com/watch?v=3D_1C62Twf0vs > > Hopefully others will be more reasonable, but you may wish to familiarize > yourself with this thread rather than endlessly repeat it. > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0X= ack > Note that we're just modernizing with W3C Web Authentication secure and > modern cryptographic one-factor authentication to use modern primitives a= nd > respect user privacy. You are more than welcome to join the Working Group > as an Invited Expert, although an expert should be aware of the basics of > security. > Although there are a number of inaccuracies in this report in terms of > WebCrypto, it's pretty clear Web Authentication matches all requirements = in > Section 6 here: > http://w3ctag.github.io/client-certificates/ > Thus, it makes sense to hold off and deprecate <keygen> after the fall of > this year, when Web Authentication is deployed in browsers. As stated > earlier, the "WebID" community can simply use Web Authentication rather > than client certs for authentication. > > That being said, since the only browser that supports <keygen> currently > is Mozilla, who plans to deprecate regardless of what the TAG says, then = it > can also be justified to remove from the standard today as there is no > interoperability. > > cheers, > harry > > > > > Cheers, > Reto > > > > > -- > Reto Gm=C3=BCr > [email protected] > > > --001a113e1eaa70aaf50534c370fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, May 31, 2016 at 9:26 AM, Reto Gm=C3=BCr <span dir=3D"ltr"><<= a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>></sp= an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u> <div><span class=3D""><div>On Tue, 31 May 2016, at 14:12, Harry Halpin wrot= e:<br></div> <blockquote type=3D"cite"><div dir=3D"ltr"><div>=C2=A0</div> <div><div>=C2=A0</div> <div><div>On Tue, May 31, 2016 at 1:40 AM, Reto Gm=C3=BCr <span dir=3D"ltr"= ><<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&g= t;</span> wrote:<br></div> <blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex"><div><u></u><br></div> <div><div>=C2=A0</div> <div><span>On Tue, 31 May 2016, at 10:04, Harry Halpin wrote:</span><br></d= iv> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div><span>I do not kn= ow anyone from the cryptographic or security community that would support k= eeping <keygen>. Indeed, the default response from the security/crypt= o community would be to drop <keygen> due to legacy usage of MD5 and = violation of security boundaries (SOP). </span><br></div> </div> </div> </div> </blockquote><div>=C2=A0</div> <div>That would also be my response if I was employed by the NSA and wanted= to prevent technologies that allow user controlled strong cryptography and= decentralized networks of trust (as enabled by webId).<br></div> <div>=C2=A0<br></div> </div> </blockquote><div>=C2=A0</div> <div><div>Reto,<br></div> </div> <div><div>That was both an idiotic and offensive statement. Can you explain= how amateur crypto and home-brewed protocols that no-one in the security o= r crypto community reviewed or supports is the way to fight the NSA?<br></d= iv> </div> </div> </div> </div> </blockquote></span><div>I had no intent to be offensive, so I would like t= o apologize for that.<br></div></div></blockquote><div><br></div><div>Then = you should not imply someone works for the NSA. So you should apologize=C2= =A0 -=C2=A0 please follow the links as to avoid throwing out such accusatio= ns on a public mailing list. I used the term 'idiotic' to describe = the idea that removing <keygen> and enforcing SOP are somehow NSA plo= ts. In detail, we do know that insofar as crypto, used correctly and with p= rivacy-enhancing technologies and resistance to traffic analysis, is the be= st way to prevent mass surveillance. SOP and extensions like CSP, SRI, etc.= is the one thing that prevents arbitrary Javascript from unknown sources r= unning in your browser, which would be a NSA dream. <keygen>, as note= d is one of the few cross-origin features that manipulates browser state an= d violates SOP, and thus browser vendors are trying to do the right thing i= n terms of security and privacy by deprecating it. New W3C standards (that = the TAG should both know about and support via technical review) such as We= bCrypto and Web Authentication allow cryptographic authentication and crypt= ographic primitives to be used without violating SOP or relying on soon-to-= be deprecated parts of HTML.<br><br><br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex"><div><div></div> <div>=C2=A0</div> <div>However, I don't apologize for the idiotic part. I'm sure keyg= en has many flaws in its design, yet it allowed idiots like me to create ke= y-pairs without the secret key ever leaving the browser and to be able to s= hare the public key (or its hash) so that others can confirm my identity (a= s it happens with WebId). If there is now an easy and elegant replacement A= PI that gives the user more control while still allowing what keygen allowe= d I'm happy with that.<br></div></div></blockquote><div><br></div><div>= The W3C membership and myself of course support one-factor cryptographic au= thentication without the secret key ever leaving the browser (or better yet= , never being accessed by the browser). WebCrypto allows secret keys to be = non-extractable and so private from server, and Web Authentication allows a= ccess to long-term keys stored outside the browser in a way that respects S= OP and never gives a browser access to the private key material. Again, bot= h you and the TAG should be aware of WebCrypto and Web Authentication. W3C = members of course support=C2=A0 These are elegant APIs that have browser ve= ndor support and have analysis by cryptographers and the wider Web Security= community.=C2=A0 These standards have been communicated to the TAG and Web= ID+TLS=20 community years ago to give them enough time to update their protocols=20 to not use <keygen>. It is not the fault of the browser community tha= t WebID+TLS fans have not updated their protocols, and the use of a non-sta= ndard protocol by a few dozen people should not hold up progress that helps= the security and privacy of the Web. Thus, I have poltely asked browsers n= ot to remove <keygen> until Web Authentication is in browsers, which = should be by end of the year.=C2=A0 </div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><div><div></div> <div>=C2=A0</div> <div>But if keygen is removed before a replacement is there,this is at very= least sending the wrong signal. Rather than contemptuously writing about h= ome-brewd protocols please provide home-brewer with alternatives. Idiots li= ke me that didn't realize that md5 is vulnerable to differential modula= r attacks are happy to change to a more secure hashing algorithm. However j= ust closing the door of keygen, saying that the experts are working doesn&#= 39;t seem to be a way to encourage people with an appropriate cognitive mod= el of the cryptographic infrastructure to go on hacking on more secure ways= of communicating and managing identities. I would like a majority of peopl= e to understand how public and private keys are used, know how to sign and = encrypt and be competent when making decisions about trusting a party. Remo= ving keygen doesn't seem to promote this, however defining new standard= s that make applications like WebId easier, more elegant and more secure ce= rtainly does. <br></div></div></blockquote><div><br></div><br></div><div cl= ass=3D"gmail_quote">See above. <br><br></div><div class=3D"gmail_quote"><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div> <div>=C2=A0</div> <div>Cheers,<br></div> <div>Reto<br></div><span class=3D""> <div>=C2=A0</div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div><div>Myself and m= any others support strong cryptography and decentralized networks of trust,= and fully support that effort. Rather than attribute the use of broken tec= hnology to protocols to NSA, it's also possibly due to lack of educatio= n. <br></div> <div>=C2=A0</div> <div>Thus, you may want to look at:<br></div> </div> <div><div>=C2=A0</div> <div>1) MD5 security issues are well-known and documented:<br></div> <div><a href=3D"http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf" target= =3D"_blank">http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf</a><br></div> </div> <div><div>2) In practice, the WebID+TLS community should use modern crypto = and the Web Security model rather than attempt to build on top of an broken= , obscure, and unstandardised browser behaviour. If you want to fight the N= SA by building new protocols on the Web, I recommend taking a class that ex= plains how Web security works. Videos are available from this MIT course ex= plain modern Web Security, including the Same Origin Policy:<br></div> <div><a href=3D"https://www.youtube.com/watch?v=3D_1C62Twf0vs" target=3D"_b= lank">https://www.youtube.com/watch?v=3D_1C62Twf0vs</a><br></div> <div>=C2=A0</div> <div>Hopefully others will be more reasonable, but you may wish to familiar= ize yourself with this thread rather than endlessly repeat it. <br></div> <div><a href=3D"https://groups.google.com/a/chromium.org/forum/#!topic/blin= k-dev/pX5NbX0Xack" target=3D"_blank">https://groups.google.com/a/chromium.o= rg/forum/#!topic/blink-dev/pX5NbX0Xack</a><br></div> </div> <div><div>Note that we're just modernizing with W3C Web Authentication = secure and modern cryptographic one-factor authentication to use modern pri= mitives and respect user privacy. You are more than welcome to join the Wor= king Group as an Invited Expert, although an expert should be aware of the = basics of security. <br></div> </div> <div><div>Although there are a number of inaccuracies in this report in ter= ms of WebCrypto, it's pretty clear Web Authentication matches all requi= rements in Section 6 here:<br></div> <div><a href=3D"http://w3ctag.github.io/client-certificates/" target=3D"_bl= ank">http://w3ctag.github.io/client-certificates/</a><br></div> </div> <div><div>Thus, it makes sense to hold off and deprecate <keygen> aft= er the fall of this year, when Web Authentication is deployed in browsers. = As stated earlier, the "WebID" community can simply use Web Authe= ntication rather than client certs for authentication. <br></div> <div>=C2=A0</div> <div>That being said, since the only browser that supports <keygen> c= urrently is Mozilla, who plans to deprecate regardless of what the TAG says= , then it can also be justified to remove from the standard today as there = is no interoperability. <br></div> </div> <div>=C2=A0</div> <div>=C2=A0=C2=A0 cheers,<br></div> <div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 harry<br></div> </div> <div><div>=C2=A0</div> <div>=C2=A0<br></div> </div> <blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex"><div><div>=C2=A0</div> <div>Cheers,<br></div> <div>Reto<br></div> <div><div>=C2=A0<br></div> </div> <div>=C2=A0<br></div> </div> </blockquote></div> </div> </div> </blockquote><div>=C2=A0</div> </span><div><div>--<br></div> <div>=C2=A0 Reto Gm=C3=BCr<br></div> <div>=C2=A0 <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= h</a><br></div> <div>=C2=A0</div> </div> <div>=C2=A0</div> </div> </blockquote></div><br></div></div> --001a113e1eaa70aaf50534c370fd--