Slashdot Mirror

D.J. Bernstein makes a case here on the merits of ECC. And his description of a "standard workstation" shows that ECC memory isn't that much more expensive.

This is very different from designing bridges or buildings, for example, where the thousands of decisions going into the design tend to reinforce the basic premise of its fundamnetal soundness. The mathematics of each calculation are usually verified by calculations done during other parts of the work. Due to this feedback, systematic failures are extremely rare, and when they do happen, often end up showcased on History Channel programs such as "Engineering Disasters".

But it is possible to write secure software through good software engineering practices. Unfortunately, not many people seem to understand them. Only a few individuals like Dan Bernstein can consistently and effectively write secure software, and will guarantee that it is secure.

This is very different from designing bridges or buildings, for example, where the thousands of decisions going into the design tend to reinforce the basic premise of its fundamnetal soundness. The mathematics of each calculation are usually verified by calculations done during other parts of the work. Due to this feedback, systematic failures are extremely rare, and when they do happen, often end up showcased on History Channel programs such as "Engineering Disasters".

But it is possible to write secure software through good software engineering practices. Unfortunately, not many people seem to understand them. Only a few individuals like Dan Bernstein can consistently and effectively write secure software, and will guarantee that it is secure.

I'd personally feel a lot less invaded if I knew the system was in place and in this form.

I'll personally continue to encrypt my emails - as many as possible of course.
Routine use of encryption (like for the one-liners) defeats to some extent traffic analysys.

The recent improvements in factoring (look here and here) don't affect 1536- or 2048-bit keys (or larger). For the time being, public-key encryption is the best means of protecting your e-mail privacy. Don't rely on some guys' kindness - with a little effort you can be sure your nosy admin/ parent/ spouse/ street cop won't "accidentally" read your stuff.

http://www.gnupg.org

See DJB's web page about them. The scheme was designed to ward off SYN-flood DoS attacks, which is pretty much what a /.ing amounts to.

Remove one of them. Apparently, Dan Bernstein switches from OpenBSD to FreeBSD. He observed, as can be seen on his cr.yp.to mainpage, a large number of OpenBSD crashes including following:

2002.02.26 ~17:30 GMT through ~19:30 GMT: OpenBSD network stack crash. The load was not heavy (about 20 web downloads per second from slashdot, plus a few mail deliveries per second) and presumably would have been handled without trouble by the FreeBSD network stack.

Looks like as if OpenBSD was /.-ed.

Remove one of them. Apparently, Dan Bernstein switches from OpenBSD to FreeBSD. He observed, as can be seen on his cr.yp.to mainpage, a large number of OpenBSD crashes including following:

2002.02.26 ~17:30 GMT through ~19:30 GMT: OpenBSD network stack crash. The load was not heavy (about 20 web downloads per second from slashdot, plus a few mail deliveries per second) and presumably would have been handled without trouble by the FreeBSD network stack.

Looks like as if OpenBSD was /.-ed.

Not only do I think you're WAY off, but I don't think you read the toaster provided. Your link refers to Cyrus' IMAP server.

From the text:
Reliable: qmail's straight-paper-path philosophy guarantees that a message, once accepted into the system, will never be lost. qmail also optionally supports maildir, a new, super-reliable user mailbox format. Maildirs, unlike mbox files and mh folders, won't be corrupted if the system crashes during delivery. Even better, not only can a user safely read his mail over NFS, but any number of NFS clients can deliver mail to him at the same time.

From that page, the jist is: NFS isn't an issue for Maildir mailboxes.

There is another solution... Invert the Internet mail infrastructure so that email is hosted centrally by senders, and they pay all the inbound bandwidth charges incurred when (if) recipients retrieve the mail.

Dan Bernstein's IM2000 idea is a step in that direction. If everyone used IM2000, normal users would "pay" about the same amount for their outgoing email (unless they were in the habit of spamming their friends with the joke of the week), but spammers would "pay" much more as the flood of retrieval requests came in.

