User: tqbf

Hats off to eEye

On: Remote 'Root' Exploit in IIS 5.0

eEye takes an incredible amount of shit from the White Hat "elite" --- the same people, like Marcus Ranum and Bruce Schneier, who villify the researchers at eEye have a noticeably softer take on Mudge and The L0pht. The difference between the two? The L0pht's non-research hacker involvement and a lot of trendy Boston VC money.

Of course, I'd be pretty upset too if a bunch of upstarts were singlehandedly obsoleting my practices and methodologies, like eEye (and groups like them) has done with "traditional" security consulting and management. I just hope all you people are watching now and paying attention to the contributions the security community gets from eEye's critics.

A published root hole in IIS is a coup for open source (when was the last "Administrator" break from Apache?). The disseminated fix will be a coup for full disclosure. Everybody wins. Except the dinosaurs.

THIRTEEN! MILLION! DOLLARS!

On: On the Subject of Ximian and Eazel

They would have gotten a better return on their money if they had simply spent their entire time convincing Microsoft to port IE to Linux, rather than building Nautilus.

Re:IP6 is still a long way away

On: A New Approach to IP Address Exhaustion

Cisco desperately wants to deploy IPv6, for the same reason every year for the past few years has been "the year multicast will happen" at Cisco. Cisco's core technology has been commoditized. If the core of the network changes dramatically, Cisco gets to leverage a huge mass of expertise and reputation to get a new handhold on the market. If it stays the way it is now, Cisco competes on raw performance against competitors who are just as capable as they are.

