removing keygen from HTML

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

removing keygen from HTML

Chaals McCathie Nevile
Hi folks,

there is an open issue [1] and open call for consensus [2] to remove  
keygen from HTML. Since the TAG, or its members, appear to have opinions  
about our spec, we'd be grateful to hear them.

cheers

Chaals

[1] https://github.com/w3c/html/issues/43
[2] http://www.w3.org/mid/op.yhs220oos7agh9@...

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  [hidden email] - - - Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Melvin Carvalho


On 30 May 2016 at 11:40, Chaals McCathie Nevile <[hidden email]> wrote:
Hi folks,

there is an open issue [1] and open call for consensus [2] to remove keygen from HTML. Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them.

KEYGEN is in use.  My understanding from reading various threads on this is that, from the perspective of the free software and open source community, it should only be deprecated / removed, when an adequate replacement (eg from FIDO) becomes available. 
 

cheers

Chaals

[1] https://github.com/w3c/html/issues/43
[2] http://www.w3.org/mid/op.yhs220oos7agh9@...

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 [hidden email] - - - Find more at http://yandex.com


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Henry Story-4
In reply to this post by Chaals McCathie Nevile

> On 30 May 2016, at 11:40, Chaals McCathie Nevile <[hidden email]> wrote:
>
> Hi folks,
>
> there is an open issue [1] and open call for consensus [2] to remove keygen from HTML. Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them.

I note that the same mail to the public-html mailing list [2] has for
deadline the 29 May and that this mail to the TAG was sent the day thereafter.
So I hope this mail from Charles is meant as an indicator that the deadline
for comments has been somewhat extended.

It should be noted indeed that the TAG is actually discussing
this issue which cuts across quite a number of areas in

 https://github.com/w3ctag/client-certificates

Here are points against removing it at present:

1) There is no good replacement for keygen at the moment
2) The "security problem" with keygen with weaknesses of MD5 is actually
  not a deep problem for current usages of certificates. There are usages
  where it is important but that can be fixed by improving the hashing using
  this or another protocol. But then we are back at 1) above.
3) What is required is a way for a private key to be creaated and saved in the
  browser (or by an attached hardware device), be tied to a certificate or
  credential in whatever syntax is desired ( currently X509 is widely used ),
  that can then be used across  origins when under the users control. This is
  what keygen does pretty well now. We are all looking forward to something
  better. See 1) above.

Keygen is in fact incredibly useful as demonstrated by the WebID-TLS protocol
   https://www.w3.org/2005/Incubator/webid/spec/tls/

Keygen need not be tied to TLS, but could be used with more HTTP2/0 friendly protocols
such as extensions to TLS client certificate authentication

   https://tools.ietf.org/html/draft-thomson-http2-client-certs-01

or perhaps simpler proposals such as http-signature
 
  https://tools.ietf.org/html/draft-cavage-http-signatures-05

that can work with the Web Crypto API.

Again, before removing keygen a replacement should be found. Keygen has
the advantage of reducing to the minimum the need for application developers
to work with cryptography. Most of the work is moved to the TLS layer which is
getting a huge amount of oversight, and in which progress is being made.


The web never was perfect, and in the space of security perfection is not
achievable. What is possible is improvements. And so those wishing to remove
keygen should state what the problems are, and propose an improvement, not
remove some key feature many depend on.

Again please refer to:

 https://github.com/w3ctag/client-certificates

Thanks,

        Henry Story

PS. The Work on WebID is only an initial consensus we have been able
to reach, a lot more is possible in that space...

>
> cheers
>
> Chaals
>
> [1] https://github.com/w3c/html/issues/43
> [2] http://www.w3.org/mid/op.yhs220oos7agh9@...
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> [hidden email] - - - Find more at http://yandex.com
>


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Harry Halpin
In reply to this post by Chaals McCathie Nevile
FYI,

Some folks are using <keygen>, although I think everyone has been notified of the upcoming deprecation quite a while ago and so hopefully are preparing for a post-<keygen> world if they use client certs in the browser outside of TLS (such as for authentication). One deployment, MIT is working to moving to OpenID with Duo two-factor.