Legitimate bulk mailers would be paying for a more realistic share of the costs of Internet mail infrastructure. ISPs would save money because on the whole, normal users receive more mail than they send.

I've been thinking of implementing it...

Knuth: "Wait, wait - I never said that."

Heh. I think you actually meant Dan Bernstein, or perhaps Theo deRaadt, both of whom are legendary for their humility...

Actually Bernstein says that he does not expect his factoring device to have any significant speed advantage over other factoring techniques for "short" keys, "short" being significantly more than 1024 bits.

The reason is that the speed up is asymptotic with a suspected slow convergence.

But I agree that for security critical application 1024 bits is too short, even if only because there is not enough safety margin.

Find the paper by D.J. Bernstein here.

$OBSCURE_PORT_1 = obscure port # on your local machine
$OBSCURE_PORT_2 = obscure port # on machine outside firewall

On the machine where you have the shell account, download and compile the ucspi-tcp package, and micro_proxy. Put the tcpserver and micro_proxy binaries in your $PATH; throw everything else away.

To run the proxy:

From your local machine,
ssh -C -L $OBSCURE_PORT_1:127.0.0.1:$OBSCURE_PORT_2 -l [username] machine.where.you.have.shell.account.co.va
(or if you use some fancy Windoze SSH client, forward $OBSCURE_PORT_1 on your local machine to $OBSCURE_PORT_2 on the remote machine)

Once logged in, run tcpserver -DHlR 127.0.0.1 $OBSCURE_PORT_2 micro_proxy & on the remote machine

On your local machine, set your browser to use HTTP and HTTPS (IE)/SSL (Mozilla) proxies on host 127.0.0.1, port $OBSCURE_PORT_1

Surf to your heart's content.

Internet Mail 2000

Dan Bernstein has some information about this project on his page. Part of the problem is persuading the entire net to scrap their existing mail infrastructure, something I think is likely to happen soon after the first honest politician gets elected.

over here[cr.yp.to] it's explained what can IM2000 do for solving the spam problem.. or at least to make us live better.

I'm not the right person to explain it here, and djb does it better there. Go check it out..

I think there are a few things amiss with the pfir plan and I'd like to suggest and comment on some alternatives and have a few comments about our continues use of 20th century DNS.

Look back at the creation of ICANN and it's not difficult to see why it has failed. The timeline goes something like this: when the Wired article came out in 1994 where Joshua Quittner reported he registered mcdonalds.com and McDonalds didn't want it he ended up selling it to Burger King. At the time InterNIC registrations were taking about 3 days. This shot up to 11 weeks in a matter of days. The NSF, who funded NSI to run the InterNIC, did not feel it's role, which is to foster academic and scientific advancement, included subsidizing deodorant.com and the like, so, it asked the FNCAC to do something. What they did was instruct the NSF to tell NSI to begin charging for domains. This caught the Internet community rather off guard and discussion ensued on a "newdom" mailing list (whose archives can be found here). Several forces came into play. First was the rift between the group that felt they too could run a TLD and the group that though this should be run from a great big central registry. The latter became the IAHC/CORE thing while the former became the first alternative root. The US Government shut down the IAHC and began it's own proceedings: the white paper was produced. Other governments, most notably in the form of Paul Twoomey from Australia
and Chris Wilkinson from the EU balked at the plan and the revised plan, the green paper took out the language about creating 5 new TLDs immediately (thereby throwing each conflicted group at least one bone). At the time Mikki Barry and Kathy Kleinman suggested in Becky Burr's office that a set of global meetings take place, not to decide answers to tough problems, but to determine just where there was consensus on the various issues. This became the IFWP forum and 3 meetings were held in Reston Va., Geneva, and Singapore. There was to be a followup meeting to merge these consensus points into a framework for the new corporation that was to replace IANA. While this was happening, NSI and IANA were negotiating, and Ira Magaziner, Clinton's senior science advisor and Roger Cochetti, a VP of IBM were running around selecting a new board. The IFWP wrap up meeting never happened, it was scuttled by Mike Roberts (suspicion is high he had been told be would be president) and the vast amount of time and energy, money, hopes and aspirations that was IFWP went down the toilet - which is a real shame as it was a significant body of work. Three proposals went in to the US government to form the new corporation. The IANA/NSI proposal drafted by Joe Sims and NSI, the Boston Working Group proposal (which is where the wrap-up meeting was to have been) which was a sane version of the NSI/ICANN proposal, and the ORSC proposal which was the BWG plan with greater fiscal responsibility and an existing corporate shell. Citing popular public support for the IANA/NSI plan it was selected - but if you read the public comments on the NTIA site carefully you'll see far less support than implied and much of it was tentative, frankly. A board materialized out if thin air, selected because they didn't know anything about DNS. So what went wrong? Was the original ICANN plan flawed or were the people just the wrong choices? I suggest that if Karl Aurbach and 9 people like him has been the original board we would not now be even talking about DNS; the board appointed from in high did not represent the Internet community whatsoever and instead represented telco, government and trademark special interests. It is believed the concessions made so that foreign government supported the "green paper" was that they got to pick certain members of the board. The first big clue there was trouble was when the board missed it's deadline to define a process for their replacement and simply extended their jobs; they should have been gone over two years ago now.

