Re: Agenda: <keygen> being destroyed when we need it

> On 3 Sep 2015, at 00:25, Harry Halpin <hhalpin@ibiblio.org> wrote:
> 
> On Tue, Sep 1, 2015 at 10:08 AM, Tim Berners-Lee <timbl@w3.org <mailto:timbl@w3.org>> wrote:
> Folks
> 
> There is a strong move my Google chrome team followed by Firefox to remove the <keygen> tag from HTML5.   This has been done without an issue being raised in the WHATWG  or HTMLWG apparently.
> 
> <keygen> is important because it allows authentication systems to be build in a distributed manner. It allows any Mom and Pop shop place to share public keys for people they trust.    For example, MIT uses it to create secure relationship with faculty and staff, and I use it for friends and family.
> 
> Public key asymmetric crypto is generally so much stronger than the password-based authentication.  It requires certificate management code to be written.
> 
> Not sure what the real motivation is for this -- maybe wanting to be able to force everyone to authenticate through their  One True accounts in future, get a global control on identity, which with keygen can be distributed and controlled by other people.
> 
> 
> It provides the security that the management of the keys by the user is handled by the bowser itself.   This means that harder for a malicious site to write Javascript to look as though it is doing the keygen thing and the later authentication when you are actually not.
> 
> Keygen is not therefore something which you can just code in Javascript. 
> 
> The original July 28  announcement from the Chrome team is here:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion>
> 
> My response to that is here: 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ <https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/5CQnw56-BQAJ>
> 
> I attached an attempt to recreate the indentation of text/response which got messed up in some versions.
> 
> Let's put this on the TAG agenda.
> 
> Tim
> 
> 
> TimBL, 
> 
> It seems the use-case is for people to authenticate securely to web-sites they trust, with the security being done by key material rather than passwords. There is already a standard for that called "FIDO" (Fast IDentity Online) that W3C is already co-operating with, as shown by our workshop final report here:
> 
> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html <http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html>
> 
> The specs are open and cover both key-based authentication (although it cleanly separates out identity from authentication and follows the same-origin policy) and multi-factor authentication. 
> 
> https://fidoalliance.org/specifications/overview/ <https://fidoalliance.org/specifications/overview/>
> 
> I know myself, quite a few of W3C Team, and many W3C members are excited by FIDO and, while it is currently being developed in a closed process, the plan is I believe to bring it to an open standards process like IETF and W3C. 
> 
> If your request is to keep <keygen> *until* FIDO is in browsers, I think that's reasonable, although the user-base of people authenticating with client certificates is quite small. However, it is also reasonable to warn developers that it will be deprecated soon, and that new protocols or products should *not* depend on <keygen>.
> 
> There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems.

This is a man in the middle attack and has no reference to X509. Furthermore it has already been patched the most widely used browsers and libraries. 

All security protocols are constantly under review and improvement: security is by necessity a wholistic project which needs to take into consideration all layers including social and psychological ones. Last year's Web Crypto Workshop report you mentioned states that "for example replay attacks on certain layers (SMS) present security problems". That is not an argument to remove that channel, but presumably to improve it.

> X.509 is also problematic to parse, leading to security issues [2].

That is a 2010 paper by Dan Kaminsky and al. He talked about this at length at various hacker conferences one of which I was present at some 4 years ago or so. The paper contains suggestions
for fixes which I were presumably implemented in the mean time. 

