Wouter Verhelst <wou...@debian.org> writes: > On 16-05-13 17:42, Russ Allbery wrote:
>> You could, in theory, switch to DNSSEC, but now you're just replacing >> one CA cartel with another. > Except that with DNSSEC (and DANE), the number of people you have to > trust is much smaller. Right, it depends on what your risk model is. If you're defending against incompetence and/or commercial greed overriding security practices, DNSSEC looks a lot more appealing than the CA cartel, since there isn't the same level of commercial incentive to cut corners and do a crappy job (there's some, but it's not as bad). But if you're defending against governments, DNSSEC isn't going to help. I think it's best to assume that both the US and Chinese governments, at least, can make DNSSEC say what they want it to if they ever needed to. The government risk case may not be of interest, and it is, in general, quite difficult to defend against governments (usually the best that you can hope for is knowledge you've been compromised, and even that is fairly difficult even in the US with National Security Letters). The problem with authentication systems, though, is like the problem with cryptosystems: vulnerabilities never get better. They only get worse. So there's some reluctance within the field to adopt a new authentication system with known attack vulnerabilities even if one thinks one can live with the current vulnerability. It usually means that vulnerability is going to get worse over time. The basic problem is that you have to trust someone, and all the parties involved in the authentication transaction (which includes the metadata host in the WebID model) have to agree on who they're going to trust. Obviously, the simplest scenario (and the one used essentially exclusively within large institutions) is for all parties to agree on a trusted central authentication authority such as, for example, an internal CA run according to known practices. The whole point of distributed authentication is to eliminate that single point of central authority, but as a result the trust problem becomes almost intractably difficult. The most secure distributed authentication trust system is for every party to maintain explicit whitelists of who they trust based on personal information and their own policies (think GnuPG signature trust, for example). It's also by far the most difficult to maintain and has significant interoperability issues. So, again, it comes down to what problem we're trying to solve. If the problem is just how do we authenticate Debian contributors to Debian systems, then we're actually in the institutional case and we don't have to trust anyone outside the project: we can deploy our own central authentication system -- a CA, a Kerberos KDC, or any other authentication system of choice -- and have all parties trust it, and that will be much simpler and much easier to analyze than any of the distributed models. Once we have our own CA, we could of course do secure WebID if we wanted to using that CA (modulo the inherent dubiousness of substituting endpoint authentication for user authentication), but it's not clear to me why we'd bother as opposed to just issuing client X.509 certificates with the metadata already included. -- 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: http://lists.debian.org/87li7ekhjh....@windlord.stanford.edu
