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

On 3 September 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> 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
>>
>> My response to that is here:
>>
>> 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
>
> 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/
>
> 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.
>

Thanks for providing this link.  You mention "several" high profile
attacks, tho I only saw one attack.  How many others are you aware of?

For attack you mention it said that fixes had been applied to : Chrome,
Opera, Android, IE, Firefox, Safari, IOS, OpenSSL, GNUTLS, Java and others.

Are there some other systems you are concerned about?  Do you have any
stats of prevalence of this attack in the wild?

For example, for the use case of dealing with trusted family members for
collaboration, I think we can rule out the malicious server problem, more
likely would just be to come over to your computer and access it physically
:)


> X.509 is also problematic to parse, leading to security issues [2]. 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.
>
> 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.*
>
>     yours,
>           harry
>
> [1] https://www.secure-resumption.com/
> [2] 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
>
>
>
>>
>>
>> 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
>>
>>    [2] 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
>>
>>    [4] https://lists.w3.org/Archives/Public/public-html/2009Sep/0153.html
>>
>>    [5] https://blog.whatwg.org/this-week-in-html5-episode-35
>>
>>    [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen
>>
>>    [7]
>> https://html.spec.whatwg.org/multipage/forms.html#the-keygen-element
>>
>>    [8]
>> 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
>>
>>    [10] 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
>>
>>    [12] https://fidoalliance.org/
>>
>>    [12]
>> 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
>>
>>
>>    Usage information from UseCounter
>>
>>
>> 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
>>
>>    Entry on the feature dashboard
>>
>>
>> https://www.chromestatus.com/metrics/feature/popularity#HTMLKeygenElement
>>
>>    Requesting approval to remove too?
>>
>>    No
>>
>>
>>
>