Feeds

Net tech bods at IETF mull anti-NSA crypto-key swaps in future SSL

'Perfect example of how Snowden has improved our privacy' says professor

Internet Security Threat Report 2014

Standards stewards on the Internet Engineering Task Force (IETF) are planning to drop RSA key exchanges from TLS 1.3, the next revision of SSL.

The technical body is instead eying up algorithms that use short-lived encryption keys, aka ephemeral keys, that can sidestep surveillance dragnets by the likes of the NSA.

Specifically, the IETF has backed Diffie-Hellman key exchange (DHE) and ‪Elliptic Curve Diffie-Hellman‬ key exchange (ECDHE) over RSA because the former two support Perfect Forward Secrecy (PFS).

When a server and a client use SSL/TLS, they must agree upon a unique encryption key valid for just that connection session – and use it to protect their communications from eavesdroppers and tamperers.

How that session key is transported between the client and server is crucial here: in RSA key exchange, the client generates the temporary key, encrypts it using the server's public RSA key, and sends it over the network. The server uses its corresponding RSA private key to decrypt the session key – now both sides have what they need.

But if that private key falls into the wrong hands, the session key can be intercepted and deciphered, allowing a snooper to unlock past and future conversations between the server and its clients.

However, PFS ensures that the ephemeral session key is never exchanged in whole over the network between the two partners.

Thus even if, say, an NSA g-man silently intercepts the pair's network traffic and then gains access to the web server's private key used to initiate the connection, the spy cannot recover the session key and decrypt the snooped data.

And even if the eavesdropper somehow obtained the temporary key, it's only good for that session and that session only.

The practical upshot is that the use of PFS makes life harder for cyber-spies, whether they're from the NSA, GCHQ, Russia, China or Iran, and so on. It also makes life much more difficult for snooping crooks.

The move by the IETF to drop RSA key transport from future SSL versions emerged in a brief post to the TLS mailing list by Joseph Salowey, an engineer at Cisco and chairman of the IETF TLS working group:

The discussion on this list and others supports the consensus in IETF 89 to remove RSA key transport cipher suites from TLS 1.3. The editor is requested to make the appropriate changes to the draft on ‪GitHub‬.

More discussion is needed on [how] both DH and ECDH are used going forward and on if standard DHE parameters will be specified.

Salowey goes on to expand the reasons why the RSA key swap is no longer up to the job of underpinning secure data exchange in the post-Ed-Snowden era:

TLS has had cipher suites based on RSA key transport (aka "static RSA", TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have several drawbacks including lack of PFS, pre-master secret contributed only by the client, and the general weakening of RSA over time. It would make the security analysis simpler to remove this option from TLS 1.3. RSA certificates would still be allowed, but the key establishment would be via DHE or ECDHE. The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3.

The RSA cryptosystem can be used for much more than just key transport, as explained by Thomas Pornin on the Information Security Stack Exchange, here.

Cryptographers have welcomed the decision to deprecate RSA key exchange from TLS 1.3.

"In case you're missing context: the removal of RSA in the next version of TLS is a perfect example of how Snowden has improved our privacy," said Matthew Green, a professor of computer science who teaches cryptography at Maryland's Johns Hopkins University.

Reg reader Arnold Yau, who drew our attention to the IETF's work, commented: "The only downside is many textbooks will need to be updated as they tend to use RSA key transport in TLS examples."

"Of course this forward secrecy won't mitigate against [SSL] implementation bugs, such as Heartbleed or [Apple's] goto fail etc," Yau added. ®

Remote control for virtualized desktops

More from The Register

next story
UK smart meters arrive in 2020. Hackers have ALREADY found a flaw
Energy summit bods warned of free energy bonanza
DRUPAL-OPCALYPSE! Devs say best assume your CMS is owned
SQLi hole was hit hard, fast, and before most admins knew it needed patching
Feds seek potential 'second Snowden' gov doc leaker – report
Hang on, Ed wasn't here when we compiled THIS document
Mozilla releases geolocating WiFi sniffer for Android
As if the civilians who never change access point passwords will ever opt out of this one
Why weasel words might not work for Whisper
CEO suspends editor but privacy questions remain
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
prev story

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.
Protecting against web application threats using SSL
SSL encryption can protect server‐to‐server communications, client devices, cloud resources, and other endpoints in order to help prevent the risk of data loss and losing customer trust.