[Twisted-Python] Elliptic Curve support

[Thedore Oidelson]

I'm taking Glyph's suggestion and bringing this to the mailing list. :)

I still believe it was unwise to remove the support for the extra EC curves
in PR #749 for a few reasons that I've said in a few different places so
I'll summarize them here.

* Support for more curves is better. It gives more options to users and
developers such as myself who want to use Twisted for custom environments.
All of this widens the support base.

* These are all curves suggested in RFC 5656, and I believe the more
Twisted supports the RFC the better.

* There are cases for using alternative curves. NIST-T-571 is stronger
than any of the currently supported curves. NIST-K-163 is weaker, but
there are still uses for it. I may be working in an embedded environment
where every CPU cycle counts and I just need simple encryption to protect
against simple plain text scanning.

* Having extra curves does not make Twisted less secure. SSH negotiates
encryption based on a list of preferred ciphers. We put the strongest
ciphers first and the weaker curves only get used if nothing better is
available where weak encryption is still better than no encryption.

There are other reasons why I think it makes sense to have the curves in
Twisted but these are the main ones.

[Tobias Oberstein]

Hi,

I do think letting users configure the permissible curves (and their
priority) using a public tx API, and exposing all of the curves that the
underlying openssl provides is important.

FWIW, the german BSI (a state IT security institute that provides
recommendations, and certifications) now recommends:

brainpoolP256r1, brainpoolP384r1, brainpoolP512r1

and only if none of these is avail, falls back to

secp256r1, secp384r1

Page 15 (3.6.1) here:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile

--

Currently, eg Crossbar.io is using secp256r1 (not configurable)

https://github.com/crossbario/crossbar/blob/master/crossbar/twisted/tlsctx.py#L331
https://github.com/crossbario/crossbar/blob/master/crossbar/twisted/tlsctx.py#L206

and we would like to move to a configurable, maintainable solution.

Cheers,
/Tobias

Post by Thedore Oidelson
I'm taking Glyph's suggestion and bringing this to the mailing list. :)
I still believe it was unwise to remove the support for the extra EC curves
in PR #749 for a few reasons that I've said in a few different places so
I'll summarize them here.
* Support for more curves is better. It gives more options to users and
developers such as myself who want to use Twisted for custom environments.
All of this widens the support base.
* These are all curves suggested in RFC 5656, and I believe the more
Twisted supports the RFC the better.
* There are cases for using alternative curves. NIST-T-571 is stronger
than any of the currently supported curves. NIST-K-163 is weaker, but
there are still uses for it. I may be working in an embedded environment
where every CPU cycle counts and I just need simple encryption to protect
against simple plain text scanning.
* Having extra curves does not make Twisted less secure. SSH negotiates
encryption based on a list of preferred ciphers. We put the strongest
ciphers first and the weaker curves only get used if nothing better is
available where weak encryption is still better than no encryption.
There are other reasons why I think it makes sense to have the curves in
Twisted but these are the main ones.
_______________________________________________
Twisted-Python mailing list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Glyph Lefkowitz]

Post by Thedore Oidelson
I'm taking Glyph's suggestion and bringing this to the mailing list. :)

Thank you :). Hopefully some people more qualified than me will comment...

Post by Thedore Oidelson
I still believe it was unwise to remove the support for the extra EC curves in PR #749 for a few reasons that I've said in a few different places so I'll summarize them here.

I have some arguments with the form of your argument here, but I should emphasize that I don't know enough about the specific underlying crypto to go one way or another - mostly I'm trusting the opinions of Alex Gaynor, and your counterpoints are not convincing (yet).

Post by Thedore Oidelson
* Support for more curves is better. It gives more options to users and developers such as myself who want to use Twisted for custom environments. All of this widens the support base.

Not necessarily. Support for more curves may allow or encourage the use of insecure curves by naive users.

Post by Thedore Oidelson
* These are all curves suggested in RFC 5656, and I believe the more Twisted supports the RFC the better.

RFC 5656 is very old. Specifically: pre-heartbleed, pre-snowden, pre-BULLRUN revelations. Just because it's in that RFC is not a compelling argument for its inclusion.