So what have we learned from this? In my opinion, no group that says "we're in charge" really is; respect is earned, not asserted and I think this was the great failing of both IAHC and ICANN. So while I generally like Weinstein, Newman and Farber, I do distrust the IAB to some extent based on previous debacles like the Boston Tea party where they were thrown out for claiming OSI and not TCP/IP was the way to go. The ISOC is another non-starter, it's wanted to get it's hands on the DNS for over a decade and has been a great supporter of the authoritarian regimes of both IAHC and ICANN. The key, I believe, is not some group claiming they should be in charge or that they have all the answers - nobody does - but the good old fashioned and time proven method of Internet collaborative cooperation. And this means actually doing it, not paying lip service to it like ICANN did. Oh and cut out the 5 star hotels and first class Concorde flights.

Is this about Internet governance? No. Absolutely not. In it's most basic form this is nothing more than an institutionalized debate between Dave Crocker and Karl Denninger in 1986 taken to it's logical conclusion. But it's nothing to do with governance of the Internet. Face it, if all you do is read and write email and/or usenet news, and play on ISC or muck about on the web, you may never have heard of ICANN and it certainly has zero effect on you. This is just about new top level domains, period; the IP addresses have virtually all been handed over to the regional registries and the port allocations are handles by somebody than CAN add one to a number and write it down on a piece of paper.

But didn't ICANN break up NSI ? Nope. That was Ira Magaziners plan executed through the Department of Commerce. You don't really think NSI gave in because ICANN though it was a good idea do you? What has ICANN really done in 4 years? They've knuckled under to WIPO and given us the horribly flawed UDRP and 7 really stupid TLDs that despite $2.$M worth of scrutiny still had huge problems to the point of being dragged into court over it.

What alternative roots exist? Quite a few actually, and while on the face of it you might think this would be a problem, but face it, if you can pick up your mail and get to Yahoo! then they work, and any of them will let you do that. The differences in them are what new TLDs they publish in their root zones. I need to disclaim right away that I coordinate, with Brian Reid's help, the ORSC root, and it's generally believed to have the greatest penetration and is certainly the longest continuously operating one. The barrier to entry it low: show us working TLD servers and we'll list you. Other notable ones are the TINC root which is operated by some old time Usenet people such as Peter da Silva which has a policy of one tld per entity, which I don't like think can be made to work (the now defunct eDNS tried this and it was found to be too easily worked around), PacROOT which in my opinion swings too far the other way with their NameSlinger client - I don't think I know the proper number of TLDS any entity should operate but I do know it's not in the hundreds if not thousands; this raises anti-trust issues, and OpenNIC which is pretty good but only has a small number of new TLDs. There is also NameSpace which believes they should run all tlds. This grates against the notion of the root as a collection of independantly run TLDs in my opinion. But, it doesn't matter to me which one people use as long as they use one of them. Vote with your nameservers - it is in nobody's interest to break anything and using any of these roots will let you see all current DNS names and a whole universe of new ones although how many depends on which one you pick.

