On Tue, 22 Oct 2013, Paul Hoffman wrote:

[ With my Red Hat on but using personal email to prevent moderation queues ]

   - RedHat has been under pressure for some time to enable EC support
     in their OpenSSL RPM package.

    * They finally relented and added EC support ~1 week ago.  However,
      they quickly decided to play it safe and enable just the Suite-B
      curves: secp256r1, secp384r1 and no others.

Note that "quickly decided" is a little judgemental and unfair. Enabling
ECC has been at least a year in the making. It predates Snowden.

    * They neglected to consider that the new libraries now
      happily negotiate EECDH key exchange TLS cipher-suites with
      servers that typically don't know of (or can't act on) the
      client's limitations.

The elliptic_curves extension informs a server which curves the client
supports, and openssl uses that extension. So that should not be a
problem. However, Hubert Kario found out that we advertise support for
curves that are not actually supported. We are addressing that bug now:

https://bugzilla.redhat.com/show_bug.cgi?id=1022468
Openssl advertises support for curves it doesn't actually support in Client 
Hello (edit)

Remember, bugs are resolved faster if reported properly. Please feel
free to contact me regarding any security/crypto bugs in RHEL/Fedora
and I'll ensure proper bugs are filed and tracked.

    * At the same time newly hardened SMTP servers at gmx.de
      and other sites have "stronger" security by switching to
      secp521r1.

With the above bug addressed, it should select a non-ECC cipher suite.

Rolling improved security out to end-users will likely take on the order of a 
decade.

Wow, that's rather pessimistic :P

In the mean-time, users should make an effort to configure their
systems to employ current best-practice security, trying to go
beyond that into uncharted territory may well be counter-productive.

Users should not do so. Vendors should do it for them. Users who tweak
crypto parameters manually are not users - they are developers.

Paul
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to