Unfortunately for Cisco, ISPs don't particularly want to deploy IPv6. It doesn't make them more money. Gadget internetworking (http://www.yourwaffleiron.com) hasn't happened yet, and when it does, there's no reason why it can't be made to fit into the 32 bit space we already use. Security has already been addressed by opportunistic IKE/ISAKMP/IPSEC, SSL, and SSH.

In a network that already aggressively uses NAT, private addressing, and overlays, what does extra address space really buy us?

Nonscaleable routing table growth!

Personally, as a low-level network application developer, I'm in no hurry to see IPv6 deployment. I generally have a problem with the way infrastructure developers have pushed more and more problems into the core of the network. This is contrary to the end-to-end argument that the Internet is based on. The more we do in applications, the more flexibility we gain.

The fact that you can't run "Icecast" servers has nothing to do with addressing. Streaming audio distribution over the Internet is a debacle right now. What you're really asking for is multicast, and that's coming around the bend (only riding ON TOP OF IP, not inside of it!). When widespread overlay multicast occurs, you'll have access to an efficient distribution channel without the need to run a "server" that people "connect to" to get audio.

And how on earth do you overlook dynamic DNS in all of this? If the problem is resource location, what is an IP address buying you? DNS already provides enough information to resolve rendesvouz problems. If you are stuck behind NAT, relay/rendesvouz architectures already exist to turn your "clientside" connection into a server feed.

I think this desire to deploy IPv6 is just knee-jerk religious bigotry from people who don't understand the problem.

Same idea, cooler projects:

On: A New Approach to IP Address Exhaustion

David Cheriton has a research group working on this problem at Stanford DSG --- "TRIAD", a DNS- based overlay that integrates the DNS query round-trip with the transport handshake round-trip and ties resource location to request routing.

Robert Morris has a group working on overlay networks as an alternative to basic Internet path selection --- RON. They are concentrating on overlays as a means of allowing intelligent or policy-based routing decisions on a small scale effect decisions on the large-scale Internet.

Of course, multicast is only going to happen via overlay networks. There are many groups building scaleable overlay networks for content and data delivery today. I'd go so far as to say that multicast semantics are going to drive adoption for routed overlay technology, which will then be used to bridge NAT domains later on.

A valid question to ask in response to this article, though, is "what address exhaustion"? Does anyone have real, valid numbers + methodology for address depletion on the post-NAT Internet?

It's not meaningless, just very old...

On: Security Hole In TCP

This problem is old. Even in the context of Cisco routers. Mudge@L0pht testified about basically this exact problem in front of congress a few years ago, and even then it was old hat.

But that doesn't mean it's not threatening. On the contrary, it's important to point out that TCP connection resilience is critical to the Internet infrastructure. TCP connections carry the BGP4 inter-ISP peering traffic that routes the backbone.

By and large, there's not a whole lot of meaningful things you can do with TCP spoofing (even RSTs) on a clueful network. But there are infrastructure protocols that rely on TCP and major havoc to be caused if they're disrupted.

There's been an unofficial understanding that router TCP stacks are not very robust. If ingress filtering isn't set up correctly, you can use flaws like this to disrupt peering sessions between routers. This is terrible. But Guardent could stand to be less hand-wavy and more forthcoming about their analyses.

I think Bruce Perens could stand to be a little less glib, and pay a little closer attention. This appears to be valid research, blown out of context by PR. It happens, it sucks, but we shouldn't add to the problem by using the bad PR to obscure the threat.

Re:Why is this any different than IDS Systems

On: DDoS Detection Devices

I like the Arbor Networks approach. These are smart people and their approaches to the problem are largely statistical. They can legitimately claim to have a solution with very minimal privacy implications.

The overwhelming majority of network intrusion detection solutions cannot make these claims. They are misuse-detectors --- IDS parlance for systems that do deep analysis of traffic looking for known signatures of misuse. The techniques for detecting these signatures are in fact more intrusive than those for detecting keywords in mail messages. Some IDS tools go so far as to ADVERTISE their utility for monitoring employees and copying email.

The fact that misuse-detectors don't even work (against savvy attackers) doesn't improve the situation (Tim Newsham and I wrote a well-known paper on this, you can find it at Vern Paxson's mirror). The only interesting work in intrusion detection and response is being done at the backbone level, in macro-analysis, using statistical profiling and anomaly detection.

Arbor Networks appears to be leading the pack on the analysis end. There are other interesting companies in this space too --- Asta Networks (tech lead by the inimitable Stefan Savage) appears to be doing direct traceback, and Mazu Networks (the Click Router group from PDOS@MIT, more insanely smart people) appear to be doing edge-based detection and filtering.

Traceback, backbone traffic analysis, and edge-based IP-level traffic/misuse detection are going to be the deployed solution for this problem. Get used to it. Network admins have had many of these capabilities for ages --- these startups are just focussing and optimizing them. You should be more afraid of ISPs deploying RealSecure or NetRanger (privacy-violating point-product misuse systems) than about them guarding their networks with traffic analysis information they could get from their routers already.

PS: Note to Linux geeks --- many of these companies, particularly Mazu, are doing large-scale in-kernel traffic monitoring. They are publishing their code (and some of it, like the Click router, is amazing) and making a HUGE PR contribution to the usefulness of the operating system.

Who cares?

On: BIND Security Info For "Members Only"?

There's an obvious response to this statement.

If people like Vixie and his Nominum (BIND, Inc.) cronies were the ones FINDING the security flaws, instead of INTRODUCING them into the Internet infrastructure, maybe we'd have cause for alarm. After all, they'd be in an position to make yet another buck off the rest of the 'net --- this time in return for an "assurance" of protection against security flaws. Fuggedaboudit.

The dirty little "secret" of the war between "script kiddies" and "security kiddies"---err, "white hats", is that the script kiddies who matter are getting the information first. Often, this is because they FIND it first. It doesn't matter if the "white hats" form yet another clique (anyone remember CORE?) and pat themselves on the back about how "clued in" they are.

They're still going to find out about these problems when everyone else does. On Bugtraq.

And Amen to that. The solution to this problem is not for bad software developers to bully users into using broken software. The solution is for clueful network operators to see the little guys behind the curtains for what they are, and replace their shoddy 80s-era software with proven, robust replacements.

I repeat this observation ad nauseam on Slashdot. Here it is again:

The same issues we're seeing here took place over the Internet mail infrastructure a few years ago. The solution was a secure mail server design proposed and implemented by Dan Bernstein, called qmail (reincarnated in Venema's qmail clone, Postfix).

How many clueful admins do you know that still run Sendmail?

How many clueful admins do you think will run BIND in 2002?

Such Old "News"

On: Patrolling Networks For Insecurities

We really need to be able to moderate story headlines. This is far beyond old news, and even when it WAS news, it wasn't interesting news.

EMERALD is not an evil government plot, nor is it interesting new technology that will change anyone's life. It's simply another research intrusion detection system, and it's been around for years. The people working on it are smart (I met and talked to Philip Porras at a Common Intrusion Detection Format meeting), but the project itself is less far-reaching than any of the commercial systems already on the market.

EMERALD is interesting primarily as a framework for building intrusion detection systems. It's component-based and designed to allow different "event generators" to be combined for analysis. This is a goal of a large number of research projects. The reason EMERALD comes up alot is that it has a relatively well-defined and powerful rule-based analysis engine to process events.

This framework differs from commercial systems like ISS RealSecure in that the sensors, which collect information from the network (or logs, or whatever) don't do the bulk of the analysis work. Unlike RealSecure, in which the raw network sniffing code is also responsible for knowing about almost every vulnerability the system detects, EMERALD allows the sniffer system to forward low-level "events" to an analysis engine that can detect attacks.

The two basic advantages to this approach is that you can more scaleably detect simple attacks and you can detect a wider range of intrusion scenarios. The system scales better because it splits the load of event generation (sniffing) and analysis (attack detection) into two components, instead of coupling them into one component like RealSecure. The system can detect more interesting attacks because it offloads analysis into a rule-based engine (basically, an "intrusion detection programming language"), so it can flexibly do things like statefully correlate different events from different event generators.

This is all nice and good, but the fact is that EMERALD is (at least, until recently) a research project with very little real-world usage. It's a nicer architecture than RealSecure, but in terms of real-world impact, RealSecure is more important; RealSecure has a fairly mature "sniffing" engine, a large database of attack signatures, and an interface that makes it easy for network operators to violate your privacy.

Anyone (the NSA, your ISP, your mother) can buy RealSecure if they have the cash. It's been available for years and years. You can deploy a RealSecure system to do everything EMERALD can currently do. And most of the interesting new capabilities EMERALD promise IMPROVE the privacy aspects of the system. You can't get a whole lot more intrusive than the "snoop every packet" semantics RealSecure already has.

So, what's the news here?

Re:Yes, it doesn't scale; we know that.

On: Gnutella Not Scaling?

The problem with centralization is that it creates a target (legal, technical). This is one of the core bulletpoints Gnutella has --- its "distributed" nature makes it harder to regulate.

The trouble Gnutella is going to have as it attempts to scale beyond community applications to infrastructure applications (like using the Gnutella community as a search engine for the web) is that large-scale apps won't work across the Gnutella peer-to-peer fabric. They will need to be "directed" by a "persistant" server network of some sorts.

Building a server-based distributed database isn't trivial, but it is (IMO) a "solved problem". The hard, unsolved problem Gnutella has is trying to self-organize into something approximating an efficient server-based network.

I think this is somewhat silly. I think that if Gnutella can solve that problem, there are more interesting applications for it than Search.

I think a more realistic angle for the Gnutella supporters to take is to bifurcate: the distributed, amorphous network is valuable when there are lots of them --- it's very hard to censor. Gnutella needs a directory system (ala Shoutcast's system) to locate these groups. The distributed search system is also valuable, but has different requirements.

