5 ms·

> It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-

by syzzer 11y ago

> It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe.. https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe.... exists. This draft /does/ encourages use of larger keys, but also encourages the use of common parameter groups. The weakdh.org site mentions the use of common groups is a reason for this attack to be feasible. It also advises sysadmins to generate their own parameters. To me, that makes using common groups sound like a bad move. The problem is, I lack proper knowledge to assess whether using common groups really is a bad move, even when using larger group sizes... Anyone here who can?

acqq 11y ago
Obviously weakdh has more up-to-date recommendations (public only a few hours!) so you should certainly not cling to the older ones published by IETF who-knows-when and which could have been influenced by the players who prefer the weaker encryption for their own benefit. I don't understand why you would not believe weakdh recommendations? The researchers describe in their paper (1) exactly how they can precompute some values only once in order to then do fast attacks on any vulnerable communication. They proved that the common and too small values are both dangerous. It's real. And it's definitely not "choose the one you like." Change both. 1) https://weakdh.org/imperfect-forward-secrecy.pdf https://weakdh.org/imperfect-forward-secrecy.pdf "Precomputation took 7 days (...) after which computing individual logs took a median time of 90 seconds."
- syzzer 11y ago
  I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters. Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it is a problem with smaller groups.
  - acqq 11y ago
    The newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example. The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just somebody sometimes somewhere. Moreover, the main reason why it should be done is that the expected browser updates won't block the sites with 1024 bits. So all the sites which for whatever reason still use 1024 bits won't be so vulnerable if they had their own parameters. The practice of using the common parameters already now worsens the current state. The bad effects of the really bad move already exist. The common parameters are now provably bad and it won't change in the future. Just don't use the common parameters. Generate the new ones everywhere. And, of course, "minimum 2048 bits, please." Edit: audi alteram... means "listen to the other side." Which side is the other side here? The stale information is not "the other side" it's just stale.
    - syzzer 11y ago
      Thanks for elaborating. The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent. I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/ https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack. To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
      - schoen 11y ago
        The folks working on that draft have definitely become aware of this research. Soon we'll see what they have to say about it.
qrmn 11y ago
Neither. ECDHE on P-256 doesn't have this problem, is available almost everywhere and is faster and safer: use that, or better still, Curve25519 and friends (in OpenSSH already, coming up in TLS later this year hopefully?). There's very little reason in practice to bother trying to patch DHE, it's slow and old and interoperates worse (thanks Java). Chrome's just taking it out in the medium-term.
- sarciszewski 11y ago
  They standardized on Ed448-Goldilocks: https://mailarchive.ietf.org/arch/msg/cfrg/BPDuOnVbrWiMSCjcfP6YTiaS6NY https://mailarchive.ietf.org/arch/msg/cfrg/BPDuOnVbrWiMSCjcf...

by syzzer 11y ago

acqq 11y ago

Obviously weakdh has more up-to-date recommendations (public only a few hours!) so you should certainly not cling to the older ones published by IETF who-knows-when and which could have been influenced by the players who prefer the weaker encryption for their own benefit. I don't understand why you would not believe weakdh recommendations? The researchers describe in their paper (1) exactly how they can precompute some values only once in order to then do fast attacks on any vulnerable communication. They proved that the common and too small values are both dangerous. It's real. And it's definitely not "choose the one you like." Change both. 1) https://weakdh.org/imperfect-forward-secrecy.pdf https://weakdh.org/imperfect-forward-secrecy.pdf "Precomputation took 7 days (...) after which computing individual logs took a median time of 90 seconds."

syzzer 11y ago
I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters. Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it is a problem with smaller groups.
- acqq 11y ago
  The newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example. The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just somebody sometimes somewhere. Moreover, the main reason why it should be done is that the expected browser updates won't block the sites with 1024 bits. So all the sites which for whatever reason still use 1024 bits won't be so vulnerable if they had their own parameters. The practice of using the common parameters already now worsens the current state. The bad effects of the really bad move already exist. The common parameters are now provably bad and it won't change in the future. Just don't use the common parameters. Generate the new ones everywhere. And, of course, "minimum 2048 bits, please." Edit: audi alteram... means "listen to the other side." Which side is the other side here? The stale information is not "the other side" it's just stale.
  - syzzer 11y ago
    Thanks for elaborating. The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent. I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/ https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack. To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
    - schoen 11y ago
      The folks working on that draft have definitely become aware of this research. Soon we'll see what they have to say about it.

qrmn 11y ago

Neither. ECDHE on P-256 doesn't have this problem, is available almost everywhere and is faster and safer: use that, or better still, Curve25519 and friends (in OpenSSH already, coming up in TLS later this year hopefully?). There's very little reason in practice to bother trying to patch DHE, it's slow and old and interoperates worse (thanks Java). Chrome's just taking it out in the medium-term.

sarciszewski 11y ago
They standardized on Ed448-Goldilocks: https://mailarchive.ietf.org/arch/msg/cfrg/BPDuOnVbrWiMSCjcfP6YTiaS6NY https://mailarchive.ietf.org/arch/msg/cfrg/BPDuOnVbrWiMSCjcf...