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

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
'Regin': The 'New Stuxnet' spook-grade SOFTWARE WEAPON described
'A degree of technical competence rarely seen'
You really need to do some tech support for Aunty Agnes
Free anti-virus software, expires, stops updating and p0wns the world
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
Regin: The super-spyware the security industry has been silent about
NSA fingered as likely source of complex malware family
Privacy bods offer GOV SPY VICTIMS a FREE SPYWARE SNIFFER
Looks for gov malware that evades most antivirus
Patch NOW! Microsoft slings emergency bug fix at Windows admins
Vulnerability promotes lusers to domain overlords ... oops
HACKERS can DELETE SURVEILLANCE DVRS remotely – report
Hikvision devices wide open to hacking, claim securobods
prev story

Whitepapers

Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
10 threats to successful enterprise endpoint backup
10 threats to a successful backup including issues with BYOD, slow backups and ineffective security.
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.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.