Donald Stufft added the comment:

> I don't think "remove de-recommended cypher" qualifies as a security fix for 
> 3.3 or 3.4.  Certainly you're not permitted to add ChaCha20 to 3.3 or 3.4

I think that this is a bad stance to take here. The difference between a 
security feature and a security fix is incredibly hard to differentiate. For 
instance, with 3DES being de-recommended (and removed in future OpenSSLs) that 
leaves basically only AES-GCM and AES-CBC left as a secure cipher. This is a 
very precarious position to be in because all it takes is some reason that 
these constructions are less secure (it doesn't even have to be an attack on 
AES itself, could just be the way TLS uses it) and suddenly 3.3 and 3.4 don't 
have *any* secure ciphers. It is important from a security standpoint to have 
multiple secure ciphers available with different implementation details to 
protect against problems in one of them from causing widespread harm.

As far as removing 3DES, I think that we need to either remove it or we need to 
implement protections to prevent it from being used for too much data. 3DES 
isn't insecure so much as it's so old that you can only safely encrypt so much 
data with it with a single TLS key (Key == Connection roughly) before it 
becomes insecure. This is likely to hit automated tooling worse because it only 
affects things that hold long lived connections or re-use TLS session keys for 
a long period of time and a lot of tooling does just that for performance 
reasons.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27850>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to