Re: removing keygen from HTML

On Tue, May 31, 2016 at 9:26 AM, Reto Gmür <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> 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. 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 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.

>
> 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=_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
> 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ür
>   reto@gmuer.ch
>
>
>