My own private Internet: .secure TLD floated as bad-guy-free zone | Hacker News Reader

My own private Internet: .secure TLD floated as bad-guy-free zone

arstechnica.com

50 pointsiProject39 comments

So, let's see. For an inflated price, you get a domain name which has a vastly more complex application process, which places arbitrary restrictions on what services and configurations you can run under it, which mandates periodic security scans (probably at your own cost), and which retains the right to seize your domain, possibly permanently, if you don't comply. Oh, and you end up with what is ultimately a less memorable and more difficult to type domain name.

With features like this, how could you say no?

  No.
  Nope.  
  No thanks.  
  Not at this time.  
  No way, Jose.  
  Never.

There must be fifty ways to leave your... ISP?

Since it's too late to edit or delete the parent to this comment, I sincerely apologize for attempting to make a joke on hacker news.

HN is fairly intolerant of any kind of humor, I've found (unless it's the snarky kind). I've been downvoted more than once for trying to crack a joke, in fact I don't even forsee this post faring well, even though it's an attempt to inform someone else of a valid point.

The HNers for Humor Coalition wishes you well. From both of us.

Of course, making a comment like that seems to correlate with the downvotes not happening. Perhaps meta-complaining is like the Windows Rule.. every other level of complaint is spared the downvotes.

the joke is tolerable if it adds something to the discussion or helps me learn something i didn't already know.

for me, HN is the reference section of the library. it is not that it can't have humor, it should be useful for more than just a laugh.

Also, it's like painting a huge target on your back for hackers to attack. Maybe that's the deal, all script kiddies will hack the .secure tld and will leave the rest of the internet alone.

Why do people write iOS apps?

> So, let's see. For an inflated price, you publish your app on the App Store which has a vastly more complex application process, which places arbitrary restrictions on what services and configurations you can run under it and which retains the right to suspend your app, possibly permanently, if you don't comply. Oh, and you end up with what is ultimately an app that is only accessible within Apple's walled garden.

I'm not saying this venture will necessarily succeed, but I wouldn't dismiss it so easily.

Late reply:

The difference is that having an application available through the App Store is pretty valuable on its own. It gets you access to Apple's QA, processing, and fulfillment services, as well as a seriously HUGE customer base.

By contrast, a .secure domain doesn't appear to give you much besides the name. All of the actual security is still your responsibility.

From a marketing perspective, this actually seems pretty clever. I could see a lot of people wanting to use "citibank.secure" or "amazon.secure" or "gmail.secure", just from the way it sounds. It's the first TLD I've ever come across that feels it could actually compete with .com.

Of course, the first time one of the sites gets hacked, who knows what will happen to the TLD's reputation...

This sounds great, but it's not really a solution to the hard problems with crypto. The single biggest impetus to a fully encrypted internet is not a technical barrier, but the fact their are too many competing systems and standards, all with different drawbacks, but generally all of which give terrible UX. For an encrypted web to become ubiquitous, there will need to be a set-it-and-forget-it solution that requires minimal input from the user and which doesn't reduce functionality.

Using .secure just asks users to instead place their trust in a new central authority; why does this even need to be a new TLD? This researcher is wasting money buying into ICANN's bullshit monopoly. The future of strong crypto systems will most certainly be decentralized.

Howdy, that article is about me, and I do agree that crypto trust systems need to become more decentralized. People seem to be reacting to the story without looking into the technical details, so I'll try to avoid http://xkcd.com/386/, but I will say that one of our goals with Domain Policy Framework (which we will release a draft of tomorrow) is to create the policy and identity that, combined with DNSSEC and DANE, allow for more granular (but not completely decentralized) trust relationships.

I think we agree about UX. One of the big picture goals of .secure is to invert the current security experience. These days you go to a site and then have to interpret the UI to see if you are safe. In our vision, when you type bank.secure you are telling your browser, OS and the server on the other side that you want to navigate there as safely as possible.

I'm going to post about the tech details more tomorrow and hopefully that clears some things up.

