[whatwg] meta="encrypt" tag is needed

[And Clover]

On 05/06/2010 02:44 PM, juuso_html5 at tele3d.net wrote:

> browser submits a (session specific) 256bit elliptic curve public key
> to the server inside every URI-request AND if the target page has
> meta-encrypt tag, the server uses the browser's elliptic curve key

The server has to read and correctly parse each HTML page to decide 
whether to encrypt it? (And how does the browser know that the page is 
encrypted, vs. a legacy server that doesn't encrypt?)

This proposal is tackling the problem of encryption at entirely the 
wrong level: it's nothing to do with HTML, it's to do with the 
connection between the browser and the server. It is very likely that 
sites would want to encrypt transfers of other files than HTML pages. 
This is something that should be tackled at the HTTP level, not in HTML5.

And lo, there is already a quite suitable mechanism for deploying 
encryption between the server and browser: HTTPS.

Whilst it is true that HTTPS has more organisational overhead in the 
form of CAs, and more server overhead in the form of making virtual 
hosting difficult, there are technical approaches to improve this 
situation (DNSSEC-based certs, SNI), and, notably, this overhead is 
*necessary*.

Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, 
just like your proposed protocol is. Without attestation that the site 
receiving the `pubkey` token is who it says it is, the encryption 
between the two is worthless. It would only protect against passive MitM 
attacks, but in reality if you are in a position to MitM passively you 
are very likely to be able to throw in an active attack just as easily.

> please don't say you instead you can use https / JS or some other thing
> that JUST DOESN'T WORK in real life.

HTTPS works fine. JS client-side-password-hashing approaches suffer from 
the same problem as your proposal: they can only ever protect against 
passive attacks.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/