Re: removing keygen from HTML

On Wed, 8 Jun 2016, at 14:28, Harry Halpin wrote:
>
>
> On Tue, May 31, 2016 at 9:26 AM, Reto Gmür <reto@gmuer.ch> wrote:
>> __
>>
>> On Tue, 31 May 2016, at 14:12, Harry Halpin wrote:
>>>
>>>
>>> On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <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?
>>
>> 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
It was not my intend to imply that you work for the NSA I do apologize
that  I formulated my sentence so poorly that - as I realize now -
someone could deduct that you work for the NSA. To be explicit: I do not
believe nor did I used to believe that you work for the NSA or  worked
for the NSA.
 
I do however believe that the NSA did try to influence standardization
processes to create weaker security and probably still are. I also
believe that they would always pretend to increase security while their
actual intent is to postpone secure technology and reduce the chances
they are adopted or implemented without vulnerabilities such as by
increasing complexity.
 
>  -  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.
I completely agree that SOP is an essential security feature for code
downloaded from a website and running in the browser  without the user's
explicit consent. If a webpage could use keygen to generate a key and
this key is installed to the keystore and subsquently used on other
sites without the user's explicit consent this would violate the user's
privacy. However I haven't seen a browser doing this like that, in my
experience user's consent is required both when installing the
certificate as well as when using the certificate. With this user
interaction there isn't the possibility to secretly track a user's cross
domain activity.
 
If one wants to dogmatically apply SOP one should also cry havoc if a
browser downloaded from microsoft.com can access sites outside the
microsoft domain.
 
 
> 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.
 
- Webcrypto is not a proposed recommendation yet and the document warns
that it is unstable.
-  The Web Authentication working group has not yet releases a spec
and depends on the Credential Management API which is still in the
draft phase.
- "soon-to-be deprecated": this seems to be kind of begging the
  question, in my opinion it shouldn't be deprecated before better
  alternatives have become standards and after deprecation it shouldn't
  be removed for a period long enough to allow users and implementors to
  transition.
 
 
>
>>
>>
>> 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.
I'm really confused now, searching the W3C site for "Web Authentication"
I find the working group. On the WG page there's a link to the
deliverables that points to
https://github.com/w3c/webauthn/blob/master/PubStatus.md which doesn't
list any deliverable yet.
 
Is there a standard that allows me to create a key-pair, advertise my
public key, have other sign it and use the keypair for authenticating
with (potentially) any  websites as well as to sign the keys of others?
 
Cheers,
Reto
 
>>
>>
>> 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:
>>> 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
>>>>
>>>>
>>
>>
>> --
>> Reto Gmür
>> reto@gmuer.ch
>>
>>
 
--
Reto Gmür
reto@gmuer.ch