Also, please be patient. This needs to be done carefully and any ECC related change needs to be cleared first. Should not take six years. :)

the "only ECC NIST Suite B curves support" seems to cripple down openssl again
with "openssl-1.0.1e-4.fc18.1" all fine over days and starting with "openssl-1.0.1e-28.fc18" a few messages like below in maillog and lead to fall back to a unecnrypted connection (yes postfix was rebuilt against the new SSL build)

Oct 21 20:26:44 mail postfix/smtp[2217]: warning: TLS library problem: 2217:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:17:45 mail postfix/smtp[7226]: warning: TLS library problem: 7226:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:20:04 mail postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:46:17 mail postfix/smtp[9202]: warning: TLS library problem: 9202:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:58:54 mail postfix/smtp[10007]: warning: TLS library problem: 10007:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12293]: warning: TLS library problem: 12293:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
______________________________________________

result of "only ECC NIST Suite B curves support" followed by "relay=mx00.gmx.net[213.165.67.114]:2" unencrypted

Oct 21 21:55:33 mail postfix/smtp[9799]: SSL_connect error to mx00.gmx.net[213.165.67.114]:25: -1
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 21 21:55:33 mail postfix/smtp[9799]: 3d3T9G66cmz23: Cannot start TLS: handshake failure
Oct 21 21:55:33 mail postfix/smtp[9799]: Host offered STARTTLS: [mx00.gmx.net]


Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to mx00.gmx.net[213.165.67.99]:25: -1
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 21 22:29:22 mail postfix/smtp[12289]: 3d3Tvy5Cdsz23: Cannot start TLS: handshake failure

as you clearly can see before the update all was fine

Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64
__________________________________

Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 20:07:16 mail postfix/smtp[1687]: Trusted TLS connection established to mx00.gmx.net[213.165.67.114]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 20:15:02 mail postfix/smtp[3036]: Trusted TLS connection established to mx00.gmx.net[213.165.67.114]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Hmm. When I look at the cipher list in the latest openssl (run: openssl ciphers), I see:

ECDHE-RSA-AES256-GCM-SHA384

I'm not sure why postfix doesn't pick it up. If you hadn't already said you rebuilt postfix against the latest openssl, I'd suggest trying that. :/ 

Might need to file a separate bug against openssl directly.

who file? you or me?
the change was yours :-)

verified 100% for sure, tried with the original ECDHE-supporting openssl 
again and it delivers like a charme to the same GMX host

here you go: http://marc.info/?l=postfix-users&m=138239029006207&w=2

Well, both ends can support ECDH and not agree on the curve to use. Curves are negotiable too, but both ends must implement the right extensions, IIUC.

but what to do?

until the last change god bless ECDHE worked like a charme
i rebuilt postfix/dovecot/httpd on the same day it was available 
there was no single issue with the first ECDHE-enabled openssl build

Quoting from the postfix mailing list at http://archives.neohapsis.com/archives/postfix/2013-10/0462.html

"The author of comment #4 is not getting it.  The problem is NOT
that Postfix fails to negotiate EECDH, rather the problem is that
it does!  Once EECDH is negotiated, the server (gmx) selects an
unsupported (by RedHat's crippled OpenSSL) curve and the handshake
fails."

So doesn't that mean that for EECDH to work the openssl-1.0.1e-speed-suiteb.patch needs to be reverted?

For completeness here are the ones disabled by that patch:

ecdsap160, ecdsab163, ecdsap192, ecdsap224, eecdsab233, ecdsab283, ecdsab409, ecdsap521

ecdsak163, ecdsak233, ecdsak283, ecdsak409, ecdsak571

ecdhp160, ecdhp192, ecdhp224, ecdhp521
 
ecdhk163, ecdhk233, ecdhk283, ecdhk409, ecdhk571

ecdhb163, ecdhb233, ecdhb283, ecdhb409, ecdhb571

Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4), there is either a bug in the server or the client isn't offering the extension advertising the curves it supports. You need to get the protocol message trace in order to determine which.  If it's client-side, the bug is (probably) against postfix. If you want openssl to support more curves, you should file a new bug.

As mentioned in comment #0:
> Please do not use this bug to discuss issues that can be more appropriately
> discussed on a bug for a particular package.

(In reply to Scott Schmit from comment #9)
> Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4), there is
> either a bug in the server or the client isn't offering the extension
> advertising the curves it supports. You need to get the protocol message
> trace in order to determine which.  If it's client-side, the bug is
> (probably) against postfix. If you want openssl to support more curves, you
> should file a new bug.

Indeed. If there is a specific curve that is needed, it would be generally helpful to know which one (and why).

well, someone with debug-knowledge could register a freemail address at https://registrierung.gmx.net/

Oct 22 10:16:29 mail postfix/smtp[13476]: warning: TLS library problem: 13476:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 22 10:16:29 mail postfix/smtp[13476]: warning: TLS library problem: 13476:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 22 10:16:29 mail postfix/smtp[13476]: 3d3nc82yyrz2k: Cannot start TLS: handshake failure
Oct 22 10:16:30 mail postfix/smtp[13476]: Host offered STARTTLS: [mx01.gmx.net]

On the other other hand, a slightly more detailed explanation than

only ECC NIST Suite B curves support
- drop -fips subpackage 

in the commit http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=b3551463cafee86a63c60e294f754a8c5cddc37a that triggered this would be generally helpful, too. I.a.W.: Say "why", not just "what" in your commit message. And that diff is large for just removing something, and even has large additions.

