Re: removing keygen from HTML
Reto Gmür <[email protected]> Wed, 08 Jun 2016 16:09:28 +0200
| Newsgroups | gmane.org.w3c.tag |
|---|---|
| Message-ID | <1465394968.3129687.631576009.4E75CF43@webmail.messagingengine.com> |
This is a multi-part message in MIME format. --_----------=_146539496931296870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wed, 8 Jun 2016, at 14:28, Harry Halpin wrote: > > > 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 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. > > Then you should not imply someone works for the NSA. So you should > apologize It was not my intend to imply that you work for the NSA I do apologize that=C2=A0 I formulated my sentence so poorly that - as I realize now - someone could deduct that you work for the NSA. To be explicit: I do not believe nor did I used to believe that you work for the NSA or=C2=A0 worked for the NSA. =20 I do however believe that the NSA did try to influence standardization processes to create weaker security and probably still are. I also believe that they would always pretend to increase security while their actual intent is to postpone secure technology and reduce the chances they are adopted or implemented without vulnerabilities such as by increasing complexity. =20 > -=C2=A0 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. I completely agree that SOP is an essential security feature for code downloaded from a website and running in the browser=C2=A0 without the user= 's explicit consent. If a webpage could use keygen to generate a key and this key is installed to the keystore and subsquently used on other sites without the user's explicit consent this would violate the user's privacy. However I haven't seen a browser doing this like that, in my experience user's consent is required both when installing the certificate as well as when using the certificate. With this user interaction there isn't the possibility to secretly track a user's cross domain activity. =20 If one wants to dogmatically apply SOP one should also cry havoc if a browser downloaded from microsoft.com can access sites outside the microsoft domain. =20 =20 > 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. =20 - Webcrypto is not a proposed recommendation yet and the document warns that it is unstable. -=C2=A0 The Web Authentication working group has not yet releases a spec and depends on the Credential Management API which is still in the draft phase. - "soon-to-be deprecated": this seems to be kind of begging the question, in my opinion it shouldn't be deprecated before better alternatives have become standards and after deprecation it shouldn't be removed for a period long enough to allow users and implementors to transition. =20 =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. > > 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=C2=A0 These are elegant APIs that have browser vendor > support and have analysis by cryptographers and the wider Web Security > community.=C2=A0 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. I'm really confused now, searching the W3C site for "Web Authentication" I find the working group. On the WG page there's a link to the deliverables that points to https://github.com/w3c/webauthn/blob/master/PubStatus.md which doesn't list any deliverable yet. =20 Is there a standard that allows me to create a key-pair, advertise my public key, have other sign it and use the keypair for authenticating with (potentially) any=C2=A0 websites as well as to sign the keys of others? =20 Cheers, Reto =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. > > See above. >> >> >> Cheers, >> Reto >> >> >>> 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/pX5NbX= 0Xack >>> 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 >>>> >>>> >> >> >> -- >> Reto Gm=C3=BCr >> [email protected] >> >> =20 -- Reto Gm=C3=BCr [email protected] =20 =20 --_----------=_146539496931296870 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" <!DOCTYPE html> <html> <head> <title></title> </head> <body><div>On Wed, 8 Jun 2016, at 14:28, 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 9:26 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 14:12, Harry Halpin wrote:</span><br></d= iv> <blockquote type=3D"cite"><div dir=3D"ltr"><div> <br></div> <div><div> <br></div> <div><div><span>On Tue, May 31, 2016 at 1:40 AM, Reto Gm=C3=BCr <span dir= =3D"ltr"><<a href=3D"mailto:[email protected]">[email protected]</a>></span> = wrote:</span><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;"><div><span><u></u></span><br></div> <div><div> <br></div> <div><span><span>On Tue, 31 May 2016, at 10:04, Harry Halpin wrote:</span><= /span><br></div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div><span><span>I do = not know anyone from the cryptographic or security community that would sup= port keeping <keygen>. Indeed, the default response from the security= /crypto community would be to drop <keygen> due to legacy usage of MD= 5 and violation of security boundaries (SOP). </span></span><br></div> </div> </div> </div> </blockquote><div> <br></div> <div><span>That would also be my response if I was employed by the NSA and = wanted to prevent technologies that allow user controlled strong cryptograp= hy and decentralized networks of trust (as enabled by webId).</span><br></d= iv> <div><span> </span><br></div> </div> </blockquote><div> <br></div> <div><div><span>Reto,</span><br></div> </div> <div><div><span>That was both an idiotic and offensive statement. Can you e= xplain how amateur crypto and home-brewed protocols that no-one in the secu= rity or crypto community reviewed or supports is the way to fight the NSA?<= /span><br></div> </div> </div> </div> </div> </blockquote><div> </div> <div>I had no intent to be offensive, so I would like to apologize for that= .<br></div> </div> </blockquote><div> </div> <div><div>Then you should not imply someone works for the NSA. So you shoul= d apologize <br></div> </div> </div> </div> </div> </blockquote><div>It was not my intend to imply that you work for the NSA I= do apologize that I formulated my sentence so poorly that - as I rea= lize now - someone could deduct that you work for the NSA. To be explicit: = I do not believe nor did I used to believe that you work for the NSA or&nbs= p; worked for the NSA.<br></div> <div> </div> <div>I do however believe that the NSA did try to influence standardization= processes to create weaker security and probably still are. I also believe= that they would always pretend to increase security while their actual int= ent is to postpone secure technology and reduce the chances they are adopte= d or implemented without vulnerabilities such as by increasing complexity.<= br></div> <div> </div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div defang_data-gmailquote= =3D"yes"><div><div> - please follow the links as to avoid throwing ou= t such accusations on a public mailing list. I used the term 'idiotic' to d= escribe the idea that removing <keygen> and enforcing SOP are somehow= NSA plots. In detail, we do know that insofar as crypto, used correctly an= d with privacy-enhancing technologies and resistance to traffic analysis, i= s the best way to prevent mass surveillance. SOP and extensions like CSP, S= RI, etc. is the one thing that prevents arbitrary Javascript from unknown s= ources 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. <br></div> </div> </div> </div> </div> </blockquote><div>I completely agree that SOP is an essential security feat= ure for code downloaded from a website and running in the browser wit= hout the user's explicit consent. If a webpage could use keygen to generate= a key and this key is installed to the keystore and subsquently used on ot= her sites without the user's explicit consent this would violate the user's= privacy. However I haven't seen a browser doing this like that, in my expe= rience user's consent is required both when installing the certificate as w= ell as when using the certificate. With this user interaction there isn't t= he possibility to secretly track a user's cross domain activity.<br></div> <div> </div> <div>If one wants to dogmatically apply SOP one should also cry havoc if a = browser downloaded from microsoft.com can access sites outside the microsof= t domain.<br></div> <div> </div> <div> </div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div defang_data-gmailquote= =3D"yes"><div><div>New W3C standards (that the TAG should both know about a= nd support via technical review) such as WebCrypto and Web Authentication a= llow cryptographic authentication and cryptographic primitives to be used w= ithout violating SOP or relying on soon-to-be deprecated parts of HTML.<br>= </div> </div> </div> </div> </div> </blockquote><div> </div> <div> - Webcrypto is not a proposed recommendation yet and the documen= t warns that it is unstable.<br></div> <div>- The Web Authentication working group has not yet releases a sp= ec and depends on the Credential Management API which is still in the draft= phase.<br></div> <div>- "soon-to-be deprecated": this seems to be kind of begging the questi= on, in my opinion it shouldn't be deprecated before better alternatives hav= e become standards and after deprecation it shouldn't be removed for a peri= od long enough to allow users and implementors to transition.<br></div> <div> </div> <div> </div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div defang_data-gmailquote= =3D"yes"><div><div> </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> <br></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> </blockquote><div> </div> <div>The W3C membership and myself of course support one-factor cryptograph= ic authentication without the secret key ever leaving the browser (or bette= r yet, never being accessed by the browser). WebCrypto allows secret keys t= o be non-extractable and so private from server, and Web Authentication all= ows access to long-term keys stored outside the browser in a way that respe= cts 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 brows= er vendor support and have analysis by cryptographers and the wider Web Sec= urity community. These standards have been communicated to the TAG an= d WebID+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.<br></div> </div> </div> </div> </blockquote><div>I'm really confused now, searching the W3C site for "Web = Authentication" I find the working group. On the WG page there's a link to = the deliverables that points to <a href=3D"https://github.com/w3c/webauthn/= blob/master/PubStatus.md">https://github.com/w3c/webauthn/blob/master/PubSt= atus.md</a> which doesn't list any deliverable yet. <br></div> <div> </div> <div>Is there a standard that allows me to create a key-pair, advertise my = public key, have other sign it and use the keypair for authenticating with = (potentially) any websites as well as to sign the keys of others?<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"><blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom= :0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border= -left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote=3D= "yes"><div><div> </div> <div> <br></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> </blockquote><div> </div> </div> <div defang_data-gmailquote=3D"yes"><div>See above. <br></div> </div> <div defang_data-gmailquote=3D"yes"><blockquote style=3D"margin-top:0px;mar= gin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;bor= der-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;= " defang_data-gmailquote=3D"yes"><div><div> </div> <div> <br></div> <div>Cheers,<br></div> <div>Reto<br></div> <div> </div> <div> <br></div> <blockquote type=3D"cite"><div dir=3D"ltr"><div><div><div><div><span>Myself= and many others support strong cryptography and decentralized networks of = trust, and fully support that effort. Rather than attribute the use of brok= en technology to protocols to NSA, it's also possibly due to lack of educat= ion. </span><br></div> <div> <br></div> <div><span>Thus, you may want to look at:</span><br></div> </div> <div><div> <br></div> <div><span>1) MD5 security issues are well-known and documented:</span><br>= </div> <div><span><a href=3D"http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf">ht= tp://merlot.usc.edu/csac-f06/papers/Wang05a.pdf</a></span><br></div> </div> <div><div><span>2) In practice, the WebID+TLS community should use modern c= rypto 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 t= hat explains how Web security works. Videos are available from this MIT cou= rse explain modern Web Security, including the Same Origin Policy:</span><b= r></div> <div><span><a href=3D"https://www.youtube.com/watch?v=3D_1C62Twf0vs">https:= //www.youtube.com/watch?v=3D_1C62Twf0vs</a></span><br></div> <div> <br></div> <div><span>Hopefully others will be more reasonable, but you may wish to fa= miliarize yourself with this thread rather than endlessly repeat it. </span= ><br></div> <div><span><a href=3D"https://groups.google.com/a/chromium.org/forum/#!topi= c/blink-dev/pX5NbX0Xack">https://groups.google.com/a/chromium.org/forum/#!t= opic/blink-dev/pX5NbX0Xack</a></span><br></div> </div> <div><div><span>Note that we're just modernizing with W3C Web Authenticatio= n secure and modern cryptographic one-factor authentication to use modern p= rimitives and respect user privacy. You are more than welcome to join the W= orking Group as an Invited Expert, although an expert should be aware of th= e basics of security. </span><br></div> </div> <div><div><span>Although there are a number of inaccuracies in this report = in terms of WebCrypto, it's pretty clear Web Authentication matches all req= uirements in Section 6 here:</span><br></div> <div><span><a href=3D"http://w3ctag.github.io/client-certificates/">http://= w3ctag.github.io/client-certificates/</a></span><br></div> </div> <div><div><span>Thus, it makes sense to hold off and deprecate <keygen&g= t; after the fall of this year, when Web Authentication is deployed in brow= sers. As stated earlier, the "WebID" community can simply use Web Authentic= ation rather than client certs for authentication. </span><br></div> <div> <br></div> <div><span>That being said, since the only browser that supports <keygen= > currently is Mozilla, who plans to deprecate regardless of what the TA= G says, then it can also be justified to remove from the standard today as = there is no interoperability. </span><br></div> </div> <div> <br></div> <div><span> cheers,</span><br></div> <div><div><span> harry</span><br></div> </div> <div><div> <br></div> <div><span> </span><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;"><div><div> <br></div> <div><span>Cheers,</span><br></div> <div><span>Reto</span><br></div> <div><div><span> </span><br></div> </div> <div><span> </span><br></div> </div> </blockquote></div> </div> </div> </blockquote><div> <br></div> <div> </div> <div><div>--<br></div> <div> Reto Gm=C3=BCr<br></div> <div> <a href=3D"mailto:[email protected]">[email protected]</a><br></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> --_----------=_146539496931296870--