It has been requested not to remove it until the replacement is ready, and I think WebAuthn fulfils the requirements in a way that is coherent with the Web Security Model.

Here's the WebAuthn schedule - so thus, one-factor cryptographic authentication should be working across most browsers later in the year, as early as October. So far, the Working Group has been moving very fast.

https://lists.w3.org/Archives/Public/public-webauthn/2016May/0213.html
Schedule:
We're aiming to reach Recommendation by February 2017, when the group's
charter ends. We agreed (with an ongoing CfC on the mailing list) to
publish a First Public Working Draft from the current Editors' Draft.
The plan:
* May: FPWD
* June: WD-01, a feature complete Working Draft
* July-Aug: Further issue resolution and Wide Review;
	additional WDs as needed
* September (TPAC): Candidate Recommendation, features stable
* Oct-Nov: Implementation and testing
* December: Proposed Recommendation
* January '17: Advisory Committee Review (4 weeks)
* February '17: Recommendation
   cheers,
       harry

On Sun, May 29, 2016 at 11:40 PM, Chaals McCathie Nevile <[hidden email]> wrote:
Hi folks,

there is an open issue [1] and open call for consensus [2] to remove keygen from HTML. Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them.

cheers

Chaals

[1] https://github.com/w3c/html/issues/43
[2] http://www.w3.org/mid/op.yhs220oos7agh9@...

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 [hidden email] - - - Find more at http://yandex.com


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Graham Leggett
On 30 May 2016, at 4:14 PM, Harry Halpin <[hidden email]> wrote:

> Some folks are using <keygen>, although I think everyone has been notified of the upcoming deprecation quite a while ago and so hopefully are preparing for a post-<keygen> world if they use client certs in the browser outside of TLS (such as for authentication). One deployment, MIT is working to moving to OpenID with Duo two-factor.
>
> It has been requested not to remove it until the replacement is ready, and I think WebAuthn fulfils the requirements in a way that is coherent with the Web Security Model.

I urge the working group to engage the crypto community and let the crypto community decide on what is or isn’t a replacement for keygen. No “proxy auth” based system like OpenID is able to replace the capabilities of client certificates.

> Here's the WebAuthn schedule - so thus, one-factor cryptographic authentication should be working across most browsers later in the year, as early as October. So far, the Working Group has been moving very fast.

I would also urge the working group to treat any attempt at rushing this issue with a significant amount of skepticism.

Regards,
Graham



Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Harry Halpin


On Mon, May 30, 2016 at 6:36 AM, Graham Leggett <[hidden email]> wrote:
On 30 May 2016, at 4:14 PM, Harry Halpin <[hidden email]> wrote:

> Some folks are using <keygen>, although I think everyone has been notified of the upcoming deprecation quite a while ago and so hopefully are preparing for a post-<keygen> world if they use client certs in the browser outside of TLS (such as for authentication). One deployment, MIT is working to moving to OpenID with Duo two-factor.
>
> It has been requested not to remove it until the replacement is ready, and I think WebAuthn fulfils the requirements in a way that is coherent with the Web Security Model.

I urge the working group to engage the crypto community and let the crypto community decide on what is or isn’t a replacement for keygen. No “proxy auth” based system like OpenID is able to replace the capabilities of client certificates.

I think you are confusing authorization with authentication. Authorization is done by OpenID. MIT uses two-factor authentication (mandatory by June 15), and will likely move to Web Authentication when the code is in browsers. Any other legacy deployments of client certificates for authentication should probably also start working on upgrading their systems to use another authentication protocol. The argument for holding till October is that by then the organizations using client certificates for authentication could upgrade to the Web Authentication API. 
 
The crypto community is already engaged in FIDO and Web Authentication and the general work has gone through the peer review process (see publications by Dirk Balfanz, etc.). Although if you find any more cryptographers or security experts, it would be great if they would join the Working Group as an Invited Experts.

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

 

> Here's the WebAuthn schedule - so thus, one-factor cryptographic authentication should be working across most browsers later in the year, as early as October. So far, the Working Group has been moving very fast.

