4 ms·

> One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections. I support the cupcake t

by daeken 14y ago

> One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections. I support the cupcake tax (we can discuss numbers later), but I think making it work only for HTTPS connections makes that seem like the biggest issue. I believe that XSS attacks, simply due to the ease of discovery and exploitation, are a much bigger issue here. Hijacking connections to a site (whether via MITM, DNS redirection, whatever) isn't easy, but XSS is downright trivial in most cases; it's definitely the biggest concern in my mind.

tptacek 14y ago
I think if you don't nail Web Crypto to TLS, people will see it as an alternative to TLS, which it isn't.
- sleevi 14y ago
  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 http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.
- briansmith 14y ago
  IIRC, that is exactly Netflix's interest in the API. Google for the "Netflix use case."
  - tptacek 14y ago
    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.

by daeken 14y ago

tptacek 14y ago

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

sleevi 14y ago
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 http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.
briansmith 14y ago
IIRC, that is exactly Netflix's interest in the API. Google for the "Netflix use case."
- tptacek 14y ago
  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.