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. …
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.
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.
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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
