Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Encryption Security

TLS 1.3 Draft Prepares to Drop Static RSA Key Exchange 51

Posted by Unknown Lamer
from the forward-secrecy-for-all dept.
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.
This discussion has been archived. No new comments can be posted.

TLS 1.3 Draft Prepares to Drop Static RSA Key Exchange

Comments Filter:
  • by Anonymous Coward on Wednesday May 07, 2014 @11:29AM (#46940847)

    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.

    • by goddidit (988396)

      Generating RSA keys is more costly than, for example, ECDH keys. Checks for primality for the p and q, are needed for it to be secure for RSA. In my understangin, any big enough integer is a valid DH private key.

      Static RSA would be nice for certain applications, since it is computationally cheaper to do for the client. Also, with DANE for instance, the same primitives can be used to check signatures. Yet, RSA might be costly in the future keylengths. For instance, some say that 256-bit symmetric keys are eq

      • by Bengie (1121981)
        It's been a while, but I think the break even point for computational costs between RSA and ECC is something around 1500bit RSA and 200bit ECC, but the 200bit ECC is much stronger. ECC's computation grows closer to linear while RSA is exponential. With 2048bit RSA being standard now, ECC is now cheaper, minus hardware acceleration reasons.
  • by Anonymous Coward

    In other news [eweek.com], 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 [nist.gov]) for 4 years, without no one taking the responsibility to fix it.

    OpenBSD developer Ted Unangst made a detailed report [tedunangst.com] 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 environme

    • Yeah, I've been trying to keep up [opensslrampage.org]. It's heavy stuff and a little over my head sometimes but never the less very interesting (and sometimes very amusing).

      • It's also pretty shocking that such madness even exists, save that open source can be like government, fixing only the things that people really bitch about, rather than infrastructure components that are decades old, and older.

        If people paid attention to core components like they did the Linux kernel perhaps there'd be a lot of noise, but a lot of better code.

        Yo: Linus-- you listening? Kernel ain't crap without other components that work and are rationally safe. Cut loose a few of your homies to do some ma

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

    • But why the hate for RSA? It's a well understood algorithm.

      Maybe because RSA has proven time and again that they can't be trusted [reuters.com]?

      • by bytesex (112972)

        Are you purposely, or ignorantly, confusing RSA, the company, with RSA, the assymetric cipher suite based on primes?

        • Got it . . . easy for someone who doesn't work with crypto every day to get confused, especially as RSA the company has developed many security-related bits of infrastructure. In fact, as far as I can tell, there's no relationship between RSA (the company) [wikipedia.org] and RSA (the crypto suite) [wikipedia.org]. My bad.
          • by Kjella (173770)

            In fact, as far as I can tell, there's no relationship between RSA (the company) and RSA (the crypto suite). My bad.

            Well, none except the RSA in the company and the cipher is the same. Or did you miss this line?

            Ron Rivest, Adi Shamir and Leonard Adleman, who developed the RSA encryption algorithm in 1977, founded RSA Data Security in 1982

            • Nope -- I didn't miss it. 1982 was a long time ago, and RSA (the company) bears little resemblance today to RSA (the company) of 1982. In any case, was RSA (the company) involved in the development / imporvements / other iterative activities related to RSA (the crypto suite in question) or not, especially recently? Because if that's the case, my original point stands, as there's plenty of evidence that RSA (the company) has been complicit in NSA's efforts to backdoor and other undermine / weaken componen
      • Maybe because RSA has proven time and again that they

        In this context by "RSA" we're talking about use of prime numbers as basis for a public key cryptosystem rather than the company "RSA".

        http://en.wikipedia.org/wiki/R... [wikipedia.org]

    • What the TLS designers need to think about is how to reduce the options to one well understood choice.

      Putting all of your eggs in one basket yields global disaster with unacceptable lag times to recovery when dropped.

      It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options.

      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.

      KISS is great and all but it falls apart when you go that one step further and try to oversimplify.

      Anyone can look at a specific problem and provide a *relativ

      • I disagree. There has been far more failure in SSL/TLS protocols and implementation from complexity in the handshakes than there has been from the basic crypto being broken (which it isn't).

        Make a really good basket and put your eggs in it.

        >KISS is great and all but it falls apart when you go that one step further and try to oversimplify.

        Not in crypto. Complexity is crypto is nothing but fail.

        >Anyone can look at a specific problem and provide a *relatively* simple custom crypto solution to solve that

      • by TXISDude (1171607) *
        "It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options."

        This mentality has led to so many errors - lest I say many C functions, that routinely result in fail because no one did bounds checking . . . We will always have poor developers, so we need to use standards and tech to help them get it right. Saying it is the develo
        • by weilawei (897823)

          The temptation to optimize for speed/memory usage over producing correct code is like will'o'the'wisps for many developers. If you develop code for a hostile environment (the default assumption for crypto) it should be assumed that any inputs will be abused.

          Further, in a hostile environment, developers also need to assume that they won't have anticipated every possible way to extract information from a process. Do the simplest thing that will always work, within the limits you can predict. Then fix the bugs

    • But why the hate for RSA?

      Because elliptic curve is less expensive: Providing the same degree of difficulty for far less bits, or more computational difficulty for the same bits. Takes less CPU to compute, so lighter weight makes it more useful. Eg: In my alternate distributed "toy" OS's PKI system there are "permission spaces". Every agent can be granted a permission, and can grant permissions to other agents, perhaps reducing the permissions possible the agent can grant to the next, including the permission to grant certain per

  • 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 u

    • by Kjella (173770)

      TLS is supposed to provide point-to-point security, if you want the information to also go somewhere else then send it there. If you don't trust the starting point then have the ending point do it. So your industrial control system sends commands X to machinery Y, machinery Y forwards it to logger Z before executing the command. Or have the logger be an intentional MITM. While the problems are genuine I feel your solutions create complications in all the wrong places.

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

Be careful when a loop exits to the same place from side and bottom.

Working...