[whatwg] meta="encrypt" tag is needed

Fri May 7 14:46:55 PDT 2010

On Thu, May 6, 2010 at 8:44 AM,  <juuso_html5 at tele3d.net> wrote:
<meta="encrypt" pubkey="ABABAEFEF2626EFEFEF"
pubtool="EC256-AES|RSA2048-AES"
passsalt="no|domainname" auth="verisign">

Good observations Frank & Ash & Aryeh & others,

> I see a few shortcomings in this approach:
> a) each document is encrypted asymmetrically, affecting performance.
1) yes, that's partially true. What is asymmetrically encrypted is
the keys to symmetrical encryption; which is much faster

2) no, that is not required. if user agent stores the AES password
    e.g. inside a session cookie, "beyond the login page" the web-pages
    can have meta-encrypt-tag pubtool="cookie-AES".
        ==> thus when UA requests page, server requests a cookie named
	according to meta-encrypt pubkey="_value_".
        ==> that cookie named _value_ contains the symmetrical AES key
        ==> so, server sees the UA has a proper pubkey
        ==> server encrypts the page using symmetrical AES and sends it to UA

3) no, that's not required for the passsalt="no|domainname" argument.
    salting happens only in UAs, passsalt argument is a hint to browser
    to hash the password field before submitting it to server. server
    would treat the salted password as any normal 'properly randomized'
    password.

> b) there is no management of keys (expiration, revocation, trust, etc).
1) IF auth is used, CA can validate pubkey belonging to site until xx/yy/zzzz
    Browser can remember authentication and store
    'SHA256(domainname)','pubkey','validuntil'
2) IF external auth is not used site can generate it's own key pair ,  
using some
    w3c? accepted / authenticated key generator tool, and the  
webmaster then just
    puts the public key into meta-encrypt tag and the private key  
into... server
    accessable location maybe .htpasswd file
3) ...so Dear Watsons... as the browser sees the meta-encrypt tag it (*may* be
    configured) to contact CA and validate the pubkey belonging to site using
    all the formal https validation techniques... What is left to the webmaster
    is to insert a simple meta-encrypt tag

> c) the values for the pubtool attribute (encryption algorithm) will need to
be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
1) yes, that's true, some specsing is needed as there are competing  
PKI technologies, with small key sizes, elliptic curves good  
candidates as they are well studied and at least to sufficient degree  
patent free. Initial specsing has also been done e.g. by "the OpenSSL  
team accepted an ECC patch in 2005", Also NSA may provide helpful  
'ideas'
	http://en.wikipedia.org/wiki/ECC_patents
	http://www.nsa.gov/business/programs/elliptic_curve.shtml

> d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?
1) I'm sure you'll find a solution ;)

> e) information from the UA to the server is plaintext (e.g.,
logon/passwords).  If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.
1) 'meta-encrypt'- tag encrypts only from UA -> server. IF there is a
     meta-encrypt tag on a requested page, UA encrypts URI-request the form
     parameters it sends to server using the pubkey="" public key

2)  submits the browser's own pubkey to the server inside
    each page-request to the server. the 'UA-encrypt' field may be valid only
    for a session. if a page has a 'meta-encrypt'-tag and a browser has
    a 'UA-encrypt'-field, the server
     +) can generate a AES256 key and encrypt the page using it
     +) return the requested AES256 _encrypted_ page to UA, but the  
pages first line is a PKI encrypted message containing the AES256 key  
that opens the 'page'
     +) UA notices the BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line
     +) UA tries it's own session private key to ENC-MESSAGE, opens  
the message,
        reads the AES256 key
     +) UA opens the page using the AES256, and shows the page content  
as any web page

3)  UA gets all page content in from requested URL in fully encrypted  
form server gets all the POST/GET parameters (from UA) to the page in  
fully encrypted form