Either problem is realistically solveable in the near term. Solving both of them simultaneously is much harder.

Sendmail IS more secure than Postfix?!

On: Bind 9.0.0 Final Released

This is a ludicrous point. In the years since you had that experience, there have probably been more than 20 exploitable holes in Sendmail published. In the years since qmail was released, not one hole has been published. not one.

Of several thousand sites at DISA, not one was hacked because of Postfix or qmail. not one. Are you willing to strain your credibility by saying that not one host was hacked because of Sendmail?

You are providing very weak anecdotal evidence about the security of Sendmail. I can provide very strong, verifiable, factual evidence about its inferiority to qmail or Postfix, including:

Sendmail's prodigious root-hole history

Sendmail's monolithic design, which conflates things like queueing logic, parsing, outbound SMTP, and MDA functionality into a single process

Sendmail's default-config reliance on root

Competant security professionals do not rely on Sendmail.

DNS Standardization

On: Bind 9.0.0 Final Released

The problem with djbdns is that Dan doesn't care about standards

Learn what "standardization" means, and how to read and interpret an RFC. You're talking out of your ass.

AXFR has been "optional" in BIND for years --- BIND's configuration allows them to be restricted by IP address, and competant admins have been restricting them with filters long before that feature was available. djbdns does exactly the same thing, but takes it a step further by running AXFR service from a seperate server context, for added security, speed, and reliability. This violates no aspect of the standard.

