JdeBP> <URL:
http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html>
KP> Note that the flaws in these initial attempts were quickly
KP> identified [...]
They were by me, certainly. I had the web page up detailing the
flaws that same day. They weren't by a lot of other people, though,
and still aren't by some.
KP> [...] ISC's official patch to BIND is a bit more intelligent.
Not really. ISC's patch doesn't fix the problem, either. I
analysed it yesterday and found a flaw that allows Verisign to
specifically target those users of the "delegation-only" mechanism
with denials of service, should it wish to. I decided to write up
the flaw for "comp.protocols.dns.bind" before writing it up for the
web page. I wrote it up for "comp.protocols.dns.bind" yesterday,
and I'm writing it up for the web page today.
KP> We can then move forward and adopt the wrung-out solution.
The wrung-out solution is, ironically, the first one that most
people thought of: Revoking Verisign's authority. This is an
administrative problem with a talking-to-human-beings fix, not a
technical problem with a software fix. Someone to whom we have
delegated authority has breached our trust. Our remedy is to
revoke (or, at least, to threaten to revoke) that authority.
Alas! All of the flawed software patches and worthless petitions
appear to be distracting people from doing what they really should
be doing, which is contacting the root server organizations and
telling them to contact Verisign and tell it to revert to toeing the
line again (with the threat that they will stop delegating authority
for "com." and "net." to it if it doesn't), threatening to stop
delegating our authority to the root server organizations themselves
if they don't do this. (As I've said elsewhere, Microsoft, as a DNS
server software vendor, can swing considerable weight in this area,
given that many users of its software unquestioningly accept its
recommendation of root server organization.)