[whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

>> In fact, do you know of *any* examples of MITM attacks
>> being successfully used against a public website?
> "Pharming" is effectively a man-in-the-middle, and in
> particular would be 100% effective at defeating the proposed  
> security feature. http://en.wikipedia.org/wiki/Pharming


Good point,
I agree that *without* external authentication (see auth="verisign"),  
pharming, poisoned DNS router or various kinds of malicious software  
on users computer could lead UA into communicating with attackers site  
or allow MITM to open the
encryption. But if external authentication service is using the  
auth="verisign" parameter, practical MITM attacks can be prevented.  
Someone said auth="verisign" would not suffice. No it doesn't...  
alone. I wanted the meta-encrypt footpring on pages to be small. So  
the actual CA company signed sertificate, which confirms  
pubkey="FAFFFA262662EAEEA" belonging to mydomainZZZ.com would be found  
from
  https://www.verisign.com/certificates/FAFFFA262662EAEEA.sig AND
  http://www.mydomainZZZ.com/verisign.sig

As UA can verify the document's verisign signature and therefore  
observe site's certificate & public key being authentic and good for  
use.

I am not saying this meta-encrypt tag would solve *most* security /  
privacy problems. I am just saying it would eliminate some of serious  
ones. Like salting the multi-used passwords that easily facilitate  
identity theft.
For example a valid meta-encrypt tag could look like this:  <    />    
i.e. NOTHING no tag at all. Meaning if a html5.01 standard would  
require user agents to, by default, salt the passwords using the  
domain name.
	sha256(userpass+domainname);

Then all browsers that confirm to the html5.01 would submit the salted  
passwords. but if target website had for
some (compability) reason a following meta-encrypt-tag
	<meta encrypt passsalt="no"/>
Then a html5.01 conforming browser would submit the password in plain  
text as it was typed

And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous
domain name, then the meta-encrypt-tag could be just...
	<meta encrypt passsalt="olddomain.com"/>

And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous
domain name, then the meta-encrypt-tag could be just...
	<meta encrypt passsalt="olddomain.com"/>

Thus a html5.01 conforming webpage could choose to use...
	<meta encrypt passsalt="current_domain_name.com"/>
	<meta encrypt passsalt=""/>
	<meta encrypt passsalt="yes"/>


That password salting 'security feature' would not be threatened; no  
matter where a rogue DNS or pharming-tool would direct the UA. And as  
always there are still special threats against password salting, e.g.  
physical or software keyloggers. But hey nothing is perfect.

The meta-encrypt tag, the passsalt="" argument alone, would have  
prevented facebook accounts and blogs of some of the leading finnish  
politicians being spied and vandalized - as recently happened after  
alypaa.com was hacked and 100,000+ username+passes were stolen. Ok  
that's all I want to say. Be well.

Juuso Hukkanen
www.colordev.com