Why do we still use root servers? Now this is where it gets interesting. What if the US Government suddenly shut off the legacy root servers? 90% of the net would feel some sort of perturbation immediately especially since at least one TLD (.SE) is name-served directly from the root (not TLD!) servers as are many in-addr.arpa delegations. As the TTLs to TLD servers expired, users of the legacy root would not be able to resolve any DNS names. But, people that use other root servers would be immune to the demise of the legacy roots (modulo one of Swedens 7 .SE nameservers of course) but an even better tactic in my opinion is to primary the root zone for yourself. Then, any or all root servers could be shut off and you wouldn't notice a thing. This would leave you with one remaining problem and that is where could you get the root zone from. Your upstream might be a good place or as DJB has suggested, a cryptographically signed root zone could be posted to usenet periodically. This has the inherent advantage of being out of band of TCP/IP; that is, even a UUCP connection could inject the zone into the news stream. That's one answer to "how do you bootstrap DNS without DNS".

Do I think ORSC should be the next ICANN as the ICANNWATCH poll suggests? No and hell no! Nobody should be in charge, and given that the net and the DNS itself is edge controlled - that is, whoever has the root password to a nameserver determines what dns names exist and what don't - any model that asserts a central authority is doomed to fail. There is need for coordination, but not authority.

Vote with your nameserver; vote early and vote often.

Richard Sexton
March 19, 2002

Try looking here: The qmail security guarentee

OpenSSH ends up looking like Qmail with each discrete task running as a separate program under a different user?

There are a lot of things in the DNS protocol that are downright ugly, such as the useless idea of "zones", the allowing of NS referrals without glue records, and the CNAME record. These only make sense when we look at the needs of those that designed DNS. The protocol is designed to make it as difficult as possible to manage DNS records (so that the bureaucrats can feel cozy that they know how to manage zones better than the average system administrator). The fact that MX and NS records point to names instead of IPs reflects the fact that the average DNS bureaucrat was too lazy to run their zone files through a sed script when making changes. The fact that out-of-bailiwick NS records (records without glue) is allowed reflects both the average DNS bureaucrat is too lazy to supply the IP for an out-of-bailiwick record, and that a DNS bureaucrat likes having well defined boundaries of authoritity.

The top down hierarchical structure of DNS also reflects the fact that the bureaucrat likes well-defined authority. The discomfort BIND developers with alternate root servers reflects the bureaucrat's desperate need to cling on to the power that they perceive having.

The fact that some DNS bureaucrats have really silly requirements for someone to have a domain in their bureau shows the kind of power grabs DNS bureaucrats enjoy having.

It comes to no surprise to me that ICANN does not want things like democratic elections; their job is to do things as slowly as possible (doing things any faster would actually take work) while getting as much control and sucking as much money out of the system as possible.

Now, at this point, all I am doing is defining the problem; I do have some ideas bouncing around my head as to what a solution should be; however those ideas still use the top-down hierarchical structure that DNS has. It would be better if there was a way to have the DNS resolution structure be based on rough consensus instead of via a top-down structure; perhaps something that allows indivual DNS servers to send "votes" on who should control a given top-level-domain; if a given set of servers for a given top-level domain get enough "votes", they control the TLD in question.

Then again, a community-controlled system needs protections to not become the diastar that IRC has become; where 14-year old kids struggle to control the channel so they can be a jerk by kicking and banning people at random.