IXFR is not a "DNS Standard". All RFCs are not standards. Many RFCs are proposed extensions to the standards, which is exactly what IXFR is. djbdns doesn't support IXFR because IXFR isn't required by the standards and, thankfully, isn't in widespread use.

Bernstein's take is that secure rsync IS in widespread use, is a general-purpose, modern tool, and is more available to the DNS operations community (even the BIND advocates) than IXFR is. I think it's clear that many of the supposed "standards" being tossed about in this debate are nothing more than features of BIND being wrangled into standards documents. Welcome to OSI, circa 2000AD.

Having addressed your straw-man argument over AXFR/IXFR, why don't we move on to ACTUAL standards compliance? BIND up to and including 8.1.2 applied DNS compression to SRV records, blatantly violating the most basic aspect of the DNS standards (the on-the-wire encoding of actual DNS records).

You're also completely wrong about the ability to do zone transfers with secure rsync and BIND. People already do this. Where'd you get your information from?

djbdns uses TCP queries when necessary, automatically. Can you come up with an actual interoperability problem djbdns has caused? What you're saying sounds *exactly* like what the Sendmail drones said when qmail was released.

I don't expect everyone on Slashdot to understand how the IETF works and what the forces are that bear on it, but I do expect that everyone here is familiar with the term "loose consensus and working code". djbdns works. BIND has been a disaster for years. If you're going to deify the IETF in your arguments, try to understand its spirit first.

Re:Security guarantee is limited

On: Bind 9.0.0 Final Released

I would guess that Vixie has had, until recently, no realistic alternative. Vixie also has a very
definite financial interest in pushing BIND and
BIND-features-masked-as-DNS-standards. Vixie is
an officer of Nominum, "the BIND company", a commercial enterprise devoted to BIND in the same
manner as Sendmail, Inc. is devoted to Sendmail.

Some of the largest sites in the world still depend on Sendmail, too. But would you run Sendmail in your infrastructure? Most people wouldn't, opting instead for Postfix or qmail,
both of which have proven themselves in large
sites as well.

Broken Analysis

On: Bind 9.0.0 Final Released

So much is being made of DJB's dislike for AXFR that I think it's important to note the fact that djbdns DOES SUPPORT AXFR, directly.

You do not need to use AXFR for zone transfers with other BIND servers. The only time you will ever need to support AXFR is if you have customers or providers that refuse to support sane protocols, like secure rsync. Synchronizing BIND servers with rsync is no more challenging than synchronizing tinydns servers.

Additionally, if you are making the mistake of using or relying on BIND anywhere in your infrastructure, reloading the zone files will give you an opportunity to free up all the memory that the infinitely-expanding BIND "cache" consumes.

You should very carefully read and consider DJB's analysis of whether you want offsite secondary DNS support before you rely on anyone else's nameservers. Most people DON'T want offsite secondaries, even if they think they do.

If you do need offsite secondaries, you should very carefully consider whether you want to rely on providers that rely on insecure, unreliable, antiquated software.

Open-Source Apprenticeship

On: Techies Saying No To College

This debate bring out more equivocation from people than any others I see. The majority of the participants here are in or have been to University. I don't think any of them want to admit a simple fact that closes the discussion:

If you're career-oriented, and you're sure you want to be in software or systems/network engineering, a CS degree is worth less than industry experience.

Obviously, if you're unsure of where you want to be in 10 years, or if you're not motivated enough to take the initiative in building a career, college-at-18 is a good idea. But everyone here knows that CS is not trade school. The knowledge you need to compete in the IT/development workforce is obtained by doing, not by reading. I'm sure even the staunchest advocates of college education have horror stories about clueless CS grads starting jobs full of a sense of entitlement but completely bereft of any practical competance.

