Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

Again removing public-webcrypto-comments.
On May 28, 2014 7:33 AM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
wrote:

> I don't have much to offer regarding the algorithm issues but I believe
> my 15Y+ with (mainly unsuccessful) security standardization efforts
> have given me at least a perspective on this.
>
> There are no entirely objective and honest persons around.
> We all have something to defend like "professional relevance",
> our employer's legacy systems, and last but not least our egos.
>
> The W3C also have another objective: keeping their big members
> happy since they pay their salaries.
>
> In addition, people have rather different personalities making
> it hard getting a reasonable climate for open discussions.
>
> I once complained to Linus Torvalds that Linux lacked cryptographic
> architecture and he said he had given up on that since security-
> people never agree on anything.  I think he is right :-(
>
> Anders
>
>
> On 2014-05-28 15:28, carlo von lynX wrote:
>
>> Sorry libtech, some of the in-between mails were not forwarded
>> to you.
>>
>> On Wed, May 28, 2014 at 02:21:55PM +0200, Anders Rundgren wrote:
>>
>>> Asking for "consensus" on anything security-ish under these
>>> circumstances is simply put impossible.
>>>
>>
>> That's because you can't build consensus if some participants
>> have an interest on dominating over others. The method of
>> consensus requires the group to remove such elements in order
>> to be able to work out a consensus which is best for the group -
>> and in this case the consensus must be privacy for humanity,
>> not security business models for companies or obligations to
>> their respective governments.
>>
>> So the mistake in the method you are applying is well-researched
>> and has an answer. Issues concerning basic constitutional rights
>> of citizen must not be defined by a standards body open to
>> entities and elements with incompatible interests.
>>
>> Thus, Webcrypto CANNOT be reasonably be brought forward by
>> either W3C or IETF.  q.e.d.
>>
>>  Following the logic in your reasoning, you should list all the
>>> algorithms that should be deprecated.  I'm not a cryptographer
>>> but I'm quite familiar with security protocols and that's where
>>> things go really wrong.  If you take a peek in the IETF-TLS
>>> list you will get an idea of the complexity building secure
>>> protocols.
>>>
>>
>> That is a fallacy. Negotation is a bug. GNUnet comes with one
>> wise choice of a cipher. Should a sufficiently relevant new
>> cipher be invented, GNUnet will have a transition period -
>> but that's it. No backwards compatibility humbug forever.
>>
>>  BTW, I'm not a member of the WebCrypto WG but I mentally support
>>> the work anyway.  If somebody comes up with a better mousetrap
>>> I don't think anybody will object :-)
>>>
>>
>> That's why you are perpetuating this debate which is VERY
>> much not in the interests of the W3C members. I like it.
>> Thank you for letting Eleanor's and my voice be heard.
>>
>>  There were requests fora high-level API that would hide the
>>> complexity as well as always using the "best" algorithms.
>>>
>>
>> Oh that's easy.. you can look at NaCl or EthOS for inspiration.
>>
>>  It was rejected and IMO on correct grounds because there
>>> would be endless discussions on how such a thing would work
>>> and in the end nobody would be happy anyway.
>>>
>>
>> It is totally among the duties of the advanced lobbyist to
>> know how to gently and delicately break consensus processes.
>> Of course a consensus could be found, but only among honest
>> participants. If you weren't successful, this is by today's
>> knowledge on democracy research a proof that your work has
>> been undermined by at least one participant who had no
>> interest in achieving consensus.
>>
>> Or did you expect secret services would walk into the
>> working group meetings armed with machine guns and coerce
>> everyone into stopping to work on reasonable crypto
>> technologies for the masses?
>>
>>
>>
>
>

Received on Wednesday, 28 May 2014 14:55:39 UTC