Hacker News Reader

Comment by tptacek | Hacker News Reader

I think if you don't nail Web Crypto to TLS, people will see it as an alternative to TLS, which it isn't.

For what it's worth, while I object to your tax-and-spend approach with cupcakes, I do subscribe to your TLS-only newsletter for key-utilizing operations, and had proposed that already. Keyless operations are more of a gray area of policy rather than security. For example, should hashing require TLS? I think not, since there are non-crypto-but-still-useful applications of cryptographic hashes and random numbers (eg: name-based or PRNG-based UUIDs as described in RFC 4122). However, splitting the interface into TLS and HTTP segments is something that has its own issues.

It's possible that a compromise might be the "Secure Cookie" equivalent of specifying policy (HTTPS-only) when creating or importing keys, but I hope it doesn't come to that.

That said, I'm also a big proponent of requiring some sort of sane CSP settings to also narrow the scope of the API usage ( http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.

IIRC, that is exactly Netflix's interest in the API. Google for the "Netflix use case."

I understand that now, after talking to David Dahl on twitter. That's extremely dispiriting. I wish you guys would think twice before caving on this issue, because while Netflix can benefit marginally from something like this, the Internet will be harmed to a much greater extent. There are a lot of site operators out there who are enthralled by mythologies about how expensive TLS needs to be and how easy it is to replace TLS.

For what it's worth, at Dahl's suggestion (and because I was off work sick yesterday), I read every thread on the mailing list archive and saw the design issues that were batted around on this. I now think the overall goal of this effort is unfortunate and the effort is star-crossed.

I have more respect for Eric Rescorla than anyone else I can think of working in standards, but interoperability with existing crypto is a terrible, terrible goal for a web crypto API. I'm not saying "no good can come of it", just that I can't think of any good that is likely to come of it and I can think of a lot of bad stuff.

Reply on news.ycombinator.com