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. On Mon, Apr 17, 2017 at 10:28 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > On Apr 17, 2017, at 9:46 AM, Thedore Oidelson <the0idel...@gmail.com> > wrote: > > 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 > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