4)  if page had a passsalt="no|domainname" form-field with or without  
the 'meta-encrypt'-tag, UA hashes the password field with SHA256 and  
submits the SHA256(password+domainname) to the server instead of plain  
text password.

> I'd prefer a radically different approach (TLS = out of scope).

There certainly are many technically excellent solutions. My approach  
just focuses in and can
a) make it maximally easy and usable for 'typical' webmasters to use
b) and force the passwords salted; thus preemptively preventing id-thefts

Ash,

You're quite right, what I am suggesting is a server module which may  
be on/off.
- if the meta-encrypt module is off, server module doesn't read the  
page before submitting it.
- if the meta-encrypt module is off, the UA still sees e.g. <meta  
encrypt passsalt="no|domainname"/> and the UA can salt the  
form-password field
- if the meta-encrypt module is off, UA receives the page content without the
   BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line, and yet  
the UA *sees* the meta-encrypt-tag on page, thus the UA concludes  
server's meta-encrypt module is off. So if a page visitor wants to  
fill a form on a page, before submitting the GET/POST parameters to  
server, UA pops up a screen
	/////////////////////
	Receiving site has it's encryption engine
	turned off. Do you still want to submit
	data to that site, as unencrypted plain
	text data?
	|YES|        |NO|
	//////////////////////

- Obviously a server must read the data chunks from a hard disk or  
similar before it can submit those.
   A server _module_ would be given e.g. two first 4096 byte chunks  
from certain file types (html,htm,php). Module would check if there is  
meta-encrypt tag (or </head>).
	- if meta-encrypt was not found but </head> would be
	==> module would return 0,
	    and apache/IIS would submit the page unencrypted
	- if meta-encrypt was found
	==> module would return 1, and apache would hand over
	    the whole file to module as well as the UA's public key
	    ==> module would encrypt file and return it to apache
		so it could be sent to UA. Also the module
		would have parsed all the related file URLs that were
		included in that original page. And module would
		request apache to read the included file(s) and the
		module would would encrypt them all

> What you're suggesting is that web servers be set up to parse HTML  
> pages, or an extra server
> module (like PHP) to parse HTML content.

Yes, PHP and other scripting languages are popular. If a site or a  
server doesn't want to use PHP module (or meta-encrypt-module) they  
can choose not to install it or they may exclude files in  
(home)directories and all-subdirectories not to be using PHP-module  
(or meta-encrypt-module) just
by setting it off e.g. using .htaccess file of 'apache/ISS' settings file.

>>> 1) Man-in-the-middle problem; which doesn't exists because
>>>        a) those are just academic mind games
>>
>> You don't get to talk about security anymore.
>
> I don't think "academic" is an *entirely* unfair characterization of  
> MITM on the web, actually.
...
> In fact, do you know of *any* examples of MITM attacks being
> successfully used against a public website?

I double that question. And before I generalized the internet MITM  
attacks against PKIs being "academic mind game" (ok NSA & Co could  
prove other vice), I googled and checked the wikipedia, if there were  
any real life examples of internet MITM attacks against  
unauthenticated PKIs, but no all seems to be non-internet site like  
examples. Sure MITM can be done, but it's not the low hanging fruit;  
that concerns most ordinary websites. AND just to tackle that  
authentication problem I added the auth="verisign" parameter

We know hundred ways of how the HTTPS mediated security would easily  
fail, but almost all off those would be "hacker-at-the-other-end  
attacks". The real life data security problem is the identity thefts,  
espionage and frauds. Where the unsalted passwords and multi-use of  
same passwords play a key role as well as in minor degree, sniffing of  
unencrypted traffic. Why would anyone even consider cryptographic MITM  
attact for the purpose of achieving identity theft, as the  
hacker/keylogger-at-the-other-end can achieve the same goal with less  
effort. After all Internet is just a massive security hole, with of  
without the HTTPS.

see the article at http://xkcd.com/538/

Juuso Hukkanen
www.colordev.com