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

> On 12 Sep 2015, at 19:48, Alex Russell <slightlyoff@google.com> wrote:
> 
> 
> On 12 Sep 2015 12:27 am, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:
> >
> >
> >
> > On 12 September 2015 at 03:20, Alex Russell <slightlyoff@google.com> wrote:
> >>
> >>
> >> Hi all,
> >>
> >> Apologies for the late response to this thread. I'm not sure that the
> >> conversation has created much mutual understanding. Perhaps it's worth
> >> trying to consider to following aspects separately:
> >> - The implementer consensus regarding <keygen>
> >> - Questions regarding the origin model and global modification of
> user systems without user interaction
> >> - User and developer needs for key generation and storage
> >> Given the current proposal to deprecate <keygen> in Blink [1], it
> >> seems worth reiterating the broad consensus that <keygen>'s use of MD5 is
> >> fundamentally broken [2].
> >
> >
> > Certificates are not signed using MD5 here, but rather, a public key.  The public key is later used to create a certificate on a server, using a hash such as sha2.
> 
> SKPAC is used to generate a challenge. This relies on MD5. In proof-of-posession usecases, this challenge is a required to be trustworthy. Thanks to MD5, it isn't.

yes, we agree. It would be easy to fix this in an number of ways.

It is important not to overblow this present weakness though, as it there is
not much harm that can be done with it, as explained in detail here:

 https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/dn_7RguGAAAJ

Overblowing this problem then leads to hasty decisions such as removing keygen
rather than fixing it, and to stifling intelligent conversation such as when 
the WHATWG censored my mail explaining the limited danger this posed

https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0027.html

> >  I dont believe the attack outlined is usable here to compromise key material. 
> 
> In many keygen scenarios, this is immaterial. The challenge is suspect, which means POP can't be assured.

The potential attacks require that the possesion of the private key not be verified,
which is not true for TLS authentication for example, may be abused in case of signature if some other evident features of a signature are missing. ( such as not
placing the name of the signer inside the signed document )

It is clear that fixing this would be an improvement. 

> 
> > If you have evidence to the contrary, it would be great to hear.  
> > The same question was posed on the blink thread, and in each case,
> > the proposer was unable to actually articulate an attack vector.  
> >  
> >>
> >> Some in the thread seem to misunderstand the impact of this brokenness,
> >> but rest assured, the only value a <keygen>-created challenge could
> >> provide is fundamentally suspect. This is in addition to long-standing
> >> objections by Microsoft that <keygen> isn't fit for purpose for other 
> >> reasons [3]. Implementers have also identified core issues with
> >> <keygen>'s behavior that mean compatibility will suffer as issues are fixed.
> >
> >
> > Thanks for pointing to microsoft's position from 2009.  In the mail,
> > they propose some suggestions to improve the keygen widget, namely:
> >
> > - add key length parameter
> > - add expiry date parameter
> > - add the possibility of certificate generation
> > - add the possibility of non RSA keys
> >
> > These are all great suggestions and something similar was suggested on
> > the blink thread, via an API.
> >
> > window.crypto.subtle.generateKey( 
> > { name: "RSASSA-PKCS1-v1_5",
> >  modulusLength: 2048,
> >  publicExponent: new Uint8Array([1, 0, 1]),
> >  hash: {name: "SHA-256"}, 
> >  keystore: true                <------------------------That's an example. Even a PKCS#11 URI could be used!
> > },

For reference, the mail in which this was suggested is archived here
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/JZiho282AQAJ

> >
> > My own and other analysis of keys in the free and open source community
> > show [1] that the vast majority of keys used today are 2048 bit RSA.  
> > Consistent with the functionality discussed by microsoft back in 2009.
> >
> > [1] https://blog.benjojo.co.uk/post/auditing-github-users-keys
> >  
> >>
> >>
> >> These concerns have reached a head with the proposal to deprecate. One
> >> might imagine repairing <keygen>, but this works against the extensibility
> >> principles the TAG encourages [4]. 
> >>
> >> A more extensible solution would be an API form of key generation.
> >> Interestingly, this now exists via Web Crypto (as was pointed out in the
> >> original Blink thread by Ryan [1]). These keys are not directly generated
> >> in the same key store used for client certificates, but page authors
> >> can work with generated keys, even allowing users to import them
> >> into keystores.
> >>
> >> Developers who want to persistent keys to the local system should
> >> acknowledge that this is an operation that lives outside the
> >> Same Origin Model. The inability to scope the use of keys added 
> >> via <keygen> (via addition to the effective keychain) creates a major
> >> hole in our one workable security primitive. It's true that this isn't
> >> part of the <keygen> spec, but compatibility requirements have caused
> >> this to be true in practice. From an architectural perspective, this
> >> alone should be enough to cause the TAG to recommend removal of
> >> <keygen> and replacement with a better, origin-scoped alternative.
> >>
> >> Lastly, I think it's important for us to take the need to generate
> >> keys seriously. We can do this without holding onto poorly designed
> >> and constructed features, however. I'd like to understand more deeply
> >> why key generation via Web Crypto isn't functional. Perhaps we can
> >> discuss that next week?
> >
> >
> > Excellent suggestions.  Progress leading towards an API would be welcome in this area, but there were a number of calls to not completely deprecate keygen until the same functionality could be replaced with something else.
> 
> I asked before and will again: why is it not workable for your uses to have Web Crypto generate key and have the page generate a download for the key file to be installed locally?

Can you detail the sequence diagram for this? I understand a number of scenarios
of which the following:

A. WebCrypto generates key pair and sends public key

1) web crypto generate a public/private key ( perhaps with extractable=false set )
2) web crypto send the public key to the server which creates a certificate that is uploaded to the server
3) the user can click on the certificate to install it