- Sam

I think that it's more important to look at factors like how often the software you are using is updated in response to security flaws and how easy it is for you to replace your software given an update.

Right. And respekt KISS. If you want to securely serve static pages, don't use a full Webserver with CGI and other stuff! Use the simpelest possible! (See e.g. D. J. Bernstein publicfile for such a solution.)

A lot of todays insecurity arises from feature creep and reinventing the wheel.

Blah. Nevermind. This one is way more recent (didn't watch where I was). It still lists it at 3rd, but says
"qmail now accounts for more addresses than Exchange, and almost as many as all Microsoft SMTP products" although I don't understand why it lumped Exchange and IIS SMTP together to make it 2nd.

How are you getting that? This page seems to place it 24th (removing "Unknowns").

And since nobody would use it because of the incompatibility issues, it would be REALLY secure. He could then afford to offer a $1000 bounty to anyone able to 'sploit it. 8-)

qmail is the second most common SMTP server on the internet, so it's hardly fair to say that nobody uses it. He can afford to offer guarantees because there are no security holes.

Maybe CAI didn't want to keep improving the product. DJB's crypto paper and methodology shows that any key less than 1024 can be "easily" cracked. CAI would have had some more work to do on their product (just as I'm sure the GNUPG team is reconsidering the approaches they are using).

Finding the people to verify PGP is secure and proving that any new method of encryption is secure takes money, and since many people still consider zipping a file up with a password as "strong encryption" there was no market for it.

To think, not to long ago the US govt. was complaining that the world would end if we all had encryption. As it turns out, few cared enough to use it.

Actually, the internet would become much more secure. :-)

I must admit to some curiosity at this point. Exactly which university grants a doctorate in computing to someone who doesn't know how the fundamental hypercube algorithms work, doesn't understand the difference between hypercubes and VLSI, and doesn't even understand the difference between a CPU and an FPU?

Let's see if I can boil the news down to something that Mr. Computing DPhil will understand.

The conventional wisdom is that each processor needs, asymptotically, a huge amount of memory for the number-field sieve. The amount of memory grows steadily with the computation time. The cost of the processor is eventually dwarfed by the cost of memory.

(These effects can already be seen to some extent in today's factorizations. You might think that the cost is about evenly balanced between processors and memory; however, the processors are constantly stalled waiting for random access to memory. A much less expensive processor could easily do the same job.)

My paper shows how to get away with, asymptotically, far less memory per processor (and, furthermore, very simple processors), while keeping the computation and communication costs under control.

These are asymptotic results: theorems saying that there is a huge cost improvement for extremely large factorizations. More work is required to figure out the exact cost of the new algorithms for, say, 1536-bit factorizations. It might turn out that the new algorithms are very helpful in practice. It might turn out that the new algorithms are useless in practice. At this point, nobody knows.

You might want to check out this link when deciding the character of the guy stating these opinions. Apparently Bernstein doesn't think very highly of him...

The methods described in the paper can be used to improve the cost of cracking EC discrete logs as well. The author, in a recent Usenet posting, points out that the paper's methods are likely to reduce the cost/effort of EC key cracking as well ... perhaps even more than RSA key factoring.

The paper, combined with other other EC strength concerns suggests that EC is not the technology to turn to at the moment.

In other words, if this paper has you concerned about the security of RSA keys by factoring, then you should be even more concerned about the safety of Elliptic Curves as well.

But as others, including the author, have stated (in large friendly letters): DONT PANIC! It is not known if the ideas expressed in the paper are applicable to key sizes that are in common use.

The methods described in the paper can be used to improve the cost of cracking EC discrete logs as well. The author, in a recent Usenet posting, points out that the paper's methods are likely to reduce the cost/effort of EC key cracking as well ... perhaps even more than RSA key factoring.

The paper, combined with other other EC strength concerns suggests that EC is not the technology to turn to at the moment.

In other words, if this paper has you concerned about the security of RSA keys by factoring, then you should be even more concerned about the safety of Elliptic Curves as well.

But as others, including the author, have stated (in large friendly letters): DONT PANIC! It is not known if the ideas expressed in the paper are applicable to key sizes that are in common use.

Well i couldn't get to the original site, but i see that NEC's citeseer has it.

You could view this post script file online here, or you could use the Windows, OS/2 or Linux viewers available here.

>Step one: Remove the Open Relay from the e-mail server software.

Good Idea. Only I can easily see someone taking some GPL'd mail server and adding open relaying into it again.

>Step two: Consider changing the process of sending/recieving e-mail....

Internet mail 2000. From DJ Berstein's site, creator of qmail.

When I was in charge of handling the spam flood at my previous job, most of the spam originated from the APNIC region. Our sysadmins would periodically go on a hell-ride and block out Taiwan, China, and Korea. We received very few complaints about 5.1.1's, just the occasional grandparent who couldn't get mail from a relative overseas.

I never recieved a response from any of the operators of the relays, save for one that originated from a Chinese government body.

Internet Mail 2000 seems to me to be a nice solution to the spam problem! This way you don't have to download the spam if you get it, and if you do, the spammer (or their ISP) has to be online. This especially solves the problem of spammers that send out mail directly to your ISP/mailserver without using a relaying SMTP-server.

The cool thing is that Internet Mail 2000 can coexist with normal mail as we know it today. Smarter servers can check if the recipient supports IM2000, and if they don't, send normal SMTP.

I don't actually think it has been implemented yet, and it looks like there are a few issues left to solve, but nothing unsolvable.

But good luck getting everyone to adopt a new mail protocol...

Unfortunately, the infighting, politics and lack of discipline of distribution maintainers have made it nearly impossible. In spite of the fact that DJB is a bit strongly worded in his opinions , he is not far from the truth here. In the 20+ years I've been using various flavors of U*ix, I groan every time I have to use a different distribution because the developers could not be bothered with maintaining a globally consistent directory structure, and simple things like command line flags on common commands (e.g. the ps utility) are rendered inconsitent because two groups of developers think cannot deign to use flags consistent with the other group. It is a real disappointment and in my opinion holds U*ix back big time.

There is a proposal similar to making the sender pay for email: Make him spend CPU cycles. It's on Dan Bernsteins website somewhere.. too lazy to look :-)

It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.

The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."

The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.

The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.

More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the /opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.

Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.

Theoretically, software developers should only have to release their files as .TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.

As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:

apt-cache search pppoe

If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:

apt-get install pppoe

and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

-castlan

A lot of this would be moot with a restructuring of email in general.

Food for thought from the man behind qmail: IM2000

After you've synched your clock to NIST time, you can use the clockspeed package to keep the master clock and any clients in synch.

I agree that with the current system, it is a social problem. But a new standard like Internet Mail 2000 would be immune to spam.

And yet, looking at the advisory, the most important vendors don't yet have patches . In particular, Microsoft, Cisco, and Sun remain vulnerable, with no released patches!

The entire rationale behind keeping vulnerabilities quiet is to enable vendors to fix the problem before the exploit falls into the hands of attackers. The entire rationale behind CERT's very existance is to act as a clearinghouse for vulnerabilities so that fixes can be coordinated prior to announcements. Virtually every credible security researcher has repeatedly exclaimed that CERT's model doesn't work. I can't imagine a clearer vindication for CERT's critics than this.

From the looks of this announcement, this may well be the most serious security vulnerability ever published; it's a root hole in literally every piece of Internet infrastructure deployed to date (assuming lack of filtering; but remember that most networks aren't properly firewalled off internally from customers and insiders). If CERT can't successfully coordinate a response to this vulnerability, why should we trust them with any other problems?

SNMP is a bad protocol. It's universally hated and derided by implementors. This is an amazingly great example of the problems that spring from shallow implementation gene pools; most of these vulnerabilities are probably due to code in CMU and UCD's (related) SNMP libraries. This is an excellent example of why it is critical to diversify implementations of core protocols on the Internet. Some incredibly hardworking researchers have been working towards these ends for years; the network engineering community has largely responded to them with derision . Think about this.

This problem was so subtle that it wasn't detected for years and years, even though the vulnerability boils down to simple buffer overflows. This is because SNMP is an ASN.1/BER protocol. There are like four bazillion ways to represent a length in BER. Talented researchers have continuously reiterated the need for simple, modular protocols to replace the rickety ad-hoc mess we use now. They have again met with derision from the network engineering community. Think about this.

Finally, the fact that SNMP is an insanely complicated protocol has not been lost on attackers. The very fact that CERT "accelerated" the release of this advisory indicates that they knew attackers "could" find some of these vulnerabilities. The fact is that some black hats almost certainly have worked this out. If we had published last year, when the discovery was made, just like the overwhelming majority of other vulnerabilities, the problem would have been fixed a year ago. If you manage a large network, how do you know you haven't already been compromised? Attackers have had years to exploit these problems without you knowing about it.

Why isn't anyone learning from these mistakes?

And yet, looking at the advisory, the most important vendors don't yet have patches . In particular, Microsoft, Cisco, and Sun remain vulnerable, with no released patches!

The entire rationale behind keeping vulnerabilities quiet is to enable vendors to fix the problem before the exploit falls into the hands of attackers. The entire rationale behind CERT's very existance is to act as a clearinghouse for vulnerabilities so that fixes can be coordinated prior to announcements. Virtually every credible security researcher has repeatedly exclaimed that CERT's model doesn't work. I can't imagine a clearer vindication for CERT's critics than this.

From the looks of this announcement, this may well be the most serious security vulnerability ever published; it's a root hole in literally every piece of Internet infrastructure deployed to date (assuming lack of filtering; but remember that most networks aren't properly firewalled off internally from customers and insiders). If CERT can't successfully coordinate a response to this vulnerability, why should we trust them with any other problems?