<aside>
I was of course listening intently to his talk, as I was worried enough about this for WebID+TLS. 
So I caught him after the talk and presented him the idea of WebID+TLS in a 1 minute 
( it's really that easy ). He loved the idea and in fact defended it right there and then as it
echoed some ideas he had regarding how to improve server security using DNSSEC.
A few months later the IETF started the DANE project which is pretty much the
WebID logic applied to servers instead of clients ( ie, instead of publishing a public key 
for a certificate on the Web, DANE publishes it in DNSSEC for the server ).
https://datatracker.ietf.org/wg/dane/charter/ <https://datatracker.ietf.org/wg/dane/charter/>
</aside>

X.509 is indeed legacy that is difficult to deprecate as it so so widely deployed on the web. But TLS is in fact extensible as far as certificate encoding goes. There is even an RFC "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication" https://tools.ietf.org/html/rfc6091 <https://tools.ietf.org/html/rfc6091>
One could also write one that used the same JSON format that was used by the Mozilla Persona
project, or even JOSE  ( https://datatracker.ietf.org/wg/jose/charter/ <https://datatracker.ietf.org/wg/jose/charter/> )
This would not change the semantics of TLS, just make it easier to code certificates presumably, extend them, and for them to be less prone to those bugs listed by Kaminsky that are due to the numerous ways of encoding numbers.
   For client authentication I can see that moving to a JOSE based certificate would be the first step
before making changes on the server side. But this will mean a transition period where browsers will
need to hold two versions of a same certificate for a given public/privte key.

> While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year. 
> 
> In terms of your current coding projects that depend on <keygen> and WebID+TLS, I'm sure the larger W3C community would be thrilled to work out solutions for your use-cases based on FIDO - and maybe   OAuth (also not perfect, but possible to be improved to give better privacy/anonymity [3])  -  that use the JOSE specs for key material. This would make the exciting coding projects being done by yourself and others compatible with Web while providing better privacy and security properties that the X.509/TLS stack. 

(1) In order to enable the browser to authenticate to any site (even ones the user has never visted before) without going through a third "Authentication provider", asymetric key cryptography and some encoding of a certificate ( however minimal), is required. 
-> This means the browser has to be able to generate a public/private key pair, and get the public key published somewhere. Ie. it needs a <keygen> like functionality, and a way to associate extra information to the key via some certificate format. 

(2) There then needs to be a protocol at the HTTP layer ( together presumably with TLS to avoid man in the middle attacks ), that enables the server to ask the client for authentication to access a resource. The client must be able to pass this request on to the user in such a way that it is impossible to phish the interface. ( presumably using some of the tools from the FIDO tool box - such as fingerprinting,etc. )
If the user accepts the authentication, the client must be able to use the private key material at its disposal
in a way that it does not leak, in order to authenticate the user. 
-> This is currently made possible by TLS client certificate authentication, but there are other proposals on the table that would adapt this so that it fits better with HTTP2.0. See the discussion started on the IETF HTTP mailing list
  https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html <https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html>

(3) The client needs to be able aware of the persona he is using at any time and be able to log out at any moment if needed. ( privacy requirement )
   This is a User Interface/Chrome requirement that requires UI designers, something along the lines
of what is proposed by the WebAppSec WG.

These pieces work in current browsers.In the WebID XG we just used the technology that actually existed in browsers (as we are not browser vendors but application developers) to get all of this working.
It is very powerful. But we welcome improvements to the technology at all levels. 

It is clear though that the functionality provided by keygen, certificates and authentication using asymetric public keys will continue to be needed if we want to build a secure distributed decentralised web where each all can participate as free citizens.

> So, perhaps a reasonable compromise is that we can not immediately disable <keygen> until FIDO is implemented in browsers, and then remove it, while warning developers *now.*

We should definitively look at what FIDO provides. But it is not clear yet that it provides what is being taken away. In fact in this thread Bryan Sullivan has stated that it does not. Until this is absolutely clear one should not jump to conclusions. 

>     yours,
>           harry
> 
> [1] https://www.secure-resumption.com/ <https://www.secure-resumption.com/>
> [2] https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf <https://www.cosic.esat.kuleuven.be/publications/article-1432.pdf>
> [3] http://www.degruyter.com/view/j/popets.2015.2015.issue-2/popets-2015-0022/popets-2015-0022.xml <http://www.degruyter.com/view/j/popets.2015.2015.issue-2/popets-2015-0022/popets-2015-0022.xml>
> 
>  
> 
> 
> On Tuesday, July 28, 2015 at 3:46:51 PM UTC-4, Ryan Sleevi wrote:
> 
>>    Summary
>> 
>>    This is an intent to deprecate, with the goal of eventually removing, support for the <keygen> element [1], along with support for special handling for the application/x-x509-user-cert [2].
>> 
>> 
>>    This is a pre-intent, to see if there are any show-stopping use cases or compatibility risks that have hitherto been unconsidered.
>> 
>> 
> Maybe if this is  strategic direction taking us away from asymetric  crypto and putting it the hands of users and developers should be reconsidered.
> 
>> 
>>    [1] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element <https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element>
>> 
>>    [2] https://wiki.mozilla.org/CA:Certificate_Download_Specification <https://wiki.mozilla.org/CA:Certificate_Download_Specification>
>> 
>>    Motivation
>> 
>>    History: <keygen> was an early development by Mozilla to explore certificate provisioning. Originally Firefox exclusive, it was adopted by several mobile platforms (notably, Nokia and Blackberry), along with support for the certificate installation mime-types. During the First Browser Wars, Microsoft provided an alternative, via ActiveX, called CertEnroll/XEnroll. When iOS appeared on the scene, <keygen> got a boost, as being the initial way to do certificate provisioning, and along with it brought support into Safari. It was then retro-spec'd into the HTML spec.
>> 
>> 
>>    Issues: There are a number of issues with <keygen> today that make it a very incompatible part of the Web Platform.
>> 
>>    1) Microsoft IE (and now Edge) have never supported the <keygen> tag, so its cross-browser applicability is suspect. [3] Microsoft has made it clear, in no uncertain terms, they don't desire to support Keygen [4][5] 
>> 
>> 
> Microsoft didn't implement SVG technology for about a decade.  For many that left it as a questionable technology.  The solution was for Microsoft to implement it.
> 
> 
>    2) <keygen> is unique in HTML (Javascript or otherwise) in that by design, it offers a way to persistently modify the users' operating system, by virtue of inserting keys into the keystore that affect all other applications (Safari, Chrome, Firefox when using a smart card) or all other origins (Firefox, iOS, both which use a per-application keystore)
> 
> 
> If it is unique, then it should be not removed. If you replace it with another way of allowing the user to create a key pair and control the use of the key, then fine, But don't please remove keygen until
> 
>> 
>>    3) <keygen> itself is not implemented consistently across platforms, nor spec'd consistently. For example, Firefox ships with a number of extensions not implemented by any other browser (compare [6] to [7])
>> 
>> 
> A solution would be then to extend the standrad in future versions and code compatibly to that.
> 
> 
>>    4) <keygen> itself is problematically and incompatibly insecure - requiring the use of MD5 in a signing algorithm as part of the SPKAC generated. This can't easily be changed w/o breaking compatibility with UAs.
>> 
>> 
> Why not?  Almost all secure protocols have to have an upgrade path, where you allow back-compatibility for a certain time
> 
> If the alternative is the browser vendors or the developers re-creating a new tool, then -- that ain't goonna be back-compatible either, is it?
> 
> 
> 
>>    5) <keygen> just generates keys, and relies on application/x-x509-*-cert to install certificates. This MIME handling, unspecified but implemented by major browsers, represents yet-another-way for a website to make persistent modifications to the user system.
>> 
> 
> There is a typical browser vendor mindset: this feature allows a web site to do something to the user. 
> Think of it: this allows a user to do something very powerful with their browser which gives them greater security in their relationships with web sites. The browser acts as the user's agent.
> 
> If you are worried about keygen being used to install access to other things, such as phone plans, without the users understanding, then fix that explicitly
> 
>>    6) Mozilla (then Netscape) quickly realized that <keygen> was inadequate back in the early 2000s, and replaced it with window.crypto.generateCRMFRequest [8], to compete with the CertEnroll/XEnroll flexibility, but recently removed support due to being Firefox only. This highlights that even at the time of introduction, <keygen> was inadequate for purpose.
>> 
>> 
>>    [3] https://connect.microsoft.com/IE/feedback/details/793734/ie11-feature-request-support-for-keygen <https://connect.microsoft.com/IE/feedback/details/793734/ie11-feature-request-support-for-keygen>
>> 
>>    [4] https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html <https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html>
>> 
>>    [5] https://blog.whatwg.org/this-week-in-html5-episode-35 <https://blog.whatwg.org/this-week-in-html5-episode-35>
>> 
>>    [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen>
>> 
>>    [7] https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element <https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element>
>> 
>>    [8] https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest <https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto/generateCRMFRequest>
>> 
>>    Compatibility Risk
>> 
>>    While there is no doubt that <keygen> remains used in the wild, both the use counters [9] and Google's own crawler indicate that it's use is extremely minimal. Given that Mozilla implements a version different than the HTML spec, and given that Microsoft has made it clear they have no desire to implement, the compatibility risk is believed to be low in practice.
>> 
>> 
>>    Mozilla is also exploring whether or not to remove support for the application/x-x509-*-cert types [10], but has not yet (to my knowledge) discussed <keygen> support - either aligning with the (much more limited) spec, extending the spec with the Mozilla-specific extensions, or removing support entirely.
>> 
>> 
>>    On the application/x-x509-*-cert support, there is a wide gap of interoperability. Chrome does not support multiple certificates, but Firefox does. Firefox will further reorder certificates that are inconsistent with what was specified, offering a non-standard behaviour. Chrome does not support application/x-x509-ca-cert on Desktop, and on Android, defers to the platform capabilities, which further diverge from Firefox. Both browsers have the underspecified behaviour of requiring the user having a matching key a-priori, except that's not detailed as to how it works. Firefox also handles various mis-encodings (improper DER, DER when it should be base64), which Chrome later implemented, but is not well specified.
>> 
>> 
>> Well, obviously a move to create more interop though a better standard would be a good idea.  Meanwhile keygen seems to work for me for webid on the 4 browsers I use.
>> 
>> 
>> 
>> 
>>    [9] https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
>> 
>>    [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871 <https://bugzilla.mozilla.org/show_bug.cgi?id=1024871>
>> 
>>    Alternative implementation suggestion for web developers
>> 
>>    The primary use cases for <keygen>, from our investigations, appear to be tied to one of two use cases:
>> 
>>    - Enterprise device management, for which on-device management capabilities (Group Policies, MDM profiles, etc) represent a far more appropriate path. That is, you would not expect a web page to be able to configure a VPN or a users proxy, so too should you not expect a webpage to configure a user's system key store.
>> 
>>    - CA certificate enrollment, for which a variety of alternatives exist (e.g. integrated to the web server, CA specific-tools such as SSLMate or protocols such as Let's Encrypt, etc). Here again, it does not seem reasonable to expect your web browser to configure your native e-mail client (such as for S/MIME)
>> 
>> 
>>    Within the browser space, alternatives exist such as:
>> 
>>    - Use the device's native management capabilities if an enterprise use case. On Windows, this is Group Policy. On iOS/Android, this is the mobile device management suites. On OS X, this is Enterprise settings. On ChromeOS, there is chrome.enterprise.platformKeys [11] for enterprise-managed extensions.
>> 
>>    - Use WebCrypto to implement certificate enrollment, then deliver the certificate and (exported) private key in an appropriate format for the platform (such as PKCS#7) and allow the native OS UI to guide users through installation of certificates and keys.
>> 
> 
> The creation of a key pair should be as simple for the user as possible.  This is a user creating an account, it has to be smooth.  It has to happen completely withing the browser, no other apps involved: users will not be able to cope.  This will lead to enterprises and organizations which want to be able to authenticate users writing special code (Like MIT's certaid) which run in the OS not inn the web and do who knows what behind the user's back.
> 
> 
> 
> 
>> 
>>    On some level, this removal will remove support for arbitrarily adding keys to the users' device-wide store, which is an intentional, by-design behavior.
>> 
>> 
> I want to be able to write a  web site which gives me as a user (or my family member or friend)  a private key so I can communicate withe them securely.
> 
>>    While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, 
>> 
>> 
> What?  What is the problem? Compared to other things suggested <keygen> seems simpler adn user-friendly to me.  There is a bug that the website doesn't get an event back when the key has been generated.  That needs to be fixed, so that the website can contiue the dialog and pick up doing whatever the user wanted to do when they found they needed to mint and identity. That is a bug to be fixed,
> 
> 
> 
>> 
>>    and represents an authentication scheme that does not work well for the web. 
>> 
> 
> Asymetric auth is fundamentally more useful and powerful than the mass shared passwords and stuff which is an alternative.  If it "doesn't work well for the web" is that just that UI for dealing with certs needs improvement?
> 
> 
> 
>>    An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities.
>> 
> 
> Well, let's see the result of that work.  Don't throw out keygen until it is up and running and FIDO does what we need smoothly and securely.
> 
> In the mean time, please fix bugs in client certs which are just a pain.
> 
> - Firefox offers to save your choice of client cert ("remember this choice?" for a sit but doesn't
> - Safari displays a list of all kinds of deleted and old and expired certs as well as you active ones, which is confusing.
> 
> - In general, the client cert selection needs more real estate and a bit more info about each cert (Not just my name which is (duh) often the same for each certificate!  Unless I have remembers to make up a different name every time to be able to select between certs later)
> 
> So don't abandon <keygen>, fix it.
> 
> And sure, bring in a really nice secure powerful Fido-based system which will make <keygen> obsolete and make management of personas and identities by users a dream, has a non-phisable UI and allows the creation of a secure relationship between a user and a web site to happen as easily as any sign-up one could imagine, and allows the users to manage them when they need to.   And is compatible in all the browsers and doesn't have these silly interop problems. That would be great, and I'm sure people will be happy to move to it.   I'll believe it when I see it.  
> 
> In the meantime please support keygen and improve client cert handling. 
> 
> timbl
> 
> 
> 
> 
> 
> 
> 
> 
> 
>    [11] https://developer.chrome.com/extensions/enterprise_platformKeys <https://developer.chrome.com/extensions/enterprise_platformKeys>
> 
>    [12] https://fidoalliance.org/ <https://fidoalliance.org/>
> 
>    [12] https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/ <https://fidoalliance.org/google-launches-security-key-worlds-first-deployment-of-fast-identity-online-universal-second-factor-fido-u2f-authentication/>
> 
>    [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 <https://bugzilla.mozilla.org/show_bug.cgi?id=1065729>
> 
> 
>    Usage information from UseCounter
> 
>    https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
> 
> 
>    Based on data seen from Google crawler (unfortunately, not public), the number of sites believed to be affected is comically low. 
> 
> 
>    OWP launch tracking bug
> 
>    https://code.google.com/p/chromium/issues/detail?id=514767 <https://code.google.com/p/chromium/issues/detail?id=514767>
> 
>    Entry on the feature dashboard
> 
>    https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement <https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement>
> 
>    Requesting approval to remove too?
> 
>    No