- From: John Kemp <john@jkemp.net>
- Date: Fri, 22 Aug 2014 16:39:42 -0400
- To: Jeffrey Yasskin <jyasskin@google.com>
- CC: Chris Palmer <palmer@google.com>, Adam Langley <agl@google.com>, Eduardo' Vela <evn@google.com>, Mark Watson <watsonm@netflix.com>, Jim Manico <jim.manico@owasp.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 08/22/2014 03:59 PM, Jeffrey Yasskin wrote: [...] > It's definitely not the same thing, but it seems to be a prerequisite. > Specifically, you need an encrypted transport layer *and* some measure > of trust in the entity it's saying you're communicating with *and* some > measure of trust that the CA hasn't been compromised. If you don't have > an encrypted transport layer, the browser can tell you haven't > authenticated the server to perform a confidential operation, so the > browser should block that operation. That's the core of the secure > origins proposal, so I'm having trouble seeing why you disagree with it. It sounds as if you are relying on a TLS server certificate to be the "strong authentication" of the server? In other words, its not the encryption of the transport you care about for validating that an origin is secure, but that the encryption depends on the server using a certificate - right? So, first of all, I do not think that (server certificate) is a good guarantee to a user, on the open web, that the browser has authenticated (in any real way) the server. Secondly, I think it is possible to get transmission of confidential data without transport encryption at all. If two parties can agree that mechanism either with or without a standard mechanism in place, and they can convince a user that they are trusted to do so, why shouldn't they be enabled by this standard to call these powerful web platform APIs? As mentioned, I like TLS for encrypting data in transit. Regards, - johnk > > *After* that, we get into the ideas around choosers that, e.g. > https://webbluetoothcg.github.io/web-bluetooth/#widl-BluetoothDiscovery-requestDevice-Promise-BluetoothDevice--sequence-BluetoothScanFilter--filters > takes advantage of, which help find out what data the user trusts the > site with. > > Certificate transparency seems to be about the third aspect of the problem. > > > Regards, > > - johnk > > * what she actually means is "don't make me have to come and get you!" > > > > -- see the "ceremony" idea you mention above), and also to > state > that TLS only protects data while in transit between a user's > network endpoint and the network endpoint with whom they are > communicating. It is not a solution (without additional > context at > least) either for authentication of the parties, or for > ensuring > that a user's data remain confidential once transmitted to > any other > party. > > Regards, > > - johnk > > > > > > > > >
Received on Friday, 22 August 2014 20:40:19 UTC