SNMP is a bad protocol. It's universally hated and derided by implementors. This is an amazingly great example of the problems that spring from shallow implementation gene pools; most of these vulnerabilities are probably due to code in CMU and UCD's (related) SNMP libraries. This is an excellent example of why it is critical to diversify implementations of core protocols on the Internet. Some incredibly hardworking researchers have been working towards these ends for years; the network engineering community has largely responded to them with derision . Think about this.

This problem was so subtle that it wasn't detected for years and years, even though the vulnerability boils down to simple buffer overflows. This is because SNMP is an ASN.1/BER protocol. There are like four bazillion ways to represent a length in BER. Talented researchers have continuously reiterated the need for simple, modular protocols to replace the rickety ad-hoc mess we use now. They have again met with derision from the network engineering community. Think about this.

Finally, the fact that SNMP is an insanely complicated protocol has not been lost on attackers. The very fact that CERT "accelerated" the release of this advisory indicates that they knew attackers "could" find some of these vulnerabilities. The fact is that some black hats almost certainly have worked this out. If we had published last year, when the discovery was made, just like the overwhelming majority of other vulnerabilities, the problem would have been fixed a year ago. If you manage a large network, how do you know you haven't already been compromised? Attackers have had years to exploit these problems without you knowing about it.

Why isn't anyone learning from these mistakes?