Of course, using tags so that one can associate package versions with commits more easily would be generally helpful, too. At least that info is in the spec diff.

But we should take this whole discussion to an openssl bug.

well, that guy is the maintainer of the postfix SSL/TLS code

http://marc.info/?l=postfix-users&m=138240935211163&w=2

> I can't connect to gmx's SMTP servers on port 25 from my laptop
> since I am on a residential dynamic IP.  On port 587 however, I
> can definitely confirm that [smtp.gmx.de]:587 is using secp521r1,
> which is one of the curves removed by RedHat.  It seems likely
> that they do the same on port 25

http://marc.info/?l=postfix-users&m=138242211613713&w=2

    ---
    Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4),
    there is either a bug in the server or the client isn't offering
    the extension advertising the curves it supports. 
    ---

* Firstly, client TLS extensions are not possible when the client starts
  with an SSLv2 compatible SSL HELLO.  So the list of supported curves
  is not sent by clients that are backwards compatible with SSLv2 (though
  of course by now SSLv2 should be disabled in most clients).

* Secondly, the OpenSSL server API does not expose the client's
  supported EC curves to the server application which is expected
  to configure the EECDH curve.  Thus the extension from RFC 4492
  is almost never used, most servers choose the EECDH curve blindly.

* Auto-configuration of the server curve (in response to client
  extensions) is coming in OpenSSL 1.0.2 which is not yet released!

Greetings.

We'd like to have the secp256k1 curve included because it is a requirement for the Bitcoin software.

secp256k1 a curve with fully rigid parameters (in DJB's parlance: http://safecurves.cr.yp.to/rigid.html, meaning there is no substantial author side freedom to choose curves with secret weaknesses) over a prime field (e.g. it is not a characteristic-2 curve, which have had some specific patent issues in the past).

Like other fully rigid curves secp256k1 supports certain high speed implementations (and this, combined with security constraints is what fixes the curve parameters in a fully rigid curve selection), but OpenSSL does not implement any of these fancy performance enhancements and uses curve generic code for them.

Cheers.

The postfix issue might have been fixed by bug 1022493.

confirmed: postfix/smtp[13130]: Trusted TLS connection established to mx01.gmx.net[213.165.67.97]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

lighttpd (an alternate web server) also needs a recompile.  Whoever has the template that is opening the specific bugs might want to open one for lighttpd too.

> Whoever has the template that is opening the specific bugs 
> might want to open one for lighttpd too.

well, no template needed, simply open a bug is enough
here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1025882

(In reply to Harald Reindl from comment #18)
> > Whoever has the template that is opening the specific bugs 
> > might want to open one for lighttpd too.
> 
> well, no template needed, simply open a bug is enough
> here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1025882

It must also block this bug. It might also need to CC tcallawa, but I am not sure about that, and he already receives enough bugspam just from this tracking bug ;-)

Hi, about bug #1012272,  since we haven't disable it, is already enabled so we can close the bug ?

(In reply to Sergio Monteiro Basto from comment #20)
> Hi, about bug #1012272,  since we haven't disable it, is already enabled so
> we can close the bug ?

yes, it can be closed as NOTABUG

Please consider #1064149.

Hello , 

openssl ecparam -list_curves

secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field

So openssl just enabled 4 of 81 elliptic curve cryptography that are available on openssl (without hobble-openssl ) 

I'd like require enable sect233k1  NIST/SECG/WTLS curve over a 233 bit binary field which is the default for secg.org TLS test server, according 
M2Crypto-0.22.5/M2Crypto/EC.py file .

The security of the binary curves is disputed and I do not like reenabling them.

@Tomas: How are they disputed?

See for example here:
https://www.quora.com/What-are-the-advantages-of-elliptic-curve-cryptography-using-binary-fields-over-prime-fields-and-vice-versa?share=1

Also note that openssl upstream wants to remove the binary field curves from the default set in the 1.1.0 branch. It does not mean that the support for binary field curves will be removed, just it won't be in the default supported set for TLS anymore.

Tomas,

I'm not sure if that necessarily means you shouldn't enable them. There has not yet been a provable case where you could definitively break those curves. Honestly, I would err on the side of making the curves available simply because upstream offers them.

Hobbling it like this is not helpful or useful to others who may want or need these curves.

It's up to you, of course, but I would strongly suggest that unless there's definitively a good reason to disable them, you should allow them to be usable in Fedora.

Hi,
from (#1067697) many EC aren't enable , but first we need to know what elliptic curves are legal and what elliptic curves are not legal. 
Tomas Mraz wrote : AFAIK there is no blank approval for any elliptic curves by legal anyway.

Meanwhile I built openssl unhobble , my work is here [1] I had test it since Dez 14 2015 , I added openssl-fips-2.0.10.tar.gz . my openssl.spec is in a draft state and of course needs many clean ups.

But the main propose of this comment is to know what elliptic curves could be enabled by FE-Legal, should we block FE-Legal bug tracker ?  

[1] https://github.com/sergiomb2/openssl

With regards to OpenSSL, the curves which are currently enabled are the ones which have been cleared by legal. Any disabled curves are disabled intentionally.

All blocking bugs are closed - shall we close this ticket as well now?

Looks like the last dependency bug marked 'RAWHIDE' has the code in f23, so closing 'CURRENTRELEASE'.

Thanks, everybody (especially Spot) - great work all around!

Err, isn't this supposed to remain open in the event more disabled curves are requested to be opened?

Neal, I think we've fixed "Fedora doesn't permit ECC".  If you create a tracking bug for enabling additional curves, I'd love to be on the CC:.