I guess we'll have to wait until you post the technical details, but from the Ars article, it sounds like this page is using existing standards (TLS, maybe some other stuff). That's fine, but what's the incentive for a bank or any secure online service to use this instead of the expected <bank>.com domain name?

When I browse to a secure page (https) in my browser, I'm told that the connection is secure with a green https prefix in the address bar. But I don't really know it's secure. I'm placing my trust in the CAs. Using .secure to signal a secure connection to user doesn't improve this. It just complicates things further, because now there's two things a savvy user should look for if he/she expects a secure connection (https and .secure).

Because you seem like a fan of XKCD: http://xkcd.com/927/ Creating a new UI standard works best when it kills (totally replaces) it's predecessor. In this case, I think that translates to having every site which currently uses https make the switch to .secure. That seems unlikely to me.

The UX should be the equivalent of the current EV UX, but the point is that if your browser supports DPF then you don't need to look. If you got there after typing bank.secure, you should be good. If the screen is red (and hopefully doesn't have an "accept this risk" button) then you didn't.

I should point out this is about more than TLS, and more than the web. We have a short window during which we can create an Internet category that is both clear to the user in it's goals and specific in its requirements for hosts. Our hope is to create an extensible protocol with DPF, one that can be extended to give domain registries and registrants the ability to choose higher privacy protections, limit risk to CA compromise, and secure other protocols like SMTP.

> sites could specify which authorities are or are not allowed to sign their SSL and TLS certificates

This idea actually sounds fantastic. If I only ever buy my certificates from one or two CAs and if I can disallow certificates signed by other CAs, I won't have to worry about some random CA getting hacked and millions of fake certs being trusted by browsers.

Implementing this scheme, on the other hand, will be tricky. If I use a DNS record to specify my trusted CAs, sort of like how we do SPF nowadays, anyone who can hijack DNS queries will also be able to forge that record. Proper DNS security must be provided before this measure can be made effective.

The beauty of the Internet is low barrier of entry for startups with potential. If .secure becomes popular among big guys, startups with similar features will be disadvantaged.

The complicated paperwork will not only drive phishers and scammers away. It also excludes people with little capital but a genuine intent to do business. We already have these barriers:

- Extended Validation SSL

- Merchant Account (including PCI compliance)

- All kinds of trust seals

The cost of these products can be several thousands of dollars every year and they have become pretty much a must-have for anyone who wants to be trusted more easily.

.secure will just impose another barrier, unfortunately.

EV SSL can be had for around $300 a year, there's an entire freaking industry that exists around card processing so you don't have to fuss around with PCI nonsense, and I've actually never seen a "trust seal" on a site that wasn't already shady at some point.

That said, .secure seems like a poor solution in search of a problem.

If you're looking for secure payments, you can always direct customers to a .secure payments handler, in much the same way that Paypal does already. The whole domain wouldn't have to operate under a .secure domain, in fact that would be undesirable as it would diminish the importance of it customer's eyes if every major website is on a .secure domain.

This type of scheme comes up what, every year? Except this time somebody sunk $9 Million into it?

Guys. Listen. .com is, has been, and always will be the standard. It's the brand name. It's the default.

There is never not going to be a chase.com. It will either be run by JP Morgan Chase, or it will be run by a scammer, either way the overwhelming majority of internet users will think "chase" and associate "chase.com" with it.

Imagine a non-technical family member getting a phishing email with chase.com in it. Do you honestly think that they're going to think to themselves "bah! the .com tld isn't secure! I should be looking for a .secure website!"

What is even the point of this? Regardless of if people jump on to .secure, the entire .com internet still exists.

  Do you honestly think that they're going to think to themselves "bah! the .com tld isn't secure! I should be looking for a .secure website!"

I don't agree. I've seen people decline to do online business because the payment page wasn't https. This was not that tech savy of a person, and it actually impressed me. People adapt quicker than we realize.

I agree, putting https on an ecommerce site actually does increase conversion. Even a silly ' this site is secure' increases conversion, so people do notice and care