One of the ways any ISP can keep track of its customers' browsing habits is to log DNS requests. IF your ISP pulls this baloney on you, try using some other ISP's DNS servers.

Alternately, use dnscache from the djbdns package. It will go straight to the root servers in order to resolve domains, and keep a local cache for good performance. It also protects you from cache poisoning.

One of the ways any ISP can keep track of its customers' browsing habits is to log DNS requests. IF your ISP pulls this baloney on you, try using some other ISP's DNS servers.

Alternately, use dnscache from the djbdns package. It will go straight to the root servers in order to resolve domains, and keep a local cache for good performance. It also protects you from cache poisoning.

End User License Agreements, also known as "shrink-wrap licenses" or "click-through licenses" are not legally binding.

Here's a page that explains further, including citations of court cases where the judge found that they weren't legally binding.

Microsoft updating their EULA means about as much as Steve Ballmer having MSN carry his latest round of whinings and what they wish the world really was.

In my experience so far, the only way to run a fairly spam-proof SMTP server is to be utterly ruthless with blacklisting. Blacklist insanely large portions of IP space, but configure your SMTP server to produce a bounce message which describes a way around the block (like a postmaster address, or something). A legitimate sender should receive and read the bounce (unless they have one of those ghastly SMTP servers which discards error message text and "helpfully" translates it into "the user does not exist"), whereas a spammer is likely to ignore it. If someone responds to the bounce message in the manner described, whitelist the associated IP address. Spammers send out so much mail that they can't attend to every bounce message personally. (And contrary to some opinions I've seen expressed elsewhere in this article, I've yet to see any evidence that spammers remove addresses which consistently bounce.)

