Re: Comments on last call

On Mon, May 5, 2014 at 10:38 AM, Salz, Rich <rsalz@akamai.com> wrote:

> Ø  start making opinionated design decisions, you no longer have an API
> toolbox –
>
>
>
> Gee, not even well-informed opinions?  J I agree it’s a toolbox. My
> concern is that it is a toolbox with no guidance, operating instructions,
> or safety goggles.
>
>
>
> GlobalSign is a neat hack. But is it really a use-case?  I have a
> colleague who implemented SHA-1 in XSLT.  Is that a use-case?
>

>
> > Consider, for example, how SMTP over TLS buys *nothing* for E2E email
> security, in a land of MX relays. You can trust your mail server, your peer
> could trust theirs, but in the world of MX and SMTP, that doesn't mean
> anything.
>
>
>
> Which is why I didn’t include it in my “just use TLS” list.
>
>
>
> > Conflating with ActiveX is... inaccurate, to say it politely.
>
>
>
> ActiveX sent object code to the browser.  You want JS, sent from a server,
> to be able to do anything that native code can do.  Seems like a reasonable
> vcomparison to me, and worth learning from.
>
>
>
>                 /r$
>
>
>
> --
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge, MA
>
> IM: rsalz@jabber.me; Twitter: RichSalz
>

I suspect we're further getting to a point where we won't be able to agree
/ take the feedback meaningfully, as it seems you fundamentally disagree on
what we're trying to accomplish. Our charter makes it clear what we're
scoped to deliver, and there was and has been ample time to criticize that.

Is an ActiveX comparison even remotely accurate? Not in the wildest world
of paranoia. Equating unsandboxed, unmediated access to arbitrary devices
to a sandboxed, capabilities-backed framework is so far in the
apples-to-oranges territory, that it's crossed into apples-to-tire-irons.
The W3C and WHATWG have been working quite hard to extend the web forward
with new capabilities - WebGL, Web Audio, the File API - that accomplish
the goal of ensuring JavaScript has the *capabilities* of native code. That
does not equate to the same security model or unmitigated access. You can
read a brief manifesto of these actions - actions that have driven the Web
standardization community for quite some time, and which just as well
justify the actions of WebCrypto - at http://extensiblewebmanifesto.org/

Is PKI.js a valid use case? Absolutely. Why shouldn't it be?
https://groups.google.com/a/chromium.org/d/msg/apps-dev/_UqhkL0rwdo/j_GOuqIZI3gJis
proof positive of how you can implement secure protocols on it.

Why shouldn't support for something like PGP or S/MIME/CMS be a valid use
case - especially keeping in mind this WGs charter.

I can't help but feel like we're not going to get much more productive
discussion out of this, but I did want to take the time to acknowledge your
feedback, to respond and highlight how it was either based on certain
misunderstandings (eg: HMAC-SHA1, AES-CBC) or misguided in its goals (in
the sense of how "just use TLS" is not a reasonable or appropriate
response).

I certainly appreciate you taking the time to read and review this. While I
had hoped that we'd come at a point where the feedback was actually in line
with how suitable or not this WG has delivered on it's charter and its use
cases, I can't help but feel like you do not feel JS - whether on the Web
or in Sys Apps - should not be allowed access to cryptographic services, or
those that it should be allowed should only be a blessed set that few-to-no
protocols even use, so I doubt we'll reach agreement here.