- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Sat, 03 Mar 2012 01:53:01 -0000
- To: public-html@w3.org
On Fri, 02 Mar 2012 23:25:50 -0000, Ian Hickson <ian@hixie.ch> wrote: > I've now specced this: > > http://html5.org/tools/web-apps-tracker?from=7011&to=7012 > http://www.whatwg.org/specs/web-apps/current-work/#http+aes-scheme > > If anyone would like to edit a spec of this that's independent of the > HTML spec, let me know, I'd be happy to move this to another spec. Thanks! I wonder whether the protocol name should be a bit more generic, e.g. http+enc. It would be silly to be stuck with that name if AES was cracked, or if other encryption schemes were found to be useful. I was unable to find info whether AES-CTR gives any integrity assurance at block level. If it doesn't, then an attacker could corrupt selected blocks of the file transferred, and UA wouldn't be able to detect that during decryption. That could allow attacker to corrupt parts of image or video files in attempt to crash the browser. If that is the case, and random access is needed, then perhaps some kind of hash tree needs to be used as well, e.g. URL specifies top hash and HTTP headers include part of hash tree relevant to the range requested. <scope-creep> It would be cool if http+aes did not trigger mixed content warning on https pages to allow cheap hosting of non-privacy-sensitive assets on HTTPS/SPDY pages (e.g. if attacker sees connection to Facebook servers, then seeing Facebook logo and CSS downloaded doesn't reveal much, but those assets could be publicly cacheable while maintaining integrity). Unprotected headers are a problem, but maybe something can be done about it? Maybe allow only selected safe headers to be used by UA, and require content to match a hash (and type?) specified securely, e.g.: <link type="text/plain" href="http+enc://sha1:%F7%FF%9E%8B%7B%B2%E0%9Bp%93Z%5Dx%5E%0C%C5%D9%D0%AB%F0@example.com"> would only accept a text file containing "Hello". The above example also shows that a random key as URL-encoded ASCII is unlikely to be shorter than a hex or base64 representation. -- regards, Kornel Lesiński
Received on Saturday, 3 March 2012 01:53:29 UTC