[OWASP-cheat-sheets] DHE versus ECDHE
torsten.gigler at owasp.org
Sun Jun 22 19:20:33 UTC 2014
thank you for forwarding this feedback.
Am 21.06.2014 20:17, schrieb Jim Manico:
> (from another expert who shall remain nameless)
It's a pity, it is is easier to discuss with somebody with a name.
> If your threat model includes the NSA -- which are suspected to be
> behind the parameters of the NIST curves -- then you shouldn't be
> using TLS in the first place. That line of thinking isn't very
> productive. 99.99% of sites don't have the NSA as their adversary.
> It's important to understand what you're defending against.
Well, I run for Web Application Security in general. I see this as a
fundamental Trade-Off between Security, Costs and Usability.
I do see for the decision DHE versus ECDHE in this case:
- Security: There are 2 Ways to realize Perfect Forward Secrecy (PFS)
with TLS (to obtain long term security for the Transported Data):
+ DHE: I have not found fundamental discussions about the
security of this Protocol, which is considered as a reliable indicator
for that it is simply doing for what is developed
+ ECDHE: There are serious discussions about the security of the
NIST-Curves: Main issue is that 'Coefficients (are) generated by hashing
the unexplained seed'. It had been claimed that this was done for
'performance reasons'. As some cryptography specialists with the highest
reputation could not confirm this, they even figured out just the
opposite: "Subsequent research ... showed that essentially all of these
efficiency-related decisions were suboptimal, that many of them actively
damaged efficiency, and that some of them were bad for security"
[http://safecurves.cr.yp.to/], "I no longer trust the constants. I
believe the NSA has manipulated them through their relationships with
=> As a conclusion DHE is considered as the *first* and ECDHE only as
the *second* best practice (from security aspect).
- Costs: As mentioned in the Cheat Sheet "*TLS handshake* with DHE
hinders the CPU abt 2.4 times more than ECDHE, cf. Vincent Bernat, 2011
-> I think this is (generally) OK.
- Usability: The Ciphers are transparent for the users, so the worst
that could happen should be some milliseconds longer time to wait -> OK
So I do think it is a good practice to favor DHE over ECDHE (The server
negotiates DHE with Browsers that support DHE+ECDHE or DHE, and ECDHE
with Browsers that support solely ECDHE (like Internet Explorer))
Protection: I think, we should protect our services against any attacker
if we can bring these 3 things in a line. All other things may be a
local decision according to a personal risk assessment.
> Some further points:
> - I haven't seen any actual _evidence_ that the NIST curves
> are insecure. They might or might not be (insecure), but you can't
> make decisions based on speculation alone.
I consider the above results as a fact that the line of arguments about
the claimed use of the ECDHE parameters is not conclusive in itself (at
least it could be seen as 'security by obscurity', as long as the
responsible standardization institution does not explain more detailed
the reason why the parameters are like they are). So why take the second
quality? This may change when commonly accepted Curves will be available.
> - Without ECDHE you're unlikely to have _any_ forward secrecy with
> Microsoft platforms. SSL Labs warns about this for OWASP:
Yes, I agree with this. ECDHE is part of the cipher suite I am
suggesting in the Cheat Sheet, but as second quality as a fall back for
software and hardware that does *not* support DHE: E.g. IE7-11 on Vista
and newer use 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)' according to
my cipher simulation. Latency browsers like IE6/IE8 on XP/Win2003 will
fall back to 'TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)' (without perfect
> - As a rule of thumb, resumption works 50% of the time.
Thanks for this input. I'd like to add this to the 'Notes' section. Do
you have any link for this?
> - Curve 25519 is being added to TLS.
I have *not* found it in the IANA standard, yet:
Do you have a latest information on this? Do you know implementations
> - OWASP's DH parameters are only 1024 DH bits, which is about 80 bits
> of security. With ECDHE, you'd have super-strong 128 bits. That's a
> fact, not speculation ;)
This is an issue of this site of today. I agree with you that this
should be changed, too: "If a commonly accepted cipher string is found,
I'd suggest to set up owasp.org <http://owasp.org> as a reference
installation ...." (this goes beyond the cipher sting). But this is a
Kind regards and stay secure
> Jim Manico
> (808) 652-3805
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-cheat-sheets