[OWASP-cheat-sheets] DHE versus ECDHE

Torsten Gigler torsten.gigler at owasp.org
Sun Jun 22 19:20:33 UTC 2014


Dear Jim,

thank you for forwarding this feedback.

Am 21.06.2014 20:17, schrieb Jim Manico:
> Torsten,
>
> (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 
industry." 
[https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929]. 

   => 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 
<http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#some-benchmarks>." 
-> 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:
>
> https://dev.ssllabs.com/ssltest/analyze.html?d=owasp.org&hideResults=on
>
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 
forward secrecy).
> - 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: 
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
Do you have a latest information on this? Do you know implementations 
for TLS?
>
> - 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 
different discussion...

Kind regards and stay secure
Torsten
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-cheat-sheets/attachments/20140622/e58ed2b2/attachment.html>


More information about the OWASP-cheat-sheets mailing list