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

Eleanor,

Yesterday I had a long tel-conference with a person representing
TrustedComputingGroup and secure hardware.  He claimed that
"Android is completely insecure" and therefore all critical
applications MUST run inside of the TEE.  However, few if any
third-party applications currently run in TEEs.  IMO, they
wont do that in the future either.

Asking for "consensus" on anything security-ish under these
circumstances is simply put impossible.

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.

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

There were requests fora high-level API that would hide the
complexity as well as always using the "best" algorithms.
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.

Regards,
Anders


On 2014-05-28 12:31, Eleanor Saitta wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2014.05.26 15.54, Anders Rundgren wrote:
>> I guess the problem is that writing secure applications remain
>> difficult.
>>
>> The (in)famous "heartblead" bug is is a recent example of that.
>> Promising secure applications by using secure algorithms would be
>> wrong because that is only a part of the problem.
>>
>> Packaged solutions may provide solutions for people with limited
>> knowledge of secure applications.  Such packages can be written on
>> top of APIs such as WebCrypto.
>
> This is a complete abdication of your duty to the community.  You are
> suggesting that primitives intentionally enable dangerous features
> because "security is hard" and "people could write bugs anyway".  This
> is an utter joke and a direct sabotage of the security of the largest
> computing platform we have right now.
>
> FIX YOU BUGS IN THE PLATFORM OR DON'T PRETEND YOU'RE HELPING SECURITY
> AT ALL.
>
> This is *not* hard.
>
>> We must not forget that the banks haven't managed creating secure
>> credit-card payments on the web although they have had 20 years to
>> think about it :-)
>>
>> Due to the latter no even the "secure" EMV-cards are more secure
>> than the non-secure dittos when used on the Internet.
>
> Again, thank you for using the failures of other industries to excuse
> your own.  Which side are you actually on?
>
>> WebCrypto will hopefully spur further innovation in this field!
>
> I look forward to putting your innovation in body bags.
>
> E.
>
>> On 2014-05-24 13:19, Eleanor Saitta wrote: On 2014.05.24 09.54,
>> GALINDO Virginie wrote:
>>>>> Anyway, thanks for taking the time to share your view with
>>>>> us. You are pointing us to an interesting problem, that we
>>>>> discussed intensively. We are currently trying to see how to
>>>>> word warning to developers in the specification to encourage
>>>>> them to understand the web security big picture. That task is
>>>>> not easy due to the always-living side of the
>>>>> security/cryptography science.
>>
>> I find this approach a little worrying.  While clearly warning
>> developers is obviously preferable to *not* doing so, it's also
>> been shown to be largely insufficient over the past 20-odd years.
>> If the default behavior of a system is unsafe, developers will
>> generally implement that behavior, regardless of what your
>> documentation warns them to do.  It would be better for the state
>> of web security to provide a significantly more limited but default
>> safe API.
>>
>> If there is no API, developers needing to solve related issues
>> will roll their own and get it wrong -- the state we have now.  If
>> there is a safe API, they're more likely to make architectural
>> choices on the basis of that API, because you've shaped the level
>> of effort from "either way I'm going to have to do everything" to
>> "I can stay within this box that I recognize as being trustable, or
>> I can do all the work myself".  Shipping an API that allows
>> developers to be unsafe puts you right back in the position where
>> they can choose to shoot themselves and their users in their
>> respective heads with no extra effort.
>>
>> Every time we see bug classes entirely eliminated at the platform
>> level, we see those bugs mostly go away in the wild.  Every time
>> we see "guidance" provided, we see little or no impact in the
>> incidence of those bugs.  The web crypto API will be used in
>> life-safety critical code.  If you get this wrong, people will
>> die.
>>
>> Enjoy your guidance.
>>
>> E.
>>
>>>
>>>
>
> - --
> Ideas are my favorite toys.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlOFuxQACgkQQwkE2RkM0wpyHQD+IhNCV8FRsb7pUpm45weuZbxt
> IJCzNXR4L1jSt0g9TMsA/Rea6H53yzBvYBzEg23epdup464t52k6pK4wTQOpauYw
> =tOki
> -----END PGP SIGNATURE-----
>

Received on Wednesday, 28 May 2014 12:22:31 UTC