>My real concern with an approach such as you describe (which has been >suggested before) is that it would end up being blindly deployed in >situations where it is _not_ safe, which I suspect is a lot of them, and it >would encourage people to rely on "easier" insecure configurations even >when they have the ability to make it work right.
I thought one problem we were discussing was that people quite frequently _dont_ have the ability to make it work right; look at Adam's situation, which is not that uncommon at all (I've run into a bunch of similar situations myself here at NRL). I'm talking about making it work today, with the tools that we have ... not about pie-in-the-sky technologies like DNSSEC or Kerberos referrals (I know that in some form, both of these things exist today ... but let's be realistic, a LOT of serious engineering work needs to take place before aklog could make use of either one, and telling people to suck it up and wait for these technologies is simply counterproductive). I will certainly use either one of these when they become available and I'll be glad to do so, but I just can't wait around for them to happen because if I did, I'd be out of a job. If the current situation was "safe", for some value of "safe", then maybe I could agree with your argument. But we have people today deploying insecure configurations! At least people like Adam could get work done, and they wouldn't be any worse off from a security standpoint. I'd debate how "insecure" these configurations really are ... in my mind the security risk from using AFSDB records is really low compared to the hundreds of other vulnerabilities we face on a daily basis. If using AFSDB records frees up my valuable time so I can combat other, more pressing vulnerabilities, I guess I consider that a win. Obviously not everyone agrees with me. --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