The word I hear most when talking about the way practical computer education SHOULD be is "apprenticeship". And we're fortunate to be at a point where meaningful (if informal) apprenticeship is available to everyone. Development and deployment projects of every level are open to participation in the form of open source projects.

If you're planning on becoming a software developer, contributing to a well-run open source project is a much better use of your time than theory classes. A solid 4-year history of real contributions to well-known projects looks much better on a resume than 4 years of undergrad schooling. It also costs less, and is more productive than undergraduate CS.

Speaking as someone who has been responsible for hiring people in the Valley for the past 3 years, I can confidently assert that the naysayers who claim employers will frown on a resume without a degree are completely full of it. The few exceptions I can think of (hardware engineering and research positions) so obviously require schooling (from a practical perspective) that they aren't worth debating. In the technology workforce, it's a sellers market. No serious employer has the luxury of waiting for a "traditional" candidate with a degree --- there are 10 companies competing for every job hunter now.

Even if the bottom drops out of the technology market in 5 years, a few years of industry experience is clearly more valuable to a resume than a degree. The market today is a huge opportunity for tech workers. It's silly to ignore that.

Is this as simple as it sounds?

On: What Happens When Patents Meet Antipatents?

Speaking as someone who has been involved in the filing of a patent, I'm not sure a simple "idea registrar" is going to be a potent weapon against patents.

Patents aren't "ideas". They are descriptions of (for instance) "a novel system and method" for performing some task. So you can't just go and register on a web page that you thought up "an RSA-strength public key system with 10 byte keys" --- you have to actually document the facts behind the invention.

Basically, just as in the patent system, in order to register a meaningful antipatent, you need to publish a "best known mode of invention". As in the patent system, the "best known mode" has to be enough information for anyone competant in the field of the invention to reimplement it. This ratchets up the effort involved in "registering" an antipatent significantly.

The problem here is that it takes a similar amount of time to "file an antipatent" as it does to write a journal article or release a piece of open-source software. Either of those alternatives ALSO generate meaningful prior art, and they are also more useful to the community than an antipatent.

I think FreshMeat is a much more interesting weapon against patents, because they basically document published inventions in near-real-time. A much better idea than creating some new "antipatent registrar" would be taking the steps required to give FreshMeat filings legal credibility (a staff of editors "notorizing" registrations, and perhaps even writing "claims" for interesting-looking new software --- this might not even need to be very formal to give the system very sharp teeth).

But none of this solves the real problem. In working with patent attorneys, we discovered that an enormous number of superficial little things we did, like talking on Usenet and IRC, created "disclosures" that jeopardized patents. The problem is that patent agents have piss-poor methodology for finding disclosures of prior art --- they basically search the patent database and perhaps academic journals for obvious matches. Creating a new "antipatent" system doesn't change the USPTO's process. It just brings the inadequacy of their process into clearer relief.

Not That Far-Fetched

On: "Fingerprinting" of Audio Files?

As someone else here said, this is conceptually not much different than calculating a message digest. In fact, I'm sure that's exactly what they are doing (and hopefully with a standard digest function, like SHA or MD5). Obviously, the question is what data they are feeding to the digest function. They obviously aren't feeding raw audio data, because it varies heavily between different codecs and sources. So, clearly, they're doing some kind of analysis. The easiest thing to develop is an algorithm for summarizing raw audio data. This addresses the concerns about encoding MP3s, Vorbis, or whatever --- you simply operate on the decoded results of these files. The goal of summarizing should be to come up with a description of audio data that is the same for two identical-sounding files.

So the question then becomes how you "summarize" raw audio data so that 10 different sources/ decodings of the same piece of audio result in the same summary information.

One pretty obvious thing to do is to select frequencies, set a threshold value (relative to the average amplitudes in the audio data for the frequencies you are analyzing) for "peak" amplitude at those frequencies, and measure time deltas between peaks. You can synchronize different audio samples to a recognizable pattern of peaks to get time synch, and you can measure time in quarter-second chunks to be "fuzzy".

