
My own private Internet: .secure TLD floated as bad-guy-free zone - iProject
http://arstechnica.com/security/2012/05/my-own-private-internet-secure-tld-floated-as-bad-guy-free-zone/
======
duskwuff
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?

~~~
joshAg

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

~~~
joshAg
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.

~~~
Karunamon
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.

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

------
crazygringo
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...

------
joejohnson
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.

~~~
secalex
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.

~~~
nextstep
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.

~~~
secalex
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.

------
kijin
> _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.

------
zhoutong
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.

~~~
batiudrami
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.

------
blhack
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.

~~~
SquareWheel

      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.

~~~
coopdog
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

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

~~~
GoodIntentions
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.

~~~
jerf
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.

------
drucken
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...

------
_IKE
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.

------
12uu45dd
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.

------
aurelianito
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.

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

~~~
lis
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.

------
rrival
What could possibly go wrong?

------
DavidAbrams
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.

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

------
Devilboy
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.

