Author markk
Recipients Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, ezio.melotti, jcea, lemburg, markk, ncoghlan, pitrou, python-dev, r.david.murray, vstinner
Date 2014-04-23.14:26:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1398263202.09.0.711529704898.issue20995@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the detailed insight, Donald! And I certainly love the progress these changes here bring. :-)

Perhaps limiting the scope to ChaCha20Poly1305 (»CCP«) has been a wrong approach of mine to explain my concerns:

We should not refer to any particular cipher in those lists, and by that avoid to revisit the defaults at any point in the future.

0. Properties of any cipher to come are known to the makers of OpenSSL first.
1. Python shouldn't duplicate the work of ordering ciphers, which is already done by OpenSSL.
2. … especially because it is unknown which ciphers a user's OpenSSL does actually implement (Is EC present? CCP? HC-256 or HC-128? WIERZA? Rabbit? NTRU…) or will implement in the future.
3. Whether a cipher is regarded as more secure than another depends on its implementation, too. The implementors are better judges of that, and hence ordering should done by them and could vary between versions [e.g., of OpenSSL].
4. Given our experiences with Python 2.7 I'd like to argue that there is reluctance to upgrading existing installations and its cipher suite strings. ;-)

But we know from experience with already established ciphers if and when to demote them.

That said I don't insist on any changes.
History
Date User Action Args
2014-04-23 14:26:42markksetrecipients: + markk, lemburg, jcea, ncoghlan, pitrou, vstinner, christian.heimes, benjamin.peterson, ezio.melotti, Arfrever, alex, r.david.murray, python-dev, dstufft
2014-04-23 14:26:42markksetmessageid: <1398263202.09.0.711529704898.issue20995@psf.upfronthosting.co.za>
2014-04-23 14:26:42markklinkissue20995 messages
2014-04-23 14:26:41markkcreate