Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Paul Vixie Interview

By Pac in Internet
Fri Feb 02, 2001 at 08:57:38 PM EST
Tags: Internet (all tags)

ISC's announcement of a new fee-based, early announcement, BIND security list caused great turmoil around the Internet this week. Kurt Seifried has interviewed Paul Vixie from ISC for Security Portal.

In the interview, Paul Vixie insists that nothing old will be suppressed, that "CERT will still be ISC's channel for announcing security bugs to the community. Patches will still be accepted from the community, and published to the community."

The article also includes comments from many parties, including Vincent Danen from MandrakeSoft and Theo de Raadt from the OpenBSD project.

Almost no one seems to agree with ISC's plans. The most important security mailing lists are really angry. At Bugtraq, given the huge number of irate posts, the moderators chose to post just a digest with the best comments. A couple of them made it into the article.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o ISC's announcement
o interviewe d
o Security Portal
o Also by Pac

Display: Sort:
Paul Vixie Interview | 15 comments (7 topical, 8 editorial, 0 hidden)
Time! I need more Time! (4.00 / 2) (#2)
by Anonymous 242 on Fri Feb 02, 2001 at 04:20:28 PM EST

Situations like this really bring out the rebel streak in me. If I had the time (and the skill, which is questionable) I'd start work on forking BIND. I don't have the time (and as I mentioned, it is questionable whether or not I have the skill).

I can understand Mr. Vixie's reasoning. It even makes some matter of sense to me. It also pisses me off to no end. The decision just seems openly atagonistic. Mr. Vixie does have every right to do this. It's BSD-style licensed code. It might even make good business sense for Mr. Vixie's company. However, I don't know that it makes sense for the rest of the internet community to support Mr. Vixie's decision.

seconded (none / 0) (#10)
by h2odragon on Fri Feb 02, 2001 at 09:47:40 PM EST

let's pull named from the BIND4 dsitribution, clean it up (not fun, but possible); and at least have one other option...

[ Parent ]
OpenBIND (none / 0) (#11)
by starlitz on Fri Feb 02, 2001 at 11:48:10 PM EST

Looks like the OpenBSD team have had the same idea. (At least Todd Fries...) A whois on openbind.org shows that he registered the domain yesterday. Then I'll be able to run OpenBIND on OpenBSD and administrate with OpenSSH, and that is a Good Thing(tm), IMO.

[ Parent ]

OpenOpen (none / 0) (#15)
by Minuit on Tue Feb 06, 2001 at 04:23:28 PM EST

Then I'll be able to run OpenBIND on OpenBSD and administrate with OpenSSH, and that is a Good Thing(tm), IMO.

Or you could use OpenSSH to OpenAdministrate OpenBIND on OpenBSD, which is an OpenGood OpenThing (OpenTM), IMOO.

It might even be DoublePlusOpenGood.

If Microsoft slapped their logo on it and included it in Windows, it would be an OpenInnovation.

If OpenBSD were to go fork itself, it would be called OpenOpenBSD.

See? The prefix 'Open' makes everything better.

(Disclaimer for the too-much-coffee-humour-impaired: It does, too.)

If you were my .sig, you would be home by now.
[ Parent ]

FreeBSD Response (2.83 / 6) (#7)
by Miniluv on Fri Feb 02, 2001 at 04:52:09 PM EST

While I'm not a member of the FreeBSD team, Robert N M Watson of the Core Team and the TrustedBSD project posted what I consider to be a highly insightful and interesting email to BugTraq in response to Mr Vixie's ongoing commentary on that list.

"<pre>"While I'm not strictly opposed to the idea of a vendors-only notification list for BIND bugs from ISC, there are a number of things that have to be kept in mind: 1) People can and do follow commit mailing lists. ISC/Nominum's commit mailing list may be private, but the commit lists for the *BSD projects are all public. It has been demonstrated on a number of occasions that people do actually read the commit lists, read the diffs, and that they aren't stupid. When security fixes are committed to the FreeBSD source tree and our advisory is delayed for whatever reason, e-mails start popping up on the FreeBSD security-officer mailing list saying, ``Are you going to release an advisory for this?'' ``This is a serious problem and if you don't release an advisory, we will'' ``Is this being covered up?''. We do try to coordinate the patching of bugs in our tree with the release of advisories, but a fundamental problem here has to do with the QA of the fix: CVS is how we serialize changes to the tree, as well as distribute the changes among developers. If we want wider testing in the developer community, it needs to be through CVS so that we have a "final" integration of the patch against a fixed version of the source tree. And as soon as it's committed, the world knows. Part of the goal of an open source and open development project is transparency -- most of the time, this is a benefit. 2) Getting fixes from the Vendor in advance of the release is very difficult. We delayed the release of our advisory because the "official" fix for the bug was BIND 8.2.3-RELEASE. It takes us several days to properly integrate a new vendor release into our tree on three code branches (5.0-CURRENT, 4.2-STABLE, 3.5-STABLE), develop and test updates against release versions, and do proper QA and testing. Releasing a broken fix helps no one: testing must occur first. Unlike what was claimed in an earlier e-mail, we had almost a month's advance notice of the vulnerability through CERT. We just didn't have the fix; we were asked to avoid disclosing the bug early, and it was clear to us that committing an advance fix prior to integrating 8.2.3-RELEASE would be about as plain to the concerned community as an advisory. We hoped that ISC/Nominum would release BIND 8.2.3-RELEASE in advance of notifying of the security problems in it, so that we would have time to integrate and test before the advisory. Instead 8.2.3-RELEASE went out the door on Jan 26, on a Friday late at night, and advisories begain popping up on Monday. Of course, the reality is that people diff releases to find security holes, as described in (1), so perhaps early access to the release doesn't work either. Trying to avoid releasing on a Friday would be a good thing, and has been discussed a number of times on bugtraq before. 3) The bind-members group sounds like it is really targetted at closed source systems: the reality of open source development is that it's done by large teams of people, that work is done by the first person who gets to it, resources for travel are relatively scarce, and that the people cooperating on open source software often don't have any binding contractual relationship. Requiring the signing of NDA's and the idea that in-person meetings be an important components of the organization will substantially hamper the participation of open source groups in the process. We discussed this to some extent internally in the FreeBSD Project, and came up with a list of no less than 8 people who would need to participate, based on the distributed nature of the security-officer list, maintainers of the BIND code in our tree, etc. And there isn't an "umbrella" organizationt that can sign the NDA and then delegate tasks internally. Also, the NDA may be quite incompatible with the nature of commit mailing lists, discussed above, which play a vital role in open source projects that use them. 4) As has been brought up, the NDA may present problems from other perspectives also: if it is known that a security vulnerability is being widely exploited, the "strong NDA" needs to take into account the desire for early release rather than delayed and coordinated release. If there is an NDA, it must come with a commitment that release of information and fixes can be done in a timely manner, not after a 30 day delay, during which time hundreds of thousands of machines are vulnerable. Having the root server operators in on the list is an interesting twist however, that may help: must vendor vulnerability mailing lists don't contain independent users of the products. Vendors want, and need, advance notification of bugs so they can best serve the users of their system. Doing this advance notification in a structured manner is also necessary, to allow all interested vendors to get notification, and to organize the advisory process to minimize risk to the users of various systems. A failure to organize the advisory process does a disservice to users of open source and closed source software, but it's necessary to keep in mind the development models used in open source software, and how they are not necessarily compatible with delayed advisories, NDA's for developers, and timed release. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services "</pre>" I think that's one of the best summations of the problem I've yet seen. While he doesn't have anymore answers than the rest of us, it's useful to see the problem defined so elegantly. Also of note, OpenBind.net and .org have both been registered in the last couple days, so perhaps there is an active interest in a fork.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

Only one? (4.00 / 1) (#8)
by kcarnold on Fri Feb 02, 2001 at 05:39:26 PM EST

For internet services, more is generally better (to a point, of course). There's only one BIND, and though there are a few alternatives, none of them have really taken hold. Though I have not researched thoroughly to see what is available, several people have mentioned djb-dns but found serious problems with its licensing, and I have not used any of the other alternatives to see if they are any good. Situations like this with BIND being the primary DNS server emphasize the importance of not having a single program, open or not, dominating the playing field from a security standpoint. If there is a problem with that server (BIND definately has had its share), even if it's only making a DoS slightly easier, the Internet as we know it could easily be taken down by the script-kiddies, given the time and effort to come up with an exploit and run it. Thank goodness there are multiple active versions of BIND, decently-frequent updating, and that the kiddies have been less active than they could be; otherwise a good deal of the core domain name services would have been compromised by the latest vulnerability or even one from a while back. Due to the importance of the DNS system in the Internet infrastructure, compromising a high-level DNS server can have disasterous consequences, service outages being the least of the problems.

This brings me to what I think really needs saying here: we need (open) alternatives to ISC BIND. A quick check on Freshmeat reveals a very satisfying answer. Grep through that page for "server". Try one. If it's good / cool, this is the perfect place to say so. I'm planning on trying a few of the alternatives on my own little server, and I'll report back here which I like. I encourage any sysadmins among you to do the same, and any good programmers here with a spare moment or two to contribute to one. With more than one server, the likeleyhood that a single vulnerability could affect all of them is greatly reduced, assuming that they are indeed different code. So let's give the kiddies a (little bit of a) hard time, where possible.

seemple solution (4.00 / 2) (#9)
by Arkady on Fri Feb 02, 2001 at 05:58:12 PM EST

All we need to do is set up a mail alias that posts to both BugTraq and to the BIND bug reports address and publicize that folks publishing security bugs should send them there rather than to ISC.

That way, they're published publicly _first_ before ISC even sees them on their little private playground list.

It's not even an issue worth forking BIND; it's just a matter of publishing publicly before submitting reports to ISC. If folks do that, ISC will change their tune quickly enough, since they won't even have a chance to evaluate and decide on a response to bugs before the public knows about them. This would put them at a major competitive disadvantage against other DNS servers.

If Vixie and ISC know what's good for BIND, he'll retract this.


Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.

Paul Vixie Interview | 15 comments (7 topical, 8 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!