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

5 things you didn’t know about cloud backup

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

Secure remote control for conventional and virtual desktops

More from The Register

next story
Ice cream headache as black hat hacks sack Dairy Queen
I scream, you scream, we all scream 'DATA BREACH'!
Goog says patch⁵⁰ your Chrome
64-bit browser loads cat vids FIFTEEN PERCENT faster!
NIST to sysadmins: clean up your SSH mess
Too many keys, too badly managed
Scratched PC-dispatch patch patched, hatched in batch rematch
Windows security update fixed after triggering blue screens (and screams) of death
Researchers camouflage haxxor traps with fake application traffic
Honeypots sweetened to resemble actual workloads, complete with 'secure' logins
Attack flogged through shiny-clicky social media buttons
66,000 users popped by malicious Flash fudging add-on
New Snowden leak: How NSA shared 850-billion-plus metadata records
'Federated search' spaffed info all over Five Eyes chums
Three quarters of South Korea popped in online gaming raids
Records used to plunder game items, sold off to low lifes
Oz fed police in PDF redaction SNAFU
Give us your metadata, we'll publish your data
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Advanced data protection for your virtualized environments
Find a natural fit for optimizing protection for the often resource-constrained data protection process found in virtual environments.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.