Christoph Anton Mitterer <cales...@scientia.net> writes: > On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:
>> For another example, upstream for both Heimdal and MIT Kerberos know >> very well what the situation is with the RC4 use in the Kerberos >> protocol and are making well-informed decisions based on compatibility >> with existing clients > Okay what does that mean? AFAIU it means: well there are still so many > people with outdated software out there, we can't just disable RC4, even > if it's broken. > I see it a bit differently: > RC4 is broken. Full stop. > Therefore new versions clients and servers should per default not > use/enable/accept it. > Of course Russ is right, that this would cause interoperability > issues,... but IMHO that should be manually decided by the admins/users. > If an kerberos admin says "well I still want/need to provide/trust RC4" > he should manually need to enable in the configs. Same for a > user/client, the other way round. > So I'm not saying that old broken/algos should be thrown out > completely[1] - they should just not come into use without user/admin > intervention. The approach that you are taking to this discussion is destroying my desire and willingness to explain to you all of the nuance that you're ignoring. But, to try anyway: your view of RC4 is simplistic, and is ignoring the fact that Kerberos uses RC4 considerably differently than how SSL does. Many of the SSL attacks on RC4 rely on the properties of HTTPS and the nature of the data being encrypted, whereas Kerberos uses RC4 in a much different mode. There's a lot of discussion in the crypto community about to what extent the same techniques carry over. Disabling RC4 enctypes breaks interoperability with all Windows XP systems. That's clearly going to be the right thing to do soon, and both MIT and Heimdal have future plans to do this, which they're coordinating with support cycles and feedback from large sites. It's unlikely that you're going to be able to make better cost/benefit decisions about these things than well-informed upstreams for general use cases. Debian is targeted for general use cases. If we were making a security-hardened distribution that chooses security over interoperability across the board, we may well want to make other decisions. Security is not an end in and of itself. People want to use their computers to do things, not to just be secure. Security is always a tradeoff. This is inherent in the nature of the work. Different people are going to want to make that tradeoff in different ways. Debian can help push the tradeoffs towards more secure software, but if we go too far and just break things, people are going to re-enable insecure stuff and not trust our defaults in the future. That, in turn, can easily mean that the deployed systems in the wild end up being *less* secure than if we maintain users' trust in the defaults. Debian, as a very large and widely-used distribution, is necessarily going to be more conservative than small and security-focused distributions whose users are much more tolerant of aggressive decisions that break backward compatibility. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3y9aw3p....@hope.eyrie.org