The raw data that you digest would then just be a series of peak-to-peak time deltas for each frequency, which should be consistant between recordings (even if you tack dummy data to the beginning and end of the file --- the latter problem being solved by only accounting for a fixed amount of time in each audio file). Think of it as summarizing/fingerprinting the audio data based on the images displayed in your MP3 player's spectrum analyzer.

I'm not sure if what I've described is practical; it's the first thing I came up with when I was presented with the same problem awhile ago. But it's evidence, I hope, to an important fact:

Anything your ears can do, a computer can do better.

Re:Interesting

On: FreeVeracity: Network Intrusion Detection

At no point has NFR *ever* been open source. Its source code has been made visible, at times, under extremely restrictive licensing terms similar to those used by the Gauntlet firewall. While this is better than keeping the source closed (it allowed me to find and publish a remote root hole in the software, which might otherwise have gone undetected), it's not even close to open source --- I still have to pay to use the software, and I cannot derive from it.

Bruce Perens brought up the same issue, with regards to Gauntlet, in a rebuttal to Elias Levy @ SecurityFocus's article questioning the value of Open Source to security. Perens' point applies just as much to NFR as to Gauntlet: what incentive does the community have to do QA on Marcus Ranum's commercial software?

I realize this is a tangent, but many people have this misconception about NFR.

Why on Earth was this Published on Slashdot?

On: FreeVeracity: Network Intrusion Detection

Rocksoft isn't the first commercial software company to release a "free" version of their software. They're not even the first computer security company to do so. They're not even releasing a particularly interesting tool. And, looking at the license, they're not even open- source.

People in the open-source community work hard to bring tools that are more interesting than "Veracity" to market every day. I don't hear about the most recent release of FreeSWAN here, or the latest news on Nessus. I could probably to go Freshmeat and find several tools that do exactly what Veracity claims to do, too.

Of course, even if that Freshmeat fodder was a 0.0.1a-release written in Perl, it'd be more trustworthy to me than "Rocksoft's" proprietary stuff.

And, incidentally, "Veracity" isn't "network intrusion detection", at least not under the common definition. It's file integrity monitoring, and in this case it's distributed. Rocksoft seems enormously impressed by this fact, advertising their newly allocated TCP port number as if it was an endorsement from IANA.

"FreeVeracity", like this Slashdot article, is nothing more than advertising for a (lame) commercial product.

Far From It.

On: The World's Most Secure OS (?)

I have some respect for the effort that Theo and the auditors have put into reviewing OpenBSD. I was peripherally involved in the project for about a year, and wrote most of their advisories. I also know Theo personally and have great respect for his technical acumen.

However, the notion that OpenBSD is the "most secure OS", or even the "most secure OS in common use", is absurd. Nor is it the most secure OS "out of the box". Rather, it is the leader in out-of-the-box security in a rather narrow set of popular, open-source, Unix-like operating systems.

There have been commercially-available mandatory access control Unix-based operating systems on the market for years. The "trusted" variants of the commercial Unices are great examples. These operating systems get their security from the compartmental design of the system, and are thus largely immune to (unavoidable) trivial programmer errors.

A great microcosm of this same competition exists in the free SMTP MTA's. Modern, secure mail transports are written in a compartmentalized fashion, so that a bug in one subsystem doesn't compromise the whole thing, or worse, the whole OS it runs on. Systems like Venema's Postfix and Dan Bernstein's qmail (which has never had a published security hole) are examples of this design.

Meanwhile, legacy MTA's like Sendmail and Exim remain popular, despite a history of insecurity. Sendmail's authors would happily claim that, after literally decades of audit, it is secure despite a monolithic design. Nobody that takes security seriously buys this argument anymore, though, because effective alternatives exist that are built on a more secure design. So what's the difference between Sendmail and OpenBSD? Well, OpenBSD is orders of magnitude more complex and has had less than 10% of the long-term attention that Sendmail has had.

Calling OpenBSD "secure" in light of competition from Argus Secure Solaris or even wrapper systems like SeOS is not much better pitting Sendmail against qmail.

