Fry me for a catfish. This is an exclamatory used by a dear friend that fits my mood right now. Incredulity. This is a suggestion for the IETF to hand to ICANN, and whatever organization follows them. ICANN are the people that assign names. They're a controversy unto themselves, but a set of Responsibility Protocols might help them regain some of their lost dignity.
Today, there are millions of top level domains, provisioned initially by ICANN and designated name registries. Whether it's .com or .name or .xxx, your name is gold—an asset that ought to be worth something to others. But just because you can register a domain doesn't you have to be responsible for them. This fact, irresponsibility, needs to stop. If you can't be responsible with your loaded gun, you need to have the gun taken away from you.
What kind of bullets are fired from your metaphorical domain gun? Let me dish up a few examples:
The FREAK and Bar Mitvah RC4 Attacks
RC4 attacks permit your seemingly safe https: domain to twist encryption selection to something pretty simple to hack and crack. Somehow, your site still allows for this ancient, dangerous, and easily corrupted encryption algorithm to undermine TLS security. If your site can use it, it can downgrade security in ways you didn't intend, right? Don't want to propagate THAT, do you? No, places like whitehouse.gov wouldn't do that, would they?
Mail Hosting Irresponsibility
Looking at you, Yahoo and Tom.com. Every domain holder, active or not, needs to have an abuse account to report security or spam abuse. The security or abuse must then be dealt with within a reasonable amount of time.
This account cannot have a spam filter that prevents a forwarded spam message, hopefully with the mail's headers, from being received. Looking at you, Tom.com. Or maybe you use an obscure RFC to mandate abuse reporting that no one can use, thus sending your mail abuse problems conveniently to zero—looking at you, Yahoo.
Oh, then you have to deal with it. Kill spammer accounts. Yes, you. Yes, now. Yes, noting their IP address, ban them. If it's a user in your domain, you have to shut them off until their bot machine is cleaned so that it can't be used as a spam source. Looking at you, Comcast, BTInternet, to name a few offenders. No active abuse account recipient? Then your domain name should be renewed until proof exists that an abuse account is both alive and working. Failing this, pull the domain from DNS and route it to a "Sorry, Folks" page.
Skinny Security, A/K/A No Secondary Auth
It's bad enough that sites like United Airlines use POST pages with mixed plain-text and encrypted information, but it ought to be mandatory—if you're taking money or storing private information—to require a user secondary authentication authorization. Token, password, bio-something, key device, I don't care which of these you use, but you must use something. Sessions must time out and demand a new token after 15 minutes of inactivity—and no persistent session without a secondary auth.
Hey, banks—aren't our assets worth something? Yo, Amazon, how about it? Fleabay? C'mon folks, let your users become comfortable with secondary auth so that your fraud costs go down, and your customer love goes UP! A colleague of mine cites an app that will beat a password with three hundred million dictionary attacks per second. While I'm impressed with his hardware, don't doubt that even low-profile targets snap like a twig when attacked in this way. Let's salt it up and make it more difficult.
People could use all of the good stuff in the cloud, if the cloud wasn't a cesspool of hideous, unevenly applied security and rascal hosting sites worthy of being kicked to the curb. I want to trust the cloud. Google, for all of its strangeness, happily offers up and demands a secondary auth, usually a Yubikey, for its employees and contractors. Let's make them demand that of search, too.