Slashdot Mirror
TLS 1.3 Draft Prepares to Drop Static RSA Key Exchange
msm1267 (2804139) writes with a bit of news from last week that seems to have slipped under the radar. The IETF TLS working group has reached consensus on dropping static RSA cipher suites from TLS 1.3, instead requiring the use of Diffie-Hellman Exchange (or the faster ellipitic curve variant). Static DH and not just ephemeral DH key exchange will be supported, so not all connections will have forward secrecy. The consensus is subject to change before the final TLS 1.3 specification is released, and there are still details to be worked out. The changes to the draft are pending as a git pull request.
I've wondered why there isn't a protocol similar to what was used in SSH 1.x, where every x amount of time (default was ten minutes), there was a set of RSA keys generated and kept in memory, used for transactions (and signed with the permanent set of keys), then tossed.
In theory, PFS should be the core of TLS... negotiate the protocol, use DH or the elliptic curve variant to hammer out a session key, re-negotiate the session key every so often, and in any case, toss the session key for good. Having a temporary set of RSA keys similar to SSH 1.x provides protection because it make the permanent host keys essentially signing keys only, not used for encryption, so less data would be encrypted by those keys.
For the crypto-noob, where is PFS in relation to this update?
Can someone give me an EL5 of this story?
In other news, OpenSSL gets a 4-year-old flaw patched. The catch here is that the bug was not only 4 years in the codebase, but it was publicly reported (CVE-2010-5298) for 4 years, without no one taking the responsibility to fix it.
OpenBSD developer Ted Unangst made a detailed report of the bug. It's not as severe as Heartbleed, but still allows remote attackers to inject data across sessions or cause a denial of service (use-after-free and parsing error) via an SSL connection in a multithreaded environment.
There are some things you want to share, and there are some things you don't want to share, which are called "private". And there are people in other countries who want to hurt you, who are called "terrorists". There's a part of the government called the NSA that looks at other people's private things in order to stop terrorists from hurting you. But some people don't like strange people looking at their private things.
Sometimes you want to share your private things with other people you trust. One of the ways to make sure nobody else can see your private things is to use encryption. Encryption does complicated math problems on your private things. If something is encrypted, only the person you're sharing it with can see it because other people watching your Internet connection won't be able to solve the math problems. This involves another math problem called a "key exchange". A piece of software on your computer called a "crypto library" does encryption and key exchanges.
What happened here is that some people think RSA, a company that makes key exchanges, was working with the NSA to help it look at your private things. And someone found a different solution to RSA's key exchange. That's why people who make a popular crypto library want to stop using RSA's key exchange.
The people that work on the kernel are not necessarily the people you want working on encryption.
To understand the encryption requires a LOT of mathematical analysis.... and there aren't enough of them to go around. The best paid ones work for the NSA.
In addition, the kernel programmers are VOLUNTEERS.
Exchange in a secure manner (in person) a private one time use page with truly random data. 2 TB hard drive with captured static noise. XOR your data with this random data at each end. Then the NSA has to come to your place with black masks and thumb screws to decrypt your communications.
But in the end who cares. Let the royals watch their peasants.
Static DH is not better than Static RSA
PFS is nice and all. But why the hate for RSA? It's a well understood algorithm.
What the TLS designers need to think about is how to reduce the options to one well understood choice. So the complexity of ciphersuite negoitation, rekeying and all the other absurd complexity can be removed.
TLS will not be fixed. It will be replaced.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I think it is a mistake for IETF to make value judgments about mandating a lowest acceptable level of security. Not everyone is faced with the same problems or places the same value on specific aspects of security.
Ability to decode encrypted sessions after the fact could in some instances offer more value than risks associated with retroactive effects of key compromise. TLS after all has ability to negotiate ciphers offering no encryption at all while still offering integrity protection for data.
If your using TLS for an industrial control application perhaps there is no value in keeping commands issued secret yet there is extreme value in maintaining integrity of data so harmful commands can't be injected by an attacker. In this scenario forward secrecy has no value, and you lose the ability to retroactively validate data stream with ephemeral keys.
For troubleshooting, auditing and political considerations (like it or not leakage prevention is a multi-billion dollar industry) an organization may deem properties of forward secrecy to be more of a liability than an asset.
Also session tickets and ephemeral keys don't mix.
Obviously you want to provide the strongest generally applicable level of security by default in any specification or implementation however if you want to provide a technological solution *everyone* can use it by necessity needs to support full range of tradeoffs where reasonable. In this case I am not hearing the "reasonable" argument for deletion of these suites.
Reasons Joe cites for removal sound like typical IETF jargon used to provide technical cover for political decisions.
lack of PFS
by identity/choice
pre-master secret contributed only by the client
No, this is an independently addressable (non)issue.
and the general weakening of RSA over time
If RSA is weak then using RSA at all to impart trust upon ephemeral keys is a receipt for disaster. This reduces to the general argument for PFS which everyone should and is free and encouraged to use.
It would make the security analysis simpler
There must be what hundreds of cipher suites by now.. seriously... analyze the ones you see value in using and disable the rest. This makes as much sense as telling the Russians you are deleting suites with *gost* in them or Japanese *camilla* simply because they would be easier to analyze.
is a bit *too* trendy these days. The NSA should be about five - ten years away from breaking it. If you have secrets that will be worthless by then, then by all means, use it.
Religion is what happens when nature strikes and groupthink goes wrong.
Does it hurts me when it does that to my private things?
Some people can misuse your private things to take your money or to lie to other people that you did things that you never really did. This misuse is called "identity theft". And that's one thing that encryption can help prevent when used in the right way.