It's definitely true that in practical terms, OpenBSD is a more trustworthy distribution of free Unix code than Red Hat Linux. However, with very few exceptions, OpenBSD's design remains stagnant and embraces an obviously-inferior security model. Who do you expect to implement compartmentalization and Mandatory Access Control first, OpenBSD or Linux?

My money is not on OpenBSD in the long run.

The mystery here is why people listen to Ranum...

On: Security Through Obscurity A GOOD Thing?

MJR is biased because he is (to my knowledge) the first vendor of a shrink-wrap intrusion detection product to ship/publish a product with a disclosed remote root hole in it. NFR, his network analysis tool, is/was accompanied by a stripped-down web server (ironically, his team wrote this because they thought Apache, the *open source* web server, was insecure!) which had a *stack overflow* in its HTTP GET handler.

No wonder he's not fond of "gray hat arms dealers".

Of course, nothing he is saying is backed up by any real researchers. In cryptography, cryptanalysis is a foundation upon which theory is built. Analyzing and breaking algorithms is the respected, hard task. People like Bruce Schneier repeatedly publish papers disclosing flaws not only in cryptographic algorithms, but in protocols that use them!

MJR's nonsensical position is even more amusing based on the people he consorts with and praises. NFR went through much effort to publically associate themselves with the L0pht --- probably the most well-known active source of full-disclosure security information. He also sticks up for people like Dan Farmer and Weitse Venema, both of whom have published information and tools about new security flaws.

The message here is not that "full disclosure is evil". What Marcus longs for are the olden days of private security mailing lists, where only his friends got information about security flaws. Those were also the days in which literally every piece of software was riddled with stack overflows and the most common way of breaking into remote computers was by mounting public NFS shares.

I understand why MJR doesn't like people outside of his insular little clique publishing and discussing security information. But it would be silly to pretend that anything he says is motivated by a desire to secure the Internet.

Re:Mirror

On: CNET Patents Banner Advertising Networks

Don't post abstracts when discussing patents.
Any patent sounds incredibly evil when evaluated
only from the abstract. You need to post the
CLAIMS of the patent if you want to have any
meaningful discussion of what the patent is about.

Paying for Better Access? How can this be?

On: Excite@Home To Change Routing Priorities For $$

I can't believe that the open spirit of the
Internet has been sullied by this obvious attempt
at crass commercialization. The Internet has
survived for the past 2 decades without charging
any money for access and providing equal levels
of service to everyone based on merit. This
could change all that.

What's next, having Internet access facilitated
by telecommunications carriers that will charge
$13,000 a month for DS3 access that is currently
provided for free?

I am shocked. We should all boycott Excite@Home.

Re:Constitutional Right to Anonymity

On: House To Hold Hearing On Napster

Protection for the right to anonymous
free speech isn't the same as protection
for complete anonymity. That argument
doesn't even make sense --- surely it is
the prerogative of the state to eliminate
anonymity when it is being exploited for
arms trafficking or child pornography.

By the same token, the anonymity desired
by Napster's users isn't the right to make
political commentary without enduring the
intolerance of the majority. Napster's users
desire the right to anonymously violate the
law by ignoring copyright.

I'm sure it's not your intent to give
consititutional credibility to the argument
that Napster users have a right to privacy.
We should be clear that this isn't a free
speech issue.

Re:A few comments on the article

On: Techie Story On TCP Stacks

You are making all of this up.

Re:A few comments on the article

On: Techie Story On TCP Stacks

Could you actually document which providers "blacklist" noncompliant TCP streams, and how they manage to do that? I don't believe you: in backbone routing, it's expensive just to have to look at more than IP addresses, and keeping enough state for a TCP stream to analyze congestion control seems completely unfeasable.

Not to mention the fact that the control mechanism they have ("blacklisting IPs" on the backbone) is trivially exploitable by malicious users to deny service to random Internet sites.

Detection at the "edges" --- at third-tier providers and universities --- seems feasable, but expensive and error prone. Predictive acknowledgement is especially susceptable to false positives, as it involves keeping state between data packets and the ACK responses, AND relying on timing and reliability of packet capture/analysis.

I'm willing to bet that no major carrier is actually profiling TCP traffic to find "greedy" stacks. Can you prove otherwise?