The SOP problem - was: removing keygen from HTML

> On 8 Jun 2016, at 14:28, Harry Halpin <hhalpin@ibiblio.org> wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 9:26 AM, Reto Gmür <reto@gmuer.ch <mailto:reto@gmuer.ch>> wrote:
> On Tue, 31 May 2016, at 14:12, Harry Halpin wrote:
>>  
>>  
>> On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <reto@gmuer.ch <mailto:reto@gmuer.ch>> 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  -  please follow the links as to avoid throwing out such accusations on a public mailing list.

yes, that's much too simple. We should remember Laurie Anderson's "Language is a Virus" song ( a phrase she took from Willam S. Burroughs): people get infected by thoughts that do not serve their own survival, but guide them to their doom for the benefit of other interests. There are lots of examples in nature of this, http://io9.gizmodo.com/12-real-parasites-that-control-the-lives-of-their-hosts-461313366 <http://io9.gizmodo.com/12-real-parasites-that-control-the-lives-of-their-hosts-461313366> 

The only way to make sure that one does not fall pray to such a thougt virus is to think things through from first principles, as mathemtically as possible.
It requires a certain hygene of thought, that requires being open about what the reasons one comes to conclusions are. This is why this mailing list
is a very good one to discuss these basic principles, and make sure we are progressing on good foundations.

> 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.

As far as I understand <keygen> is not really cross origin.  The WebID-TLS spec actually has a little diagram
to explain how it works ( when one does not use the MD5 signature part, which in any case is not secure ).
https://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation <https://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation>


All that keygen is, is an HTML form element, that on submission of the form creates a public/private
key (1) and adds the public key to the form submission (2) In Firefox the private key is then placed in
a browser's keychain ( not the trusted certificate keychains of course! ) and it waits
for the correct client certificte to come back with the public key to bring the private and public key
together (4).





There is nothing there that says that the keychain should accept a certificate that comes from another origin.
There is as far as I know no problem with sending a form to a server.

So where exactly is the SOP issue with keygen?

The TAG finding says:
http://w3ctag.github.io/client-certificates/#known-threats <http://w3ctag.github.io/client-certificates/#known-threats>

Keygen form submission has unmitigated access to the keystore; script can affect either 
1) global OS state changes without user permission, or 
2) origin-unaware certificate installation (in user agents that implement their own keystore). At a minimum, this violates the same origin policy.

But actually that would be quite easy to fix if it is a problem: browsers just need to be place the private key in an origin aware browser store, and as the TAG finding says in section 5

Keygen must not write private keys into origin-unaware keystores without user permission. User permission must be granted prior to writing new private keys into any keystore (whether OS-provided or not).

If that were your issue with keygen then seriously that would not warrant removing it, just fixing that impleemtnation.

 
> 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  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.  

(and people have argued that you should leave a period of time so that people can actually compare whatever you have
 with what claim is a subsitute for it)

Anyway, the Web Cryptography API was finished beginning of 2015.

In September of 2015 I in fact wrote an implementation that uses WebID, the Web Crypto API and the Web Signatures RFC 
the details of this are written up here:
   https://github.com/solid/solid-spec/issues/52 <https://github.com/solid/solid-spec/issues/52>

So it is not true that we have not researched what is possible.

You should know that I know, as I  have written this up and details what issues remain:
  (1) This does not give the user much control over the keys, leaves everything completely up to the executing JS from a given origin, which may
      or may not decide to show the user that he is authenticating or not to a site
  (2) in other words there is a lack of chrome integration, and security

So the real discussion here is to fill the gap between what the client certificate authentication allows (aided or not by <keygen> btw) and
what is missing in the Web Crypto API. 

So for the moment you have a very confused set of arguments:

 1)  you are arguing to remove <keygen> on the grounds that it fails on SOP, where in fact it does not (see above), or not in any way that is not easy to rectify
 2)  it seems that what you are bothered with is client certificates being used across origins - but that does not fail SOP either if the user is allowed to be in control
    ( see the TAG finding, regarding ), and that is not what keygen removal addresses 
 3) you sugest the Web Crypto JS API as a replacement but that does not in fact put the user in control, and allows even more easily for super cookie use!


PS.

It may be useful if the client certificate TAG finding on client certificates were extended a bit to also speak about cross 
origin usage of certificates and the importance of the user being in control, as that seems to be the real issue Harry Halpin 
has with the technology. I have opened an issue for this:

 https://github.com/w3ctag/client-certificates/issues/18 <https://github.com/w3ctag/client-certificates/issues/18>



>  
> 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 <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=_1C62Twf0vs <https://www.youtube.com/watch?v=_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/pX5NbX0Xack <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack>
>> 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/ <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ür
>   reto@gmuer.ch <mailto:reto@gmuer.ch>