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

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

[brooxta]

Steps in the right direction

Great to see PFS becoming standard, and RSA based key exchange deprecated. These steps incrementally improve TLS security.

That still leaves the gaping hole which is the ridiculous amount of trust placed in root certificate authorities, and what happens when they are compromised (eg. Comodo), but the direction this decision sets seems good.

[The Man Who Fell To Earth]

Re: Steps in the right direction

Eh? The article did not say that PFS was becoming the standard. It simply said that Diffie-Hellman key exchange (DHE) and ‪Elliptic Curve Diffie-Hellman‬ key exchange (ECDHE) will be the two supported because they *support* Perfect Forward Secrecy (PFS). But DHE & ECDHE are not synonymous with PFS. DHE & ECDHE are simply schemes by which two entities with no prior knowledge of each other can generate a shared mutual key over an insecure channel. You can use DHE & ECDHE without PFS. So the real question is whether TLS 1.3 will *require* PFS, or at least have it turned on by default.

[NoneSuch]

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

A small price to pay indeed.

[Bronek Kozicki]

This is very good news. Not major event, just good.

Now the question : how long before the spec is finished and then implemented on majority of popular platforms? This will likely take some time ...

[Anonymous Coward]

I agree, an incremental improvement...

But very welcome. How much updating of existing firmware will be required?

[poohbear]

Aren't they worried about how this is going to make life safer for [drug dealers | Cyber criminals | pedophiles | varmint-of-the-month] ?....

[Adam Inistrator]

Privacy for the masses including thinkers and whistleblowers is mor important than catching bad guys I think. Police think everything is a nail.

[AlanS]

The only surprise is ,,,

why this isn't done already. When I first learnt about DH negotiation, years ago (some TV programme on how GCHQ had invented RSA before RSA), I assumed all connections used DH for the initial (quick) link and then negotiated something better.

[Michael Wojcik]

Re: The only surprise is ,,,

I assumed all connections used DH for the initial (quick) link and then negotiated something better.

All the SSL/TLS suites that support key exchange do precisely that - they use asymmetric cryptography to exchange a session key, then use that symmetric cryptography with that session key. That has nothing to do with Perfect Forward Secrecy.

[Anonymous Coward]

PFS

Now this is from memory without citation.

I seem to recall that MS's IPSEC implementation is pretty much the only one I've come across that enables PFS by default in Phase 2. Certainly TMG and ISA (both shite products as far as I'm concerned - you try fixing them when ADAM goes titsup) both had this.

Did someone working within the beast of Redmond do this to ensure a little extra security or to help make their products a little harder to connect to by others? Conspiracy? You decide.

[asdf]

>"Of course this forward secrecy won't mitigate against [SSL] implementation bugs, such as Heartbleed

Go Theo! Save us from the devs and their broken culture over at the openssl project. Libre in the name is a good thing.

[codebeard]

Misleading URL

The URL of this article says 'rsa depreciated [sic] from tls'. RSA will remain an important part of TLS, but key exchange will use additional methods and not just plain RSA key exchange. RSA keys are not going anywhere.

[Anonymous Coward]

Or impliment PFS now

An article in the last few days from Howtoforge explains setting up PFS now on nginx - http://www.howtoforge.com/ssl-perfect-forward-secrecy-in-nginx-webserver

I've not been through it in detail, but it seems at a glance to do what the new spec suggests.

[Michael Wojcik]

Clarifications

The TLS ECDHE cipher suites are not simply "‪Elliptic Curve Diffie-Hellman‬ key exchange"; that would also include the ECDH cipher suites. The ECDHE ones use ephemeral ECDH keys rather than fixed ones (which is what the ECDH suites use). See RFC 4492, among other references. The ECDH suites do not provide PFS.

As codebeard noted above, DHE and ECDHE can be used with RSA keys. The alternatives are DSA and ECDSA keys; if you include ADH and AECDH key exchange, you can also use no asymmetric key pair for authentication, though in that case you have no way in the protocol of verifying the peer's identity.

Key exchange and peer authentication are two different aspects of SSL/TLS, and RSA remains the most popular alternative for the latter. RSA keys aren't going anywhere.

[Mummy's 'ickle soldier]

Re: Clarifications

Completely agree. This doesn't guarantee that you are actually speaking to the server and not subject of a MITM attack. Until authentication and DNS Security improves, improved encryption will only protect against sniffing attacks. Good to see the IETF improving things though.