But then in 3) the certificate is in the keychain without the corresponding 
private key, so its not much use. Would the user also have to look in local
storage for the private key?

B. WebCrypto generates key pair and sends both

In that case why bother with web crypto? The server could have generated
both keys itself, packaged them into a PEM file and sent that to the client.
This is logically equivalent to the case when the client JS generates the key
pair with extractable=true , since any JS on the origin can access the private 
key. 

In both of these cases installing the certificate into the keychain 
is a multi-step  process for the end user which is difficult to accomplish.

In B furthermore it is teaching the user to install a certificate for which
he is not the only one to posess the private key, which is a very bad habit
to get people to engage in. It is not for nothing that FIDO makes sure that
the private key never leaves the dedicated hardware. Why would one now go
in the reverse security direction?

Compare this with the security and ease of use of the actual implementations
of keygen. One click and the public/private key is generated under the user's
control, and the certificate is installed under the user's control. User
Control and involvement is essential to this process.

Now it won't do to say that this is too difficult to build, since the whole 
of the FIDO alliance is working on not just tying the UI experience to the
chrome, but even to the Operating System and the hardware. ( and furthermore
it is already built into Google's Chrome, Internet Explorer, Safari, and Opera )

Henry

> 
> >> Regards
> >>
> >> [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack
> >> [2] http://www.kb.cert.org/vuls/id/836068 
> >> [3] https://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
> >> [4] https://extensiblewebmanifesto.org/ 
> >>
> >>
> >> On Sat, Sep 5, 2015 at 5:05 AM, Henry Story <henry.story@co-operating.systems> wrote:
> >>>
> >>>
> >>> > On 4 Sep 2015, at 14:54, Henry Story <henry.story@co-operating.systems> wrote:
> >>> >
> >>> >>
> >>> >> On 2 Sep 2015, at 14:15, Wendy Seltzer <wseltzer@w3.org> wrote:
> >>> >>
> >>> >> On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> >>> >>> On 1 September 2015 at 16:08, 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.
> >>> >>>>
> >>> >>>
> >>> >>> IMHO we need an area of the browser under a user's control
> >>> >>
> >>> >> That seems like a different, and more interesting requirement than
> >>> >> "keygen."
> >>> >>
> >>> >> Keygen was a poorly designed, inconsistently implemented feature, that
> >>> >> many sophisticated users and developers found confusing. If we can
> >>> >> instead define what features we want to be able to build, and what they
> >>> >> depend on that's not provided by WebCrypto, and think about how we can
> >>> >> enable users to access these features without opening themselves up to
> >>> >> be phished or tracked, that feels like a more productive avenue for
> >>> >> discussion than "bring back keygen".
> >>> >
> >>> > I think this is much too harsh on keygen btw. What is happening may be
> >>> > that the documentation in the HTML5 was not good enough at explaining how
> >>> > it worked. After a discussion on the WhatWG where one key argument against
> >>> > keygen turned out that it was insecure because of its use of MD5, and after an off
> >>> > list pointer to what the aleged reason of the problem was I wrote a detailed
> >>> > response to the WHATWG showing that MD5 has no effect on keygen, and
> >>> > ansuggesting that improved wording of the spec may help diffuse this
> >>> > misunderstanding.
> >>> >
> >>> >   https://github.com/whatwg/html/issues/102
> >>> >
> >>> > This did not stop the issue being closed within 15 minutes of my opening the
> >>> > issue. ( and I seem to be filterd now on the WHATWG mailing list ).
> >>>
> >>> So yes the mail that referenced issue 102 linked to above was filtered and
> >>> censored for reasons of "security". This is surreal. A decision for removing
> >>> strong security from browsers is made on a mistaken understanding of how the
> >>> feature works. Then showing that the alleged security hole is illusory is
> >>> considered a potential security risk and is filtered. Here is the link to the
> >>> mail:
> >>>
> >>>   https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0027.html
> >>>
> >>> I am sorry to mention it, but how can this not make one think of secret courts using secret evidence ( and even secret laws ) ? This requires everyone to completely trust the cryptography experts and makes it then impossible to bring to light the implicit assumptions that are guiding their thinking, and that would perhaps when brought out in the open allow new possibilities to emerge.
> >>>
> >>> Henry
> >>>
> >>> PS. I verified my position on the irrelevance of MD5 in keygen generated spkac with cryptography experts from openssl. It would be nice if some cryptography experts could at least confirm this here.
> >>>
> >>> >
> >>> > Henry
> >>> >
> >>> >
> >>> >>
> >>> >> --Wendy
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
> >>> >> Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
> >>> >> http://wendy.seltzer.org/        +1.617.863.0613 (mobile)
> >>>
> >>>
> >>
> >

Received on Sunday, 13 September 2015 16:53:42 UTC