I would also urge the working group to treat any attempt at rushing this issue with a significant amount of skepticism.


Note that the general scheme has been under development for several years before the Working Group so the Web Authentication Working Group is not rushing. The general scheme is used internally at Google and many other large organizations, so it makes sense to make it more widely available.

        cheers,
             harry


       


 

Regards,
Graham



Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Reto Gmür
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).
 
Cheers,
Reto
 
 
Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Harry Halpin


On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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?

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
 
 

Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Eric Mill
The original email said: "Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them." It'd be most productive for this thread's discussion to at least be initiated by a member of the TAG.

-- Eric

On Tue, May 31, 2016 at 8:12 AM, Harry Halpin <[hidden email]> wrote:


On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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?

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
 
 




--
Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Daniel Appelquist
Hi Folks - the TAG (in the person of Travis) has written on this topic:

https://w3ctag.github.io/client-certificates/#replacing-keygen

As noted, it represents the rough consensus of the TAG on this issue.

Dan

On Tue, 31 May 2016 at 13:33 Eric Mill <[hidden email]> wrote:
The original email said: "Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them." It'd be most productive for this thread's discussion to at least be initiated by a member of the TAG.

-- Eric

On Tue, May 31, 2016 at 8:12 AM, Harry Halpin <[hidden email]> wrote:


On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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?

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
 
 




Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Harry Halpin


On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist <[hidden email]> wrote:
Hi Folks - the TAG (in the person of Travis) has written on this topic:

https://w3ctag.github.io/client-certificates/#replacing-keygen

As noted, it represents the rough consensus of the TAG on this issue.


My point was that the TAG should know that the W3C Web Authentication Working Group has started, and the W3C Web Authentication AI I believe fulfils most if not all of these use-cases in a way that improves on <keygen>, and the plan is to be in browsers by end of the year.

One could argue to keep <keygen> enabled till when Web Authentication API is in browsers.

Also, as <keygen> is currently non-interoperable and specified in only one browser and so could be removed on those grounds below from the HTML spec as per W3C Process. The former would probably cause less complaints from the WebID+TLS user group that is on this mailing list.


 

Dan

On Tue, 31 May 2016 at 13:33 Eric Mill <[hidden email]> wrote:
The original email said: "Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them." It'd be most productive for this thread's discussion to at least be initiated by a member of the TAG.

-- Eric

On Tue, May 31, 2016 at 8:12 AM, Harry Halpin <[hidden email]> wrote:


On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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?

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
 
 





Reply | Threaded
Open this post in threaded view
|

RE: removing keygen from HTML

Travis Leithead-2
In reply to this post by Daniel Appelquist

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

 

With my HTML-editor’s hat on: there is a strong desire for the HTML5.1 spec to represent the feature set that is interoperable in browsers. Setting utility of the feature itself aside, lack of interop is the primary driving motive for removal. The above statement seems to support this.

 

Aside: the minting and return of the client cert is not technically part of the HTML5.1 specification, which only has this to say:

 

Note: This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this certificate, once downloaded and stored in the key store along with the private key, can then be used to authenticate to services that use TLS and certificate authentication. For more information, see e.g., this MDN article.

 

With TAG hat on: WebAuthn does look like a promising alternative to keygen, though it [by design] uses the SoP restrictions, meaning you can’t mint a client cert for use broadly across multiple origins. Some folks see this as a security issue with the <keygen> model, while others see it as a feature. I’m more inclined towards the former viewpoint.

 

Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Chaals McCathie Nevile
In reply to this post by Harry Halpin
On Tue, 31 May 2016 16:40:30 +0200, Harry Halpin <[hidden email]>  
wrote:

> On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist <[hidden email]> wrote:
>
>> Hi Folks - the TAG (in the person of Travis) has written on this topic:
>>
>> https://w3ctag.github.io/client-certificates/#replacing-keygen
>>
>> As noted, it represents the rough consensus of the TAG on this issue.

As I read that, in relation to the question facing the Web Platform group  
for the HTML spec:
  1) It doesn't present any urgency to remove keygen, noting that there is  
