- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Fri, 23 Jan 2015 16:59:00 +0200
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- Cc: Public TAG List <www-tag@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Henry Thomson <ht@inf.ed.ac.uk>, Mark Nottingham <mnot@mnot.net>, Chris Palmer <palmer@google.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "Michael[tm] Smith" <mike@w3.org>, Tim Berners-Lee <timbl@w3.org>, Paul Libbrecht <paul@hoplahup.net>
On Mon, Jan 19, 2015 at 3:44 PM, henry.story@bblfish.net <henry.story@bblfish.net> wrote: > 3. Unneeded cryptography > > First I think TLS has a mode with 0 encryption. This should of course be > visible in the UI. > ( just verification that the content has not been changed en route) > This may cover some of the issues brought up, such as those related to > encrypting large > video files. Large video files in quantities where the overhead of the symmetric cipher in the straw that breaks the camel's back is very much a special case. I think it doesn't make sense to enable more opportunity for TLS misconfiguration to cater to that case. For pretty much all other cases, blaming the symmetric cipher on performance grounds doesn't make practical sense. > 5. Client side certificates I think this TAG finding should not get side-tracked into https-related fringe features like client-side certs. In particular, client-side certs are far worse a piece of technology for endorsement than the parts of https that the draft finding currently endorses. Specific problems include (not necessarily an exhaustive list): 1) In currently-deployed versions of TLS, the most obvious way to request a client cert results in the client cert being sent in the clear, which exposes information that identifies the user to eavesdroppers who can use this for surveillance or for targeting malware injections. It's non-obvious to users that accessing an https site leaks info like this when people have been taught that https means that the connection is encrypted. I think this will remain a major problem until server-side support for encrypted transfer of client certs is so commonplace that browsers can start refusing to send client certs in the clear. 2) In the case of associated private keys stored on disk, syncing the certs to all browsers that the user wants to use on all devices that the user wants to use is a usability problem. 3) Trying to fix that problem by storing the private keys on a hardware device leads to driver problems and a ball-and-chain that (if client certs were use more; fortunately they aren't) would limit the progress of technology. (You can't stick a credit card-sized smart card in a phone, for example. Good thing most people don't need to and the mobile Web was able to take off. And, before you say "SIM", consider wifi-only tablets, etc.) -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Friday, 23 January 2015 14:59:27 UTC