Re: removing keygen from HTML
Reto Gmür <[email protected]> Tue, 31 May 2016 21:26:58 +0200
| Newsgroups | gmane.org.w3c.tag |
|---|---|
| Message-ID | <1464722818.1487381.623940921.5591B1A2@webmail.messagingengine.com> |
This is a multi-part message in MIME format. --_----------=_146472281814873810 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 of 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. =20 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 the 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. =20 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 modular 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 cognitive 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 sign 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. =20 Cheers, Reto =20 > Myself and many others support strong cryptography and decentralized > networks of trust, and fully support that effort. Rather than > attribute the 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 NSA by building new protocols on the Web, I recommend > taking a class that explains how Web security works. Videos are > available from this MIT course 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 and 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 >> >> =20 -- Reto Gm=C3=BCr [email protected] =20 =20 --_----------=_146472281814873810 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" <!DOCTYPE html> <html> <head> <title></title> </head> <body><div>On Tue, 31 May 2016, at 14:12, Harry Halpin wrote:<br></div> <blockquote type=3D"cite"><div dir=3D"ltr"><div> </div> <div><div> </div> <div defang_data-gmailquote=3D"yes"><div>On Tue, May 31, 2016 at 1:40 AM, R= eto Gm=C3=BCr <span dir=3D"ltr"><<a href=3D"mailto:[email protected]">reto@g= muer.ch</a>></span> wrote:<br></div> <blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg= in-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-col= or:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote=3D"yes"><di= v><u></u><br></div> <div><div> </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> </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> <br></div> </div> </blockquote><div> </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><div>I had no intent to be offensive, so I would like to apolo= gize for that.<br></div> <div> </div> <div>However, I don't apologize for the idiotic part. I'm sure keygen has m= any 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 the= public key (or its hash) so that others can confirm my identity (as it hap= pens 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 ha= ppy with that.<br></div> <div> </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 modular at= tacks 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 see= m to be a way to encourage people with an appropriate cognitive model of th= e cryptographic infrastructure to go on hacking on more secure ways of comm= unicating and managing identities. I would like a majority of people to und= erstand how public and private keys are used, know how to sign and encrypt = and be competent when making decisions about trusting a party. Removing key= gen doesn't seem to promote this, however defining new standards that make = applications like WebId easier, more elegant and more secure certainly does= . <br></div> <div> </div> <div>Cheers,<br></div> <div>Reto<br></div> <div> </div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div defang_data-gmailquote= =3D"yes"><div><div>Myself and many others support strong cryptography and d= ecentralized networks of trust, and fully support that effort. Rather than = attribute the use of broken technology to protocols to NSA, it's also possi= bly due to lack of education. <br></div> <div> </div> <div>Thus, you may want to look at:<br></div> </div> <div><div> </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">http://m= erlot.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">https://www.= youtube.com/watch?v=3D_1C62Twf0vs</a><br></div> <div> </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">https://groups.google.com/a/chromium.org/forum/#!topic/b= link-dev/pX5NbX0Xack</a><br></div> </div> <div><div>Note that we're just modernizing with W3C Web Authentication secu= re and modern cryptographic one-factor authentication to use modern primiti= ves and 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 basi= cs 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 requireme= nts in Section 6 here:<br></div> <div><a href=3D"http://w3ctag.github.io/client-certificates/">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 Authentication = rather than client certs for authentication. <br></div> <div> </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> </div> <div> cheers,<br></div> <div><div> harry<br></div> </div> <div><div> </div> <div> <br></div> </div> <blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg= in-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-col= or:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote=3D"yes"><di= v><div> </div> <div>Cheers,<br></div> <div>Reto<br></div> <div><div> <br></div> </div> <div> <br></div> </div> </blockquote></div> </div> </div> </blockquote><div> </div> <div id=3D"sig46204098"><div class=3D"signature">--<br></div> <div class=3D"signature"> Reto Gm=C3=BCr<br></div> <div class=3D"signature"> [email protected]<br></div> <div class=3D"signature"> </div> </div> <div> </div> </body> </html> --_----------=_146472281814873810--