Another possibility is to use the "MAIL From:" address: construct a whitelist of names from whom you will accept mail, and bounce all the others with a similar "how to get around this" message. As before, add the address of any such person who reads the bounce message to your whitelist. Note that both of these techniques could, in principle, be automated. Note also that although a spammer can trivially forge the "MAIL From:" address, it's not nearly so trivial to match every "RCPT To:" address with a whitelisted "MAIL From:" address.

I don't pretend that the above approach to spam-blocking is polite, but rather that it's the only one I've found to be very effective, given the limitations of SMTP. Most people are quite horrified at the number of IP addresses I blacklist: one spam from an open relay is usually enough to convince me to blacklist that IP address at the class B level (approx 65,000 IP addresses in its neighbourhood). It's not about raw numbers, though: it's about the impact that it has on your mail service. If I'm never likely to receive a legitimate email from that IP range, then why not blacklist it?

Ultimately, though, the solution will be to replace SMTP with a protocol that recognises one simple fact that SMTP does not: parties engaging in mail exchange are potentially hostile to each other, and thus the protocol must only allow progress when there is mutual agreement between the parties that the transaction should go ahead. IM2000 is an interesting and potentially useful proposal, for example, albeit a bit short on details (and stagnant, judging by the recent lack of traffic on the mailing list). As it happens, I've chosen to make this problem (replacing SMTP) the subject of my Honours thesis, and that's due to be finished by July. Whether or not my proposals will actually be adopted by anyone is a different matter, of course.

DJB already does (look at server information on main page). talk about ego's running rampant. all things aside, DJB writes damn good, clean code. so does OBSD. so does Darren. a match made in heaven for the end users, but you could PPV the ruckus between Theo, DJB, and Darren if they ever met up in the ring.

Take a look at djbdns, from the guy who wrote qmail. It's very different than BIND, but has the same security guarantee as qmail.

Take a look at djbdns, from the guy who wrote qmail. It's very different than BIND, but has the same security guarantee as qmail.

The "desktop" idea has already been yelled and screamed at as a bad idea. And simply, a FTP server is going to be way too hard to use.

OK, I have it easy. I mount my web site as a folder on my local machine, and to "upload" a file I just "Save as ..." in the GIMP and POW! It's published on my web site within seconds. But even that is a little bit difficult

So if you think people, AOL users even, are going to be using FTP ... na, forget it.

FTP daemons are as buggy as hell. Read Bugtraq - all the FTP daemons you can write to have exploits, and the only secure one I know has no upload facility.

Windows XP has the right idea with clicking "publish to the web" or whatever nonsense they've built into the folders. But it is still too difficult.

see D. J. Bernsteins modest proposal for reducing mail traffic