data request on Sitefinder
The session this morning ran out of time, so I didn't get to ask my question. Verisign's review panel has identified a number of problems -- I won't argue if they're minor or not -- that are addressable with software changes. We heard this morning that Postfix is an application that will need to be changed to handle the proposed new version of Sitefinder's MX record. Of course, it's generally considered a good idea to test sofware before deploying it. So -- how much notice would the operator community want before deploying new software? What about for enterprises? (We all know that stuff *can* be deployed more quickly in emergency circumstances. We also know the problems that that can lead to, which is why we generally want testing and controlled deployment.) --Steve Bellovin, http://www.research.att.com/~smb
-----BEGIN PGP SIGNED MESSAGE----- Steve Bellovin wrote:
Ahem, so Verisign wants to change the complete working of the internet with the currently installed base because they want to gather all the typo's??? Are they going to pay us the money for upgrading/verification/checking/testing etc? Fix the Webbrowsers, which in most cases already support the functionality their 'application' gives. If Verisign wants the webbrowsing folk to use their 'sitefinder technology' then they should take a share in Microsoft, AOL, Opera and a number of other companies and pursuade them to include it. Don't change something that doesn't need fixing. (Ignoring the spam thing :) *if* Verisign gets it through that the installed base has to bend over because they introduce such a thing it would be a very bad thing for the internet as a whole and it would really mean that the internet is yet another commercial thing controlled by one single entity. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5P9mSmqKFIzPnwjEQKDxQCgqYs/jptLOScVYOV4Hgvib8LeZZEAoJ7m CorMPVEzuY10InQz/cniNxlm =iBHg -----END PGP SIGNATURE-----
At 5:22 PM +0200 10/20/03, Jeroen Massar wrote:
Given that this functionality does exist in web browsers, there's the flavor of monopolistic competition that may be vulnerable to antitrust action.
Look at the interview with Verisign's CEO at http://news.com.com/2008-7347-5092590.html?tag=nefd_gutspro, and I think you'll see that your "what it would really mean" is exactly Verisign's position.
Jeroen - and Howard - ----- Original Message ----- From: "Howard C. Berkowitz" <hcb@gettcomm.com>
Hmmm - Jeroen, I dont think this is what this means at all. What it means is that today there is no one entity controls what is routed or passed through and over the Internet. In fact the Internet is a fiction. It is peering agreements and now-adays a number of DNS roots. So then what is it you are really looking for? A single authority to manage the Internet? For instance - who controls what ISP's route and don't route at the client-side level? Becuase for all intents and purposes, the back-end is just pipe. The answer that you will find is that NO ONE controlls the Internet today.
-----BEGIN PGP SIGNED MESSAGE----- Howard C. Berkowitz wrote:
Verisign is indeed being monopolistic here. But you still have a choice of disabling/changing software on your local machine, that is your personal choice. If you install the Google/Altavista/Yahoo toolbar like many people do you will get that functionality. You are probably hinting to MS's dominant IE position, you can turn it off. You can't turn off sitefinder easily though. todd glassey wrote:
Not routed or passed indeed, that is IP level and that is done per ISP/network.
I am not looking for that. ICANN made it possible that there was one well-known root (there are indeed others). This root is currently in control by Versign and they are now going to just make it work for them, not for the public, not for the ISP's. If they can do that, it is exactly that, the root is Verisign's and not that of the public and not of the ISP's. Verisign should NOT be putting wildcards in the .com/.net zones as it is NOT their domain, they where entrusted by the public and with that the ISP's to run .com/.net and make sure that it keeps working in the way it used to. But now they are going to make money from a public resource by abusing their power they have over the .com and .net zones. Even though many have oposed _after_ they suddenly implemented it breaking quite a lot of applications and usages.
For instance - who controls what ISP's route and don't route at the client-side level?
The ISP itself because that is their part of the internet. It isn't called inter-network for nothing.
DNS is a *very* important application in todays internet, he who controls that, controls the internet as that is the biggest user base. I don't see a major fraction of the internet suddenly moving away from the current roots simply because that is the part where the information is. Ofcourse you can use your .leet domain, but who can access it? Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5QYVSmqKFIzPnwjEQIsxwCfd7xBNFu+PDHzIzBxVjTf6yLBzDoAnRHL 6XmnyKSMUFPv7XTvquDMJNgj =JnUE -----END PGP SIGNATURE-----
see http://www.cbronline.com/latestnews/165c8acb5f79bb5780256dc50018bddd for an oblique response to some of sclavos' statements in the interview referenced above. note that in the third paragraph where it says "root server operators" it really should say "name server operators", like http://oarc.isc.org/ does. but the reporter really "got it right" on everything else. -- Paul Vixie
At 10:59 AM -0400 10/20/03, Steve Bellovin wrote:
I don't even want to start down that path. If we were talking normal software development and deployment schedules we'd be talking six months to a year from notice to the software company to deployment. But obviously that isn't going to happen. As a software developer I'd want at least 30-60 days to do development and testing. As a service provider thought, I'm pretty conservative about updating my servers. And of course this change probably wouldn't be back-patched into old versions, so that means I'm biting off all kinds of other changes that I need to test as well. More importantly--Verisign needs to deploy alternate servers so it's actually possible to test software against the changes they propose to make. Otherwise we're just running around guessing what the behavior is going to be. But fundamentally the problem is this. There is no way to handle root wildcards by various registries in a standard and reliable way. Verisign has not even been able to provide code for how to handle *their* wildcard in a reliable way. Each registry may implement different features with different behaviors. What works for one won't necessarily work for another. And every time any one of them changes, or a new registry is added, every single piece of software that relies on a particular behavior has to be checked and possibly patched. We can't afford to run the internet that way. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
On Mon, 20 Oct 2003 13:31:41 -0400 Kee Hinckley <nazgul@somewhere.com> wrote:
But fundamentally the problem is this.
i maintain that there is a different problem that is fundamental. Verisign is clearly expecting the operations community to incur costs so that they can make their (estimated) $100M a year. what's wrong with this picture? richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
I like John Currans proposed timeline of Length of Verisign Contract+1 day. However, absent that, I think that 12 months to the operational community and 24 months to the enterprise community is probably a reasonable starting point as long as they are willing to accept delays if a significant portion of the responses indicate that this is insufficient time. How do you think AT&T customers would respond if AT&T were to redirect all misdialed 800-numbers to TFDA powered by Tellme? I tend to think the response would not be a positive one. In fact, I'd expect the FCC to have something strong to say about it. Owen --On Monday, October 20, 2003 10:59:43 AM -0400 Steve Bellovin <smb@research.att.com> wrote:
I said 90 days myself - 30 of investigation and 30 to plan and then 30 to clean-up whatever messes the act causes. Todd ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Steve Bellovin" <smb@research.att.com>; <nanog@nanog.org> Sent: Monday, October 20, 2003 11:02 AM Subject: Re: data request on Sitefinder
I like John Currans proposed timeline of Length of Verisign Contract+1
day.
the
Steve Bellovin wrote:
Well, that would be a little longer than the time for upgrading from BIND 4.x to BIND 8.x (oh, that would be 9.x these days, folks were so slow to upgrade that the major version changed meantime :-)! I'm pretty sure that's on the order of 4 years or more for operators. Since Postfix is run by a lot more enterprises than BIND, let's double that number! How about, until all the W95 and W98 and W2K servers are updated.... -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Mon, 20 Oct 2003 14:19:36 -0400 William Allen Simpson <wsimpson@greendragon.com> wrote:
if verisgn thinks this ought to get done faster, i think they should volunteer to pay the costs, don't you? richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
A number of people havce responded that they don't want to be forced to pay for a change that will benefit Verisign. That's a policy issue I'm trying to avoid here. I'm looking for pure technical answers -- how much lead time do you need to make such changes safely? --Steve Bellovin, http://www.research.att.com/~smb
On Mon, 20 Oct 2003 16:31:45 -0400 "Steven M. Bellovin" <smb@research.att.com> wrote:
may i suggest another operational issue then? how does verisign plan to identify and notify all affected parties when changes are proposed? for example, in the current case, how do they plan to identify every party running postfix and inform them that they need to upgrade their MTA? this seems non-trivial to me. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
At 5:04 PM -0400 10/20/03, Richard Welty wrote:
Purely from an operational standpoint, it would be a mark of efficiency to have a central repository of who is running what. That would mean that notifications would only be sent to those that need them, and also would provide objective information to determine how many organizations would be affected by a change. In other words, something that actually would be useful. Unfortunately, we have seen Verisign constantly take the position that information they learn through operations is their intellectual property, to be used as they see fit, and generally to be kept proprietary. So if we try to separate operational from policy, we see white-winged ships sail by, carrying data that might be useful, but then have them crash on the rocks of stewardship of the data.
On Mon, 20 Oct 2003 17:15:23 -0400 "Howard C. Berkowitz" <hcb@gettcomm.com> wrote:
At 5:04 PM -0400 10/20/03, Richard Welty wrote:
may i suggest another operational issue then?
this seems non-trivial to me.
i maintain that building this list is phenomenonally difficult. the set of people running mail servers is substantially larger than the set of people who read nanog, run backbones, run regional ISPs, etc., etc. i don't disagree that it would be useful, but how are you going to build it without actively probing mail servers across the internet? and it can't possibly ever be complete, with PIX firewalls obscuring SMTP banners and sysadmins depending on security-by-obscurity who change their banners to elminate MTA identification. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
I don't really disagree with you, even ignoring that many providers would consider much of this information proprietary, much as they might for private peering arrangements. This is something of a thought experiment on what would have to be available for a Verisign or the like to make unilateral changes without presenting the idea for comment, well in advance. The process of asking for comment through IETF and the operational forums has the proven benefit of getting major players to look at the issue and decide to comment. Now, as you point out, there are many people who run mail servers and the like, who don't follow any relevant mailing lists. I would suggest, however, that the number of people that do read these lists run mail servers with more end users than the small system administrators that do not. The absence of a list such as I've described, the difficulty of creating of which you point out, makes it more unlikely to me that an organization can really assess the effects of unilateral design changes, especially when that assessment is shrouded in commercial secrecy.
On Mon, 20 Oct 2003 20:06:50 -0400 "Howard C. Berkowitz" <hcb@gettcomm.com> wrote:
true, but this can be interpreted as "they're small and clueless, so screw 'em", a position which i find unattractive.
agreed. richard ("nine out of ten experts hand selected by Verisign agree...") -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Richard - Do they (Verisign) have any legal reason to??? - is there anything between them and ANY of their clients that requires them to inform them before any changes to protocol facilities are made - I think not. Todd ----- Original Message ----- From: "Richard Welty" <rwelty@averillpark.net> To: <nanog@nanog.org> Sent: Monday, October 20, 2003 2:04 PM Subject: Re[2]: data request on Sitefinder
On Mon, 20 Oct 2003 16:31:45 -0400 "Steven M. Bellovin"
<smb@research.att.com> wrote:
changes
On Mon, 20 Oct 2003 16:55:32 -0700 todd glassey <todd.glassey@worldnet.att.net> wrote:
i'd say that their client is the Department of Commerce. when the wildcard is inserted in the .com and .net zones, it affects many third parties who are not direct clients of Verisign, some of whom are users of .org or other tlds that verisign doesn't handle, so they in fact have no contractual relationship with Verisign or with a Versign client. what i had in mind, though, was that Verisign has apparently indicated that they will give somewhere around 60 days (plus/minus) notice of any future changes of this sort. Steve is attempting to collect data which constitutes technical input about the appropriateness of the interval. what i am suggesting is that the sum total of people who courtesy dictates ought to be notified is basically anyone who runs any sort of internet server. i picked mail servers because Verisign themselves identified the postfix MTA as an "issue". after that, there's still the nagging issue of notification interval. many are thinking in terms of their own, often large and busy ISP or backbone operation. there are many, though, in the Enterprise or SMB spaces who are at risk of being left twisting in the wind ("They're small and clueless, screw 'em"). cost is without question an operational issue. how fast an affected entity (ISP, NSP, Enterprise, SMB) can adapt may be directly related to available manpower or funding. i maintain that it is very difficult to separate the funding issue from the time issue, given that Verisign apparently proposes to give the community 60 or 90 days notice of potentially significant changes to the infrastructure, affecting unpredicatable numbers of entities in ways unknown, and impossible to cost out in advance. for all the flaws of the IETF, it is infinitely preferable to this scenario. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Hi, We are getting a LOT of web requests containing what mostly looks like giberish. [Mon Oct 20 21:13:42 2003] [error] [client 172.133.3.204] request failed: erroneous characters after protocol string: \xb8\xcf\xc235\x9f\xc4\x1c\xebj\xd7\xc5\x8e\xe9d>\xfdMe\xed\x16\xca\xd51\xcfReF\x82\xa3qi\x89\x832<\vJ5k\x15\xa2\x0c\x90\xed\x8bCT\xa3\xa2\x96\xd7\xe8\xa2`S#+W\xfc\xc2\xc2w*\xce\x1a<\xb9\xc3\x91\x14\xb0\x9e\xfe\x14\"7\xaa\xeaR\xd1\x9c\x13\x1a\xf0\x1aN\x8eklP\xdc\xc1\xe3\xb9w\xb0\x1aGt\x04|I4\xae\x06WC\x15NA\x80\xb1\xc5E~\xd59\x85+\xcc\x9e\xb8\xaf(\r\x1f\x97 But this is not the standard Microsoft worm stuff that I can tell. It is coming from numerous IP addresses and nearly took down a few of our servers until we started blocking them with the firewall. So I am trying to find out as much as I can about what is happening, but I don't really know where to start. I don't believe it is considered approperiate to send a list of IPs to this list. So where should I start? The list so far contains about 60 addresses. Thanks, Eric
todd glassey wrote:
To inform? Not yet, although I have the feeling that this will be changed due to historic record. However, changes that have an effect are always analyzed and a course of action chosen. I believe this is the job of ICANN. At some point, ICANN's power will need to be tested and set in stone. Only the community can create or strip that power. Yet if an organization is going to exist to serve the community and maintain order, then it needs the power to do it. I think Vixie has alluded to this a few times, and I know there is much that goes on in the hallways concerning the overall problem of who controls what. Verisign is just helping to push the process along. I doubt it will end as they want it to. -Jack
At 9:46 PM -0500 10/20/03, Jack Bates wrote:
Throughout this affair, I've been puzzled by what seems to be an assumption that once a contract exists, it cannot be changed or cancelled. Yet such changes and cancellations happen daily in business. They may require litigation, lobbying of the Congress or executive when government is involved, market/consumer pressures, etc., but change is not impossible. Jack makes excellent points here, which I might restate that this is a defining moment for ICANN to establish its viability and relevance as an organization. If ICANN is to be meaningful in the future, it _must_ make a strong stand here. Related issues include whether the IETF process, even if flawed, is the consensus means of proposing and discussing changes in the infrastructure. Whether or not the operational forums like NANOG have a role in this process, or even in presenting consensus opinions, also is a basic question for Internet governance. Purely from my experience in journalism, media relations and lobbying, I have to respect the effectiveness of the Verisign corporate folk who largely have been setting the terms of debate, and managing the perception -- or misperception -- of this matter in the business and general press. Apropos of that, lots of people equate "privatization" of the Internet to its "commercialization." Privatization isn't nearly that binary. If privatization, in general, is getting the US government out of Internet governance, we still have the options of: -- transferring such control as exists (and there may be no control mechanism) to a quasi-governmental body such as ICANN. -- transferring control, especially with regard to stewardship, to a not-for-profit corporation (e.g., ARIN) -- accepting that an organization such as IETF will manage a consensus process -- subcontracting, but closely monitoring, to a general for-profit enterprise. -- transferring control to a regulated technical monopoly, probably with a financial model of return-on-investment rather than maximizing shareholder value. -- transferring control, at least for a defined period, to a for-profit enterprise with a fiduciary responsibility to maximize shareholder value -- transferring control to competing for-profit organizations Howard, who is puzzled by what seems to be lots of tunnel vision (and I don't mean GRE).
I will point out that it will be much easier for the community to strip that power than to vest it in another entity. To strip that power only requires one of two things: 1. Enough of the community heading in a different direction and disregarding said entity (ICANN). 2. An organization such as Verisign openly defying ICANN and ICANN failing to make a sufficiently strong response to enforce and protect the consensus will of the community. I think item 1 is unlikely unless fueled by item 2. Verisign would do well to notice that if they do implement the sitefinder wildcards again, and, ICANN does not successfully put a stop to it, the single most likely outcome is for the community to view ICANN as irrelevant and impotent. Once this happens, the inevitable result is a fragmentation of the DNS, disparate roots, and, loss of the convention of a single recognized authority at the root of the tree. This convention is fundamental to the stability of the current internet. Losing it would definitely have negative impact on the end user experience. In every forum to which I have convenient access, Verisign has repeatedly attempted to restrict the discussion to the technical issues around the wildcards. The reality is that the technical issues are the tip of the iceburg and, while costly and significant, they are not the real danger. The issues that must be addressed are the issues of internet governance, control of the root (does Verisign serve ICANN or vice-versa), and finally, whether the .com/.net zones belong to the public trust or to Verisign. Focusing on the technical is to fiddle while Rome burns.
The IETF process is the consensus means of proposing and discussing changes in the DESIGN of the infrastructure, not the construction or maintenance. That _IS_ the role of the network operators and the operators forums. For this to work, however, the operators have to be generally of good will and cooperative for the greater good. This model is somewhat antithetical to capitalism because for it to operate efficiently, it requires the long term good of the community to take precedence over the short-term gains of the individual or single organization. Capitalism is well optimized for the short-term gains of the individual or single organization. This is one of the growing pains that comes from the internet being originated as a government-sponsored community research project. The design was done assuming a collection of organizations whose primary motivation was to cooperate. As we shifted to a privatized internet, that fundamental design assumption was broken and we have seen some interesting changes as a result. The fact that it still works at all is somewhat of a miracle. Its continued stable operation will vitally require the continued good will and cooperation of the entities playing vital roles. An ISP can be routed-around as damage, although the larger the provider, the more painful the injury. If it becomes necessary, significant portions of the internet will route around Verisign in a similar manner. The difference is that absent ICANN providing for this, there will be no agreed upon replacement, and, several alternatives will emerge. The result will be fragmentation of the root, marginalization of ICANN and a reduction in internet stability. I believe much of ICANN's previous resistance to dealing with Verisign's abuses of their role has been fear of the instability that could result. It has appeared to me to be strategically and tactically very similar to the accomodations made by the powers in Europe in the late 1930s. (No, I am not comparing Verisign's actions to those of Hitler, but, the strategy and tactics are a match.) If ICANN continues to give ground, Verisign's capabilities to commit further abuses will continue to grow as well.
Agreed. This is a big part of how the Nazis came to power in the 1930's as well. I hate using that analogy because it is so emotionally charged and the scope of the damage was so much more significant, but, again, I am comparing only the strategy and tactics, not the ideology or the actions. Owen
Owen DeLong wrote:
This is the part that drives me nuts. Unless a court ordered it otherwise, the root servers can designate ANYONE as the registry for a tld. My understanding is that the process for making such changes is lengthy and involves the agreement of 3 different organizations. However, on a technical level, such changes are possible, and such a registry can form agreements with ICANN and the various registrars. I'm suddenly reminded of .org... -Jack
--On Tuesday, October 21, 2003 10:03:09 AM -0500 Jack Bates <jbates@brightok.net> wrote:
I can't tell if you are: 1. Agreeing 2. Disagreeing 3. Making a tangential point to what I said. I agree that technically, designating a new registry for .com/.net and transferring the existing zone file to that registry is a simple matter. However, transferring the other metadata associated with the registry function and getting the registrars all cooperating with the new registry is a bit more involved. If this is not done in advance of the root switch, there are stability issues involved. If this is not done proactively by ICANN, then the probability of a successful and smooth transition drops dramatically. Getting registrars, a new registry, and the root servers to do ICANNs bidding is probably relatively simple. Having those decisions survive the legal and lobbying-based challenge that will surely come from Verisign as a result is a bit harder (Verisign will claim it has rights to continue until the end of it's contract and, I suspect, will not simply accept ICANN paying out the remainder of Verisigns contract, even if they could). Getting this to occur without the involvement and cooperation of ICANN will be virtually impossible because of the loyalty divisions. Further, it will make it much easier for Verisign to get injunctions preventing the root server operators from switching to an alternative registry (or reversing such action). I will remind you that .org was done proactively by ICANN with the cooperation of Verisign and that ICANN made concessions to Verisign to get them to cooperate on the .org transition. Owen
At 7:26 AM -0700 10/21/03, Owen DeLong wrote:
Valid observation.
That _IS_ the role of the network operators and the operators forums.
If one thinks of using the IETF model in the operational forums, which I don't consider an unreasonable idea, the operational forums will need specialized mailing lists/working groups, a document handling procedure, and a means of signing off on the "best current practices" track (analogous to standards track). This isn't rocket science, since most of the conceptual work has been done in the IETF -- mind you, if we ever do this, could we NOT perpetuate some of the more obscure rules in RFC formatting? I'd certainly be willing to work with developing such a process as long as I have a roof over my head (In this economy, I'm more in the "will network for food" category). I think others will, and I would hope that there's even a little time this week for hallway discussion of the idea.
Although there have been precedents for competitive profit-making organizations to cooperate for their mutual benefit. One of the earliest examples is the cooperation of insurers to form Underwriters Laboratories.
Again, there are precedents for conflict-avoiding organizations, or organizations to mitigate industry-created threats. In the first case are both government organizations like the air traffic control system, and private monitoring centers for utility and telephone networks. We have intermediate cases like the VISA network, owned by its competing member banks. In the latter, we have things like CHEMTREC, a system that gives emergency responders 24/7 information on potetially hazardous chemical shipments.
That good will could be recognized, I believe, as legitimate enlightened self-interest. While OSI protocol development was largely a blind alley, the US Justice Department was willing to give antitrust exemptions to the Corporation for Open Systems.
Agreed.
Sadly, you can find very similar techniques in the rise, or attempted rise, of other totalitarian regimes. Somewhere in this, some player should have a job opening for Baghdad Bob. :-(
On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin" <smb@research.att.com> said:
OK, since you asked.... At least from where I am, the answer will depend *heavily* on whether Verisign deploys something that an end-user program can *reliably* detect if it's been fed a wildcard it didn't expect. Note that making a second lookup for '*.foo' and comparing the two answers is specifically *NOT* acceptable due to the added lookup latency (and to some extent, the attendant race conditions and failure modes as well). Also note that it has to be done in a manner that can be tested by an application - there will be a *REAL* need for things like Sendmail to be able to test for wildcards *without the assistance* of a patched local DNS. And yes, this means the minimum lead time to deploy is 'amount of time to write a "Wildcard Reply Bit" I-D, advance through IETF to some reasonable point on standards track, and then upgrade DNS, end host resolvers, and applications'.
At 5:09 PM -0400 10/20/03, Valdis.Kletnieks@vt.edu wrote:
You make an assumption here -- one with which I agree completely -- but that certainly wasn't followed during the Sitefinder debacle. The assumption is that the IETF provides a tested mechanism for disseminating information and making comments. Verisign claims that they had tested their ideas with a Verisign-selected group of organizations, and made their commercial decisions based on the proprietary data it generated from those organizations.
On Mon, 20 Oct 2003 Valdis.Kletnieks@vt.edu wrote:
Its not just wildcards. Although the IAB rejected VeriSign's previous request to do specific response synthesis for IDN, it is conceivable that someone else will do 'interesting' response synthesis, which applications will be _unable_ to detect by querying for a wildcard. ( A similar problem to Randy's 'how do I tell which nameserver gave me this response, without requerying?' )
Yes, which implies that many applications would need to change 'gethostbyname()' calls to 'getrealhostbyname()' (or whatever). Whilst many _popular_ applications can be patched in a relatively quick timeframe, the more subtle implications of large scale synthesis deployment will probably take much longer to be understood, let alone patches being deployed, particular with less popular applications.
draft-bcampbell-non-wildcard-00 was submitted last Tuesday to the rfc editor and should appear in time to be discussed during dnsext in Minnie. Even if its approved instantly (very unlikely, as I've suggested using the last reserved header bit), and relevant authoritative nameservers are upgraded in short order, there is a huge implied change to applications and libraries, which extends the deployment timeline tremendously. To answer Steve's question, it would be at least 3 months to patch my employer's applications to work around a possible .com or .net wildcard, and at least 6 months to do it in a fashion which does not break established standards. --==-- Bruce.
You can't separate them. How long something takes to do depends upon who is paying for it and how much they are paying. With a blank check, I can do almost anything in a week. On the other hand, if it's an unexpected expense without an accompanying unexpected source of funds, the same task can take years. If the beneficiary is not paying, things take very much longer. In any event, this question is currently impossible to answer from a purely technical perspective because we don't know what Verisign intends to change. For example, what will be the new correct way to determine whether or not a domain exists in the DNS, say for purposes of spam filtering? Will the wildcard A record be guaranteed to always point to the same, single address or not? We don't know what the target is, so we don't know what's involved in hitting it. When Verisign releases a specification, then we can talk about what's needed to meet it. DS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh boy, well first and foremost the root servers and database are owned by the public because they were paid for from the TAX-BASE..... Second and foremost the technology to redirect web pages and ips is not new or innovative, kiddies used to do it on IRC, to redirect to porn sites and get paid for every redirected hit, starting in the 1996,1997 time frame. Network solutions on more than one occasion caused an incredible stir when they adjusted pricing and had to role back the price, court ordered. I think some of you were here and remember that ruckus. In the public interest and the interest many businesses, Verisign should divest itself completely and just become another company doing business across the backbone. I see serious troubles ahead, imagine a client of a client who has lets say 3,000+ servers on-line and new list of clients is added and there is a typo and all 3,000 servers are redirected with 10's of thousands of clients, each with the potential to sue in both directions. Gentlemen and ladies this is simply not a well thought out idea, I don't care how many PR firms get involved they are simply there for the money, with no clue to the potential harm. I think the leadership here needs to formulate a public posture and present it's case and it's alternative solution that the NSP community can live with and rapidly adapt to as a working acceptable model. Henry R LInneweh Sr Design Systems Engineer -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP5RUdsiimYc7OT3DEQJ1TgCfftP4aRJDmOxXr5QB04a6nt9Z7ZYAoNdM 72ro5GzJw/dxSrlhMaC6iEMR =i8Ms -----END PGP SIGNATURE----- "Steven M. Bellovin" <smb@research.att.com> wrote: A number of people havce responded that they don't want to be forced to pay for a change that will benefit Verisign. That's a policy issue I'm trying to avoid here. I'm looking for pure technical answers -- how much lead time do you need to make such changes safely? --Steve Bellovin, http://www.research.att.com/~smb
At 2:35 PM -0700 10/20/03, Henry Linneweh wrote:
But clearly the problem there is in the UI for the application they used. After all, if the application had just looked up the host name the admin entered, and checked first to see if it had an A record, then the typo would have been detected immediately, instead of after deployment. :-) -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
"Steven M. Bellovin" wrote:
Merely install a new version of postfix on all MX servers? Assuming that postfix itself has been modified as desired by VeriSign? Well, let's see, in an emergency with the master mail server crashing 20+ times a day, I was able to get the support folks to scavenge parts, build another machine, essentially talk them through cloning one of the old NS machines, update it to latest system and BIND 9, run a few rudimentary tests, and physically swap it in, all in just about 6 days. (I probably could have done it myself in under a day, but I'm in Michigan and they are in rural Mississippi. Also, you have to consider that it's a 3.5 hour drive round trip to Memphis for any parts needed on an emergency basis, and POPs are spread about an hour apart. Quick installation is not in the cards.) Of course, that was for BIND, not postfix, which would take longer. To order a faster postfix frontend MX machine (we did), await delivery, install and test and physically swap -- oops, they still haven't finished install and test ... in 4+ weeks so far. When they finish that, the same process on the machine swapped out, lather, rinse, repeat until all machines are finished. (Since the VeriSign emergency went away, there was a lot less pressure to divert support from the jobs they are paid to do, or work overtime.) Really, no matter how you slice it, money is at least as important to lead time as the "pure technical answers". -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
participants (16)
-
Bruce Campbell
-
David Schwartz
-
Eric Frazier
-
Henry Linneweh
-
Howard C. Berkowitz
-
Jack Bates
-
Jeroen Massar
-
Kee Hinckley
-
Owen DeLong
-
Paul Vixie
-
Richard Welty
-
Steve Bellovin
-
Steven M. Bellovin
-
todd glassey
-
Valdis.Kletnieks@vt.edu
-
William Allen Simpson