Re: removing keygen from HTML

> On 31 May 2016, at 14:12, Harry Halpin <hhalpin@ibiblio.org> wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <reto@gmuer.ch <mailto:reto@gmuer.ch>> wrote:
> On Tue, 31 May 2016, at 10:04, Harry Halpin wrote:
>> I do not know anyone from the cryptographic or security community that would support keeping <keygen>. Indeed, the default response from the security/crypto community would be to drop <keygen> due to legacy usage of MD5 and violation of security boundaries (SOP). 
> 
> That would also be my response if I was employed by the NSA and wanted to prevent technologies that allow user controlled strong cryptography and decentralized networks of trust (as enabled by webId).
>  
> 
> Reto,
> 
> That was both an idiotic and offensive statement. Can you explain how amateur
> crypto and home-brewed protocols that no-one in the security or crypto community
> reviewed or supports is the way to fight the NSA?

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 
https://lists.w3.org/Archives/Public/semantic-web/2016May/0089.html <https://lists.w3.org/Archives/Public/semantic-web/2016May/0089.html>

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

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

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/ <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:

   https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01 <https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01>

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