There are two new web trends standards on the block that I think have a decent future, HTTP Strict Transport Security preload lists and .onion alternate addresses such as like Facebook and Blockchain.info providing SSL signed .onion domains.

To start with the preload lists, just checking out the criteria for Chrome and Firefox, specifically rfc6797 for example forces a max-age on the header field — something I can imagine being omitted or simple screwed up by a casual developer. Combined with a per-browser application process — HSTS preloads are simple not a standard that your typical systems administrator will want to implement.

Onto .onion alternatives, I found (and cannot find again :( ) a plugin that finds .onion alternatives for mainstream sites, allowing a user to passively have an enhanced Tor browsing experience without returning to the clear net through those pesky hostile exit nodes. Clearly onion routed network access is the next ‘supports SSL’ feature for your website of the future.

So, how could we standardise a way for a website to signal to a user how to access them under these increased security options? DNS records of course!

Well first of all your site and user’s clients need to support DNSSEC, which whilst full adoption may be a few years off, I think we’ll get there.

Then, let’s put our policy in our records:

example.com:

name: www

type: A

data: 1.2.3.4

Now let’s add a custom record to announce HSTS policy:

name: www

type: txt

data: HSTS=YES;PORTS=443,8443;EXPIRY=6000

And another to announce some alternative domains:

name: www

type: txt

data: TOR_DOMAIN=123456.onion;I2P_DOMAIN=123456.i2p

If such DNS standards were used to govern this data, appropriately configured browsers could seamlessly secure user requests and further anonymise them with no further user intervention. Hurrah!

Edit — it’s come to my attention that a working group for ‘DNS-based Authentication of Named Entities (dane)’ is working on creating stronger standards for the dissemination of info in DNS specifically cryptographic keys presumably like with DKIM. However I don’t think it’s in the same space really.