Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:40 PM
Connect Directly

Selling A Secure Internet Domain

PayPal among organizations invited to help shape security protocol for .secure that also can be used in existing domains

PayPal is among the as-yet unnamed organizations invited to join a new working group that ultimately will build the framework for the proposed .secure top-level Internet domain that also can be used in any existing domain as well.

The new .secure TLD, which was announced earlier this month, will include fully encrypted HTTPS sessions and a comprehensive vetting process for websites and their operators. It has been billed as a "safe neighborhood" on the Internet, and is one of the first next-generation TLDs to emerge from the new Internet Corporation for Assigned Names and Numbers (ICANN) program that opens up the TLDs beyond the 21 existing global domains that include .com, .org, .net, and .edu. Artemis Internet Inc., a wholly owned subsidiary of NCC Group plc, has applied with ICANN for the new .secure domain in the competition for thousands of new TLDs aimed at better classifying companies and people by industry, interest, or location.

If the new domain takes off, it could alter the way Web domains are secured, as well as what users see when they enter a secured site. Security experts say the initiative has some big hurdles to clear first, however, and much of it involves logistics and not necessarily technology.

It's unclear whether PayPal will definitely participate in the Domain Policy Working Group, which was formed this month to build a framework for the security standards that will be required of the new secure TLD, and submit the specifications to the Internet Engineering Task Force (IETF).

But a blog post last week by a PayPal risk management professional appeared supportive of the initiative. Brad Hill, a member of PayPal's risk management group, said in the Information Risk Management blog that his company had been invited by .secure TLD creator Artemis to participate in the Domain Policy Working Group.

"We have identified the need for and advocated uniform security policy frameworks to address Web security," Hill blogged. "As such, we support the opportunities presented by the Domain Policy Framework (DPF) for broader adoption of these and other security technologies."

But Hill told Dark Reading that he is unable to discuss the .secure and Domain Policy Working Group efforts, and noted that The Security Practice blog is not an official PayPal communications channel.

"We are encouraged by the effort to create user-recognizable spaces on the Internet where uniform and modern best practices for security and safety will be enforced. We also look forward to a time when domain registrants will be held to high standards for truthful and accurate self-identification, trustworthy operation, and protection of users," Hill said in his post. "As the viability and benefits of such an approach are demonstrated in parts of the new gTLD space, we hope this work will help accelerate efforts to enable a safer Internet everywhere, for all users."

Overall, security experts have welcomed the .secure concept in the spirit of improving Internet security rather than solely finding ways to break it. "I applaud anything anyone can do that's something constructive," says Richard Bejtlich, CSO at Mandiant.

The good news is that the new domain doesn't require tearing apart existing infrastructure. "We can't make the Web any more secure unless we break convention and backward-compatibility, and no one is willing to do that. The benefit of .secure is that you don't have to start over ... they're not boiling the ocean," says Jeremiah Grossman, CTO and founder of WhiteHat Security. The TLD can make a difference by mandating that certain security measures be on by default in browsers and websites -- such as SSL or secure flags -- in order to operate, he says.

The .secure domain will verify domain applicants' identities and require mandatory DNSSEC-signing of every zone, use of TLS (SSL) for all Web sessions, and DKIM and TLS for SMTP email. It also will support only a preapproved list of legitimate and secure certificate authorities.

[ The recent rash of breaches among certificate authorities has left a bad taste in enterprises' mouths. For a look at what's wrong and what's next, see What's Next For Certificate Technology?. ]

But Grossman says .secure will also pose something of a marketing exercise on how to provide end users the best visual cues and information to ensure they can and will use the secure domain.

Mandiant's Bejtlich says this may be too technical a concept for the man on the street. "I feel this is so much inside baseball that it's not going to resonate for the person on the street ... The trust people have is in the companies who operate the website, not in any part of the infrastructure or domain," he says.

Alex Stamos, CTO at Artemis, says the goal is for the secure domain to do everything for the user to be secure in his or her transaction, enforcing security settings on the server side as well as on the browser side, for instance. "Once you type '.secure,' all of that will be taken care of for you," he says.

And part of that equation is enforcing the security protocols and clean websites of the domain owners. Stamos says the Domain Policy Working Group's protocol will be the standard by which .secure domain owners must adhere. "We will have an engineer randomly scanning subdomains ... we will very vigilantly police this neighborhood for bad actors" as well, he says.

Stamos yesterday posted an FAQ to address some of the questions and concerns about how the new domain would operate. "Security is a process, not a destination, and we will need to be clear that we are looking to improve the horrible level of trust on the Internet but are not so arrogant as to think that we can solve all problems for all users all at once," Stamos wrote in the FAQ.

"No one can promise perfection. What we are promising is that Artemis and the .Secure domain holders are engaged in a continuous process of testing, improvement and if necessary, vigorous response. This is certainly more than you will get from .com or any other announced gTLD," he wrote.

Meanwhile, Grossman says enforcement won't be easy because there's the potential for a conflict of interest for the domain provider. "That's something they are going to have to address. Alex is well-aware of this," he says. Suspending or penalizing a subdomain for security violations ultimately could cost the .secure domain provider money, he says. "That's a tough decision they will have to make every day," Grossman says.

Whether organizations will be willing to pay for a domain that mandates these security requirements in order to operate it is the big question. Mandiant's Bejtlich says he doesn't think organizations will be willing to pay for that while the domain operator tells it how to "run its business."

"My guess is the best you could hope for is to pursue standards for better implementation of [security] technologies and also some type of code of conduct," he says. "But you retain control of how you operate on the Net."

Overall, though, he says he favors Artemis' goal. "I love the fact that they are trying to do something constructive," Bejtlich says. "It's all about trust and business that causes the most conflict."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-11
FusionSphere OpenStack 8.0.0 have a protection mechanism failure vulnerability. The product incorrectly uses a protection mechanism. An attacker has to find a way to exploit the vulnerability to conduct directed attacks against the affected product.
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Credential Manager component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Assets component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Analytics component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Permissions component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.