not a replacement available now.
  2) I don't know how rough that consensus is. Multiplying rough consensus  
by rough consensus can quickly get to "a minority opinion".

> One could argue to keep <keygen> enabled till when Web Authentication API
> is in browsers.

Which would have a critical impact on our current question - should we  
remove it *now*?

> Also, as <keygen> is currently non-interoperable and specified in only  
> one browser

As far as I can see it works in Safari as well. Is my simplistic testing  
giving a false positive, or does it work?

>> On Tue, 31 May 2016 at 13:33 Eric Mill <[hidden email]> wrote:
>>
>>> The original email said: "Since the TAG, or its members, appear to have
>>> opinions about our spec, we'd be grateful to hear them." It'd be most
>>> productive for this thread's discussion to at least be initiated by a
>>> member of the TAG.

To be fair, I understand the nature of this mailing list, and while I  
addressed my comments prmiarily to the TAG I am grateful for others giving  
input too.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  [hidden email] - - - Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Reto Gmür
In reply to this post by Harry Halpin
On Tue, 31 May 2016, at 14:12, Harry Halpin wrote:
 
 
On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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.
 
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.
 
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.
 
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:
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:
 
Hopefully others will be more reasonable, but you may wish to familiarize yourself with this thread rather than endlessly repeat it.
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:
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
 
 
Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Martin J. Dürst
In reply to this post by Harry Halpin
On 2016/05/31 23:40, Harry Halpin wrote:
> On Tue, May 31, 2016 at 3:43 AM, Daniel Appelquist <[hidden email]> wrote:

> My point was that the TAG should know that the W3C Web Authentication
> Working Group has started, and the W3C Web Authentication AI I believe
> fulfils most if not all of these use-cases in a way that improves on
> <keygen>, and the plan is to be in browsers by end of the year.
>
> One could argue to keep <keygen> enabled till when Web Authentication API
> is in browsers.

One could also argue that <keygen> should be available until a year or
two after the Web Authentication API is in browsers, to give both
browser users and application writers some reasonable time to switch
over and avoid a flag day.

Regards,   Martin.

Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Henry Story-4
In reply to this post by Harry Halpin

On 31 May 2016, at 14:12, Harry Halpin <[hidden email]> wrote:



On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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?

Harry this shows a complete misunderstanding of WebID over TLS.  
WebID over TLS  is just TLS client side authentication

In other forums you have been advocating switching over to HTTPS  eg here 

If the Semantic Web doesn't gracefully deal with the upgrade from HTTP to
TLS, it will date itself quite quickly and will not be usable for any
real-world usage

I suppose you are not going to say that TLS is a home brewed protocol?
 
Well I have news for you WebID-TLS is just TLS client authentication, 
which has been, and keeps being, reviewed by top security analysts. 

The extension we have done to TLS is so minimal that we did not even
have to invent a new X509 field. X509 since over 15 years comes with two
extra fields:
  - the subject alternative name
  - the issuer alternative name
each of which can take a URI.

We just use that, in pretty much the same way OpenID uses URIs to identify people. 
That's pretty much  the end of where we innovated. As you see there is no need 
to do cryptography. Certainly nowhere near as much as anything that requires the 
Web Cryptography JavaScript API libraries that all are in the namespace "subtle" 
for a good reason.

Myself and many others support strong cryptography and decentralized networks
of trust, and fully support that effort.

Mine and others assessment of what you have actually been doing is very different,
much closer to spreading Fear Uncertainty and Doubt (aka FUD) than to the role you 
should be playing as a W3C staff member. This e-mail is a case in point. 

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

We all know about these Harry. If you stopped taking the people you are communicating 
with  for idiots you may actually start hearing the arguments we are putting forward.

Lets take your two points:

1) "MD5 security issues": most other protocols including TLS actually then moved on from MD5. 
They did not stop at that point and give up. Here for example is the extract from RFC5246 TLS1.2 

      The MD5/SHA-1 combination in the pseudorandom function (PRF) has
      been replaced with cipher-suite-specified PRFs.  All cipher suites
      in this document use P_SHA256.

   We were expecting similar improvements to the Keygen functionality.

