In March, the Internet Engineering Task Force approved the Transport Layer Security version 1.3, the key function to enable HTTPS function on the web. On the surface, the new encryption model shores up network communications and provides substantially improved security features.

As the new encryption model used to browse the internet, the TLS 1.3 standard ensures data is encrypted through cryptographic protocols, using algorithms and ciphers. The previous model, TLS 1.2, had many flaws, which, left unfixed, could have impacted users around the globe. Hackers could have been able to crack the flaws in the TLS 1.2 encryption to complete a downgrade attack.

So IETF spent four years on 28 drafts with comment periods and arduous hours crafting the new web standard. Hailed by many in the security industry for advancing security and performance functions, TLS 1.3 removes some of the legacy functions of past encryption models and phases out obsolete protocols.

TLS 1.3 also improves the "handshake" between SSL/TLS, to secure the connection between the client and the server. The process includes communication between the two parties to validate security certificates and negotiate data transfer terms.

The standard drastically reduces the handshake timeframe with just one round to complete. Not only that, it remembers clients and servers that have met before, which means it won't take additional rounds to complete.

The IETF Internet Engineering Steering Group passed the standard with overwhelming support, with eight of the 13 members in support and the other five said 'no objection.'

Challenges for HIPAA and patient privacy

So with all of these improved security features, why are some experts concerned about this change? To Josh Magri, vice president of Counsel for Regulation and Developing Technologies at the Financial Services Roundtable, some of the concern stems from the encryption standard's premise that communication between endpoints are always between two individuals.

In practice, communications, specifically TLS sessions, are often between a person and the enterprise as the endpoint, with the enterprise then distributing the communications throughout their network.

But now the enterprise as gatekeeper has been removed and enterprise won’t be able to see the communications occurring between the individual sender and the individual receiver,” said Magri. "The enterprise as an endpoint is no longer.”

"The thought among some of the privacy fundamentalists or activists is that when a communication is sent it should only readable by the individual sender and individual receiver," he added. "But I'm thinking about how an enterprise works: : The enterprise needs to know what is going on within its walls to protect itself, its employees, and the people it services – it should be the endpoint and have control, following proper regulations and informed consent requirements."

Under the new standard, the data is encrypted on each singular device, for each individual. The problem, as Magri explained, is that these organizations are responsible for the devices on their networks, and they need to be able to see whether an insider is taking data out or doing malicious activities.

"When you've encrypted [under TLS 1.3] inside the enterprise won’t necessarily be able to see what's going on between a receiver on its network and a sender and vice versa," he said.

This could be problematic for healthcare when it comes to HIPAA and patient privacy. While HIPAA doesn’t require vulnerability scans or penetration tests, it mandates organizations conduct a risk analysis – or a test of security controls. Two important ways to accomplish this are with those tools.

NIST actually issued a special HIPAA recommendation that organizations should "conduct trusted penetration testing of the effectiveness of security controls in place, if reasonable and appropriate. This validates your exposure to actual vulnerabilities."

But here’s the catch: Without the ability to view traffic across the whole network, infosec leaders will either need to invest in workarounds, time and or tools to be able to effectively monitor these threats. And in terms of patient safety and HIPAA – that becomes a serious challenge.

You want to have idea of what is going from point A to point B on your network, and spot whether there are any bad actors or other malicious behavior even if it isn’t internet bound," said Magri. While there are some workarounds to handle this issue, "it can still cause a lot of problems."

Let's get technical

It's not that the group wants the new encryption protocol removed. Rather, the group spent two years trying to sway the IETF to keep the critical risk and operational management capabilities in place for TLS, explained Andrew Kennedy, director of BITS, FSR's technology policy division.

"The capability to inspect encrypted custodial data has been available for nearly a quarter of a century and serves to protect customers and enterprises against data breach from phishing attacks, advanced persistent threats, and insider threat, and to expedite the diagnosis and resolution of critical network anomalies," Kennedy wrote in reaction to the IETF approval.

To Kennedy, the real issue is out-of-band inspection: the "non-invasive way of essentially taking the encrypted data and shifting it elsewhere."

"The encrypted data goes to its intended destination, but it is also copied to the side," said Kennedy. However, since the enterprise has the private key, "Using RSA key exchange, enterprises can inspect [the copy of] the data."

"There are lots of good reasons to do that: malware, insider threats, DDoS concerns, fraud, insider abuse," he added.

But TLS 1.3 took away this capability, Kennedy explained. And although there are other ways to inspect the data, out-of-band is crucial as it's doesn't interrupt data flow or add operational risk. In-line acts like a proxy and gets in front of the client on the server to decrypt.

"[In-line] is still possible with TLS 1.3, but it adds operational risk, latency and doesn't scale as well," said Kennedy. "We had this universal tool for inspecting data – and now we're left with [in-line] that does not cover all threat models."

Kennedy laid out a use case that explained how a hacker could easily go into a network to steal healthcare or banking data, or flip a switch and turn off the electrical grid – or even worse, undermine the integrity of data.

"When you have complex networks, mergers and acquisitions, business partnerships – you need the flexibility to have this inspection capability when you need it," said Kennedy. "It's a universal tool – not just for fraud and security – it's also used for diagnostic and customer experience."

Take, for example, if a service goes down because a hacker gets in: It costs money and time, he explained. "You need this universal tool because if you can't inspect the data or firewall – in some cases, it's hundreds of hours of downtime.

"There are so many places on the network that it could be a problem in finding that one threat," Kennedy added. "You could be down for hours and finding that problem could be weeks."

Uphill battle

About two years ago, FSR discovered that the proposed TLS 1.3 protocol changed the key RSA algorithm, which caused these issues with viewing data for the financial and healthcare sectors.

Kennedy said it was "a culture shock (for IETF) to learn how everything works."

The group went to work on developing standard-based ways of solving these issues – but both were rejected.

"The funny thing is that there are solutions out there that technically meet the TLS 1.3 standards, but are probably not what the privacy advocates could want," said Kennedy. "But that's not the way the IETF thinks of things: They think about internet and individual."

FSR is no longer pursuing a fix through IETF. The two solutions developed by the group solve the problem in-line, and some may choose to take that path. Organizations can also tune the key and change it for each session, the way previous versions work.

But Magri and Kennedy said they're talking to other sectors and standards groups to determine another way forward. They also mentioned there are vendor options that can help – but it doesn't immediately solve the issue.

"The unfortunate part is the IETF is the premier standards body for the internet, it makes it harder to get by and get that developed," said Kennedy. "This is going to be solved regardless of them weighing in, but they should have."

"TLS 1.3 it has been implemented, so it's going to be hard to unwind that," said Magri. "It will be a matter of trying to look for solutions going forward that will work for the companies and work for the privacy folks. It's just not going to be as thought through as what we would have hoped it would be."

Twitter: @JessieFDavis
Email the writer: jessica.davis@himssmedia.com