The problem is the classic tld one. With https you know it's the same domain, but who's to say chase.secure is run by the same people as chase.com? Both could own a trademark relating to the word chase, both have verified (and different) addresses, but they're not necessarily the same

I know it ruins the tld extortion model, but I think for this to fly the .secure address should be linked to .com, so only the owner of the .com is eligible to buy the .secure and has been vetted as owning it

Otherwise I'm pretty certain the consumer uncertainty of the tld issue will destroy all trust in the .secure brand. No one argues that https is less secure, but when people have their geek friends put caveats on the .secure domain that they don't quite understand, I think that consumers will eventually avoid it

"There is never not going to be a chase.com."

No, but it might exist only to 301 to chase.secure. Still preferable to type it directly but potentially better than nothing.

If this scheme is going to founder it's because nobody pays attention to the URL despite the best efforts of browsers, not because any of the rest of the scheme is bad.

That's a very US centric view.

This is why we are proposing an extension to HSTS that would make the redirect from one TLD to another permanent, which could help all of the new gTLDs.

This + RFC 3514 (https://www.ietf.org/rfc/rfc3514.txt) will make internet secure!

That RFC was the first thing that came to mind for me...

some folks will read ".secure" as ".pwn-this-i-dare-you" and it will happen eventually unless you air-gap any ".secure" machine from the "real" web. This idea is about as effective as the evil bit RFC imho, just less funny.

You say this like it's a bug, but it's a feature. Your servers don't get hardened by being ignored, they get hardened by being under continuous assault. The ignored servers are the ones the hackers waltz into with an exploit patched by the vendor six years ago.

A gated, centralised and unscalable Internet community whose lofty goals are directly undermined by cost and the core principles of security: weakest link.

Also, I cannot see how they could achieve critical mass without government intervention. I expect if they really do mean business to see some intense political lobbying or sidedoor via some government regulator or commission. It could even be that the intelligence services will love and push for this proposal for the centralisation of so many channels may make their work significantly easier.

No non-trivial corporate will go to the lengths requested without being required to or strong tangible benefits over what they already do and can cost-effectively procure in future. After all, there is nothing in the proposal that corporates cannot already do themselves.

In short, this seems to be at best a security industry playground and the founding companies business model as a play on security concerns subsidised by others, or at worst, security theater.

It would be very interesting to know Bruce Schneier's take on this...

Sounds like they would be trying to operate as a sort of Centralised Certficate Authority.

Didn't Verisign try something similar, only to get out of that business as soon as it became obvious the whole system is easily exploited and inherently insecure?

It will be interesting how this company tries to explain how this is different.

It's a way for a security firm that does audits, escrow and such for customers -- who all have websites -- to sell more services.

"We sell domain names too!"

Just one more thing they can add to their list of "services".

Does it increase security?

Just throw in some buzzwords that clients identify with security. Sold.

No one ever audits the auditor.

Maybe it increases security in the mind of the client or the end-user.

And that's enough to sell the services.

This thing reminds me of the Oracle Unbreakable PR stunt: http://www.securityfocus.com/news/309

Sometimes, it even makes me wonder if they choose these kinds of names to get penetration testing services for free.

Because all users will know the difference between realbank.secure/index and fakebank.com/index.secure ...

This. When it comes to fishing, there is one rule: don't change your TLD. When I log in to PayPal I am always getting redirected from paypal.com to paypal-deutschland.de (the german tld), how is someone who is not internet savvy supposed to know whether he is getting phished or not, when even the companies use different TLDs?

Be consistent - using citibank.com and citibank.secure does not help at all, it will only confuse customers even more.

What could possibly go wrong?

Ugh. Just get rid of restricted TLDs entirely. Oh wait, ICANN finally decided to do that, but then made it into a giant sham and rip-off.

Inept clowns and scammers.

Why would it be a good idea if it was free?

If they do a good job and gain enough respect and trust this could be big. I'm not sure it will actually go anywhere but maybe.

Reply on news.ycombinator.com