2) "WebID+TLS community should use modern crypto"  

  As mentioned we use TLS which keeps evolving. Are you saying that the whole TLS work 
is outdated crypto?

Then you state that you have a replacement of keygen, but that is not deployed and not a finished spec.
How could we use that? And how can we verify that it does indeed do what you claim it does?

3) "the Web Security model" by which you mean I suppose given your comments below, 
the "Single Origin Policy" which is exactly what is under discussion, and which the TAG finding
points out is not broken by client certificates usage that keep the user in control. 

Your not understanding point 3) is what makes me somewhat suspicious of any work you recommend,
as that is fundamental to what keygen enables to make widely and cheaply available with client
side certificates inside TLS.

Note also that we are not fundabmentally tied to TLS: I have similar implementations that work with 
the WebCrypto API, though there of course there is a much bigger risk of things going wrong, and 
sadly that offers nealy no user control when compared to that offered by client side certificates.


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

That is a very long thread that is really interesting but that would not be the best use of anyone's time to read through in 
full.  I do recommend this post where I go into the so called "security issues" of MD5 as related to keygen


and why it is actually not as big a security issue as it seems to be (it's subtle, so read with care). All it means 
is that there are cetain types of things one cannot do with certificates. (note that we do look forward to 
improvements to a future keygen of course ).

It is my feeling that the TAG's finding is a much better place to start discussions from, as it tries
to have a principled view of the discussion.


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. 

so you start out your mail from the position that none of us who work in WebID-TLS understand anything about crypto, and
then you suggest that we are welcome as invited experts to join the WG..... Can you try to be consistent within one
e-mail message?


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.

As someone who studied philosophy (and not cryptography) you should be aware of the power of reasoned
discussion to change people's points of view. Certainly new facts on the ground should when relevant
change one's behavior.

And there is a lot that is changing in this space,  including improvements to TLS client certificate authentication 
for HTTP2.0 as for example the RFC proposal by Mozilla and Microsoft, whose most recent draft was just
published a little over a week ago:


So as you see TLS client certificates is continuously being worked on by top cryptographers, who
most certainly are not "home brewed", but active members of the W3C which you are meant to
represent.  

<keygen> provides very important functionality to allow those protocols to work on the web. 

Now perhaps the Work you are advocating is going to be better that what we currently have.
Great. But if so why advocate removing a key feature of the old system that would make comparison
of the two technologies difficult? Why the hurry?



   cheers,
       harry


 
Cheers,
Reto
 
 


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Nathan Rixham-2
In reply to this post by Chaals McCathie Nevile
How to do auth on web?

Honest and serious question.

WWW-Authenticate and Authorization provide basic (lol) and digest (mitm), so can't use them.

Alternative? Public key authentication (usually implemented with a HTTPS / SSL client certificate)  ... sounds good.

How to request, provide, or manage/select a client certificate with browser? nothing specified or implemented, maybe use keygen to request? (deprecated in live browsers), maybe provide a certificate with application/x-x509-user-cert (deprecated in live browsers), manage/select? (nothing specified)

keygen is specified and was implemented terribly, but where's the alternative.

How to do auth on web? A question I certainly can't answer, can anybody here?

On Mon, May 30, 2016 at 10:40 AM, Chaals McCathie Nevile <[hidden email]> wrote:
Hi folks,

there is an open issue [1] and open call for consensus [2] to remove keygen from HTML. Since the TAG, or its members, appear to have opinions about our spec, we'd be grateful to hear them.

cheers

Chaals

[1] https://github.com/w3c/html/issues/43
[2] http://www.w3.org/mid/op.yhs220oos7agh9@...

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 [hidden email] - - - Find more at http://yandex.com


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Anders Rundgren-2
In reply to this post by Chaals McCathie Nevile
On 2016-05-30 11:40, Chaals McCathie Nevile wrote:
> Hi folks,
>
> there is an open issue [1] and open call for consensus [2] to remove
> keygen from HTML. Since the TAG, or its members, appear to have opinions
> about our spec, we'd be grateful to hear them.

If you look into the comments I think there are two fairly unrelated
issues here where removing keygen represents the less important (Microsoft
never bothered with keygen and iOS doesn't support keygen either).

So the core issue is rather that the TAG considers using client-certificates
in an origin-unconstrained (including user consent) fashion is "wrong".

The problem with this is that this concept already is firmly established and
in some places in the world indeed working quite good as well.  I don't think I'm
alone finding it quite handy being able to open any number of "doors" with just one key.

Few if any of these deployments rely on keygen, they rather use their
own take on certificate enrollment.  After the deprecation of browser plugins
which have had a big impact on the Web ecosystem, quite a bunch of these
deployments have switched to "Apps".

What's really missing is a down-to-earth description of how for example
WebAuthentication could support the multiple door scenario.

Anders

>
> cheers
>
> Chaals
>
> [1] https://github.com/w3c/html/issues/43
> [2] http://www.w3.org/mid/op.yhs220oos7agh9@...
>


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Henry Story-4

> On 1 Jun 2016, at 14:10, Anders Rundgren <[hidden email]> wrote:
>
> On 2016-05-30 11:40, Chaals McCathie Nevile wrote:
>> Hi folks,
>>
>> there is an open issue [1] and open call for consensus [2] to remove
>> keygen from HTML. Since the TAG, or its members, appear to have opinions
>> about our spec, we'd be grateful to hear them.
>
> If you look into the comments I think there are two fairly unrelated
> issues here where removing keygen represents the less important (Microsoft
> never bothered with keygen and iOS doesn't support keygen either).
>
> So the core issue is rather that the TAG considers using client-certificates
> in an origin-unconstrained (including user consent) fashion is "wrong".

I don't see where you get that from. The Client Certificate document published by
the TAG here

  http://w3ctag.github.io/client-certificates/

says that inserting a key into an OS keystore should not be done without
user consent, just like a web page should not be able to start the camera
on the computer without user consent, or be able to access the users geo
location without her consent. All of that is well understood in fact, and
has not stopped browsers giving access to the camero or to geo location
information on the device.
 
> The problem with this is that this concept already is firmly established and
> in some places in the world indeed working quite good as well.  I don't think I'm
> alone finding it quite handy being able to open any number of "doors" with just one key.
>

I think the TAG finding does not disagree with that position. Do you have text
you can point to that goes in that direction?

>
> Few if any of these deployments rely on keygen, they rather use their
> own take on certificate enrollment.  After the deprecation of browser plugins
> which have had a big impact on the Web ecosystem, quite a bunch of these
> deployments have switched to "Apps".
>
> What's really missing is a down-to-earth description of how for example
> WebAuthentication could support the multiple door scenario.

I agree with you that the confusion about Single Origin Policy's applicability
to authentication across origins is what has stalled a lot of the work that would
have enabled  client certificates in browsers to be deployed to their full
capacity.

But to be fair, most of the browsers that have implemented client certificates have
held to this obvious restriction when dealing with using certificates accross origins.
The same is true about inserting a certificate into the OS level keystore, though perhaps
a lot of the browsers do not allow the user to easily specify if a certificate should
be only used for one origin or across origins... So improvements can be made.

So I welcome the TAG finding as it makes this obvious point clear.


>
> Anders
>
>>
>> cheers
>>
>> Chaals
>>
>> [1] https://github.com/w3c/html/issues/43
>> [2] http://www.w3.org/mid/op.yhs220oos7agh9@...
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: removing keygen from HTML

Harry Halpin
In reply to this post by Reto Gmür


On Tue, May 31, 2016 at 9:26 AM, Reto Gmür <[hidden email]> wrote:
On Tue, 31 May 2016, at 14:12, Harry Halpin wrote:
 
 
On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <[hidden email]> 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:
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:
 
Hopefully others will be more reasonable, but you may wish to familiarize yourself with this thread rather than endlessly repeat it.
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:
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
 
 

12