Post by Thedore Oidelson
* There are cases for using alternative curves. NIST-T-571 is stronger than any of the currently supported curves. NIST-K-163 is weaker, but there are still uses for it. I may be working in an embedded environment where every CPU cycle counts and I just need simple encryption to protect against simple plain text scanning.

These types of use-cases do not require these curves to be enabled by conch by default. They just require there being a public API to enable these things.

Post by Thedore Oidelson
* Having extra curves does not make Twisted less secure.

If they are enabled by default, it very well can.

Post by Thedore Oidelson
SSH negotiates encryption based on a list of preferred ciphers. We put the strongest ciphers first and the weaker curves only get used if nothing better is available where weak encryption is still better than no encryption.

Or if an adversary successfully executes a downgrade attack.

There's downgrade detection in SSH, but we shouldn't rely on it to be perfect.

Post by Thedore Oidelson
There are other reasons why I think it makes sense to have the curves in Twisted but these are the main ones.

I think it might be more productive to argue for the inclusion of individual curves on a case-by-case basis. "should it be included at all" and "should it be enabled by default" are also separate questions.

-glyph

[Thedore Oidelson]

Glyph, I understand your and other's concerns, and while clearly I feel a
little differently, my real concern was how the curves I was using were
suddenly not supported at all. Which is why I think the API you and Tobias
suggested is a good compromise.

I have the code to do this just about ready and will submit a ticket and PR
shortly.

Post by Thedore Oidelson
I'm taking Glyph's suggestion and bringing this to the mailing list. :)
Thank you :). Hopefully some people more qualified than me will comment...
I still believe it was unwise to remove the support for the extra EC
curves in PR #749 for a few reasons that I've said in a few different
places so I'll summarize them here.
I have some arguments with the form of your argument here, but I should
emphasize that I don't know enough about the specific underlying crypto to
go one way or another - mostly I'm trusting the opinions of Alex Gaynor,
and your counterpoints are not convincing (yet).
* Support for more curves is better. It gives more options to users and
developers such as myself who want to use Twisted for custom environments.
All of this widens the support base.
Not necessarily. Support for more curves may allow or encourage the use
of insecure curves by naive users.
* These are all curves suggested in RFC 5656, and I believe the more
Twisted supports the RFC the better.
RFC 5656 is *very* old. Specifically: pre-heartbleed, pre-snowden,
pre-BULLRUN revelations. Just because it's in that RFC is not a compelling
argument for its inclusion.
* There are cases for using alternative curves. NIST-T-571 is stronger
than any of the currently supported curves. NIST-K-163 is weaker, but
there are still uses for it. I may be working in an embedded environment
where every CPU cycle counts and I just need simple encryption to protect
against simple plain text scanning.
These types of use-cases do not require these curves to be enabled by
conch by default. They just require there being a public API to enable
these things.
* Having extra curves does not make Twisted less secure.
If they are enabled by default, it very well can.
SSH negotiates encryption based on a list of preferred ciphers. We put
the strongest ciphers first and the weaker curves only get used if nothing
better is available where weak encryption is still better than no
encryption.
Or if an adversary successfully executes a downgrade attack.
There's downgrade detection in SSH, but we shouldn't rely on it to be perfect.
There are other reasons why I think it makes sense to have the curves in
Twisted but these are the main ones.
I think it might be more productive to argue for the inclusion of
individual curves on a case-by-case basis. "should it be included at all"
and "should it be enabled by default" are also separate questions.
-glyph
_______________________________________________
Twisted-Python mailing list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Glyph Lefkowitz]

Glyph, I understand your and other's concerns, and while clearly I feel a little differently, my real concern was how the curves I was using were suddenly not supported at all. Which is why I think the API you and Tobias suggested is a good compromise.

I'm still a little unclear as to why you were specifically using these curves, which I think informs this discussion somewhat :). For example, if you're testing with intentionally weak curves then we should be putting these behind an API that is as awkward to use as possible :).

I have the code to do this just about ready and will submit a ticket and PR shortly.

Cool. Hopefully our cryptographers in residence will have no issue with an API that you have to call to specifically enable these.

-glyph