Re: Draft finding - "Transitioning the Web to HTTPS"

Convergence.io

Anyone looked into it? Pros and cons vs CA? Why wouldn't be also supported by default in browsers? If https is imperfect in that it can be undermined by a powerful adversary then why not open up the debate for supporting alternative schemes in addition. What is bad about centralizing authority? And what is bad about decentralizing it? Pros am cons. Can't understand why we would have centralized but not decentralized when both are imperfect and open to attacks. Why the philosophical bias? Or is it a political bias? Or just people isn't think with an open mind? Too much fear about decentralized security? Or keeping power in established power structures? 

Sorry to keep bringing up the same point but we are confronted with evidence that the argument against decentralization is iffy at best. 

Sent from my iPhone

> On Dec 17, 2014, at 3:36 PM, Chris Palmer <palmer@google.com> wrote:
> 
>> On Wed, Dec 17, 2014 at 8:46 AM, Marc Fawzi <marc.fawzi@gmail.com> wrote:
>> 
>> Btw, on a related subject, stuff like "signed scripts" which were proposed
>> on this list by an independent developer (with the conclusion being that
>> signing a script at least assures that it's not be altered) might be part of
>> a more perfect foundation. The argument I heard here against Web Crypto over
>> HTTP (or more comprehensively stuff like OpenPGP.js which used by Google for
>> its End-to-End security plugin) for client-to-server secure exchange is that
>> MITM can alter the script, but a signed script would solve that, so
>> regardless of whether you use a CA or not you should be able to get pretty
>> good privacy, right? (assuming signed scripts or signed Chrome/Firefox
>> hosted apps)
> 
> Think about this. What would the root of trust for script signatures
> be? Perhaps script execution environments could be born with the
> public keys of trusted third parties that vouch for the identities of
> script authors...
> 
> 
> If you are referring to Sub-Resource Integrity (SRI), at least the
> top-level page that includes the resources has to be served over
> HTTPS, so that the SHA-256 hashes for the sub-resources are at least
> minimally trustworthy. So you haven't really avoided the secure
> transport requirement for WebCrypto.
> 
> (Of course, I argue that even the sub-resources must be served over
> secure transport, even for/especially for SRI. But that's a whole
> other thread.)

Received on Friday, 19 December 2014 18:45:15 UTC