Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
Christoph Anton Mitterer <calestyo@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: