Newsletter on Internet voting, privacy and security issues
List: I would like to extend an invitation to the IETF list to read "The Bell" -- the first newsletter entirely dedicated to Internet voting and collaborative decision-making in Internet protocols (including the use of digital certificates and the resulting security/privacy concerns from potentially non-anonymous voting). Electronic and hard copy subscriptions are available at www.thebell.net Safevote [1] is sponsoring the newsletter as an open forum. Regarding the name "The Bell", the idea was to use the image of a bell because mission bells were used in colonial California for telling time, announcing events, and for passing on news from one city to another. This newsletter intends to serve similar purposes and is also a public service open and free for all who may want it. With monthly 16-page issues, the "The Bell" will focus on privacy, security and technology used in Internet voting. In Internet tradition, the newsletter is available free over the Internet (PDF format), or at an annual cost of $30 for first class mail delivery in hard copy. The first issue contains an extensive marketing study of the year 2000 U.S. public elections market - a study that will be serialized in upcoming issues. It also includes an article on today's public voting systems used in the United States by election expert Roy G. Saltman and an essay by myself outlining the need for a strong separation between identification and authentication in order to ensure fair Internet voting protocols. Internet voting and its potential impact on society will increasingly call upon us to understand and keep abreast of the latest developments in various fields of work. As a developer in this market, I see a widening gap between the 100-year-old voting technologies in use today and what Internet voting protocols need to take into account. The Bell is dedicated to help fill this gap -- perhaps with your help as well. Cheers, Ed Gerck [1] Safevote (www.safevote.com) is a founding member of the Internet Voting Technology Alliance (www.ivta.org) and develops OEM (Original Equipment Manufacturer) systems for Internet voting, polling, public elections, bidding, consensus assessment and other Internet decision- making applications. The Bell is edited at Safevote. The May 2000 issue is now available at the "The Bell" Web site, www.thebell.net
Re: interception proxies
Vijay Gill [EMAIL PROTECTED] writes: Any specific ISP's that one could care to name? Coming from an ISP, what I've seen in general is that most routers have just enough cycles in the forwarding path to keep up with the offered traffic, much less sit around watching for SYN's in flight so as to mutate the MSS values. In fact, I'd think this would be more of an end system issue rather than a "core" or a "backbone" issue, where the end system is the box prior to the ISP handoff and not quite under the ISP's control and not the end system as in the end2end tcp/ip sense of the word. As the person who mentioned this to Ted in the first place, it's BellAtlantic InfoSpeed DSL: 04:07:18.626618 ppp0 badsl.1886 home.finger: S 3981264130:3981264130(0) win 31944 mss 1452,sackOK,timestamp 57597532 0,nop,wscale 0 (DF) 04:07:18.720702 ppp0 home.finger badsl.1886: S 295466136:295466136(0) ack 3981264131 win 16384 mss 1412,nop,wscale 0,nop,nop,timestamp 7390358 57597532 04:07:18.720725 ppp0 badsl.1886 home.finger: . 1:1(0) ack 1 win 31944 nop,nop,timestamp 57597542 7390358 (DF) 04:08:17.797647 badsl.1886 home.79: S 3981264130:3981264130(0) win 31944 mss 1412,sackOK,timestamp 57597532 0,nop,wscale 0 (DF) 04:08:17.798118 home.79 badsl.1886: S 295466136:295466136(0) ack 3981264131 win 16384 mss 1460,nop,wscale 0,nop,nop,timestamp 7390358 57597532 04:08:17.839552 badsl.1886 home.79: . ack 1 win 31944 nop,nop,timestamp 57597542 7390358 (DF) Of course, it's hard to tell exactly where this is happening. I suspect either the DSL modem or the DSLAM. I've considered bringing up IPsec using AH on the two endpoints, but I'm sure that will involve far more pain dealing with incompetent technical "support" droids than I have time to deal with. On the other side, I can name over a dozen major web sites which create a black hole by setting DF on outgoing TCP segments, but block ICMP fragmentation required messages going the other way. If anybody at Cisco is listening (a rhetorical question to be sure), a great feature for a future version of IOS would be one which causes TCP to be blocked completely if ICMP fragmentation required packets are blocked. At least then the black hole would be easy to spot :-) Marc
Re: Source address (offtopic)
I don't want to change it (as if I could!), my purpose was to point out that our current network is the sum of our mistakes, not the network equivalent of the Mount Sinai tablets. no disagreement there. but the original mistakes in TCP/IP were more-or-less designed to work together. when people start deploying their own mistakes in an ad hoc fashion, and when multiple mistakes get added concurrently, not only do they break things that assumed that the only mistakes in the network were those originally designed-in, the combined effect of those new mistakes is far worse than the effect of any of them taken individually. Keith p.s. I will also argue that the complexities of adding a separate application-level identifer and doing without the source address, are such that had this been done in the original TCP/IP design, it would have had a much more difficult time getting deployed in the first place.
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote: I wonder if any of the authors has explored the risks of modifying data in flight. How could this be abused by interlopers and evil doers? If I could hack into a router implementing NECP, what damage could I do? Could I start a nasty little JavaScript/Java/Shockwave/... applet in an advertisement? And who would know it was me? Do you mean the authors of NECP? If so, then I'm confused because NECP is not about "modifying data in flight" - it is about load balancing multiple services which sit behind e.g. a single IP address. (i.e. DNS server farms, firewalls, proxies). As I have said repeatedly, "interception proxies" is only one of these applications and by no means the most widely used. Are you confusing this with WCCP (which *only* works with "interception proxies"). Quoth John Martin: [...] Let me be absolutely clear, NECP is about communication between server load-balancers (SLB) and the back-end servers they speak to. Were this so clear in your document my mailbox wouldn't be full of this stuff. The very first sentance says: "This document describes "NECP", a lightweight protocol for signalling between servers and the network elements that forward traffic to them. It is intended for use in a wide variety of server applications, including for origin servers, proxies, and interception proxies." Despite the fact that "interception proxies" are listed last, they are the only service people are talking about. But, you are right in general: if this is how people read the document, we need to fix the document. If it looks like a duck and quacks like a duck, but it's not supposed to be a duck, the IESG ought to point out that it's a turkey by so indicating at the top of the document. Also, I'd like to understand why you're not going experimental, where it would be expected that you'll correct your mistakes. Your choice of "informational" seems unfortunate at best and as disingenuous marketing at worst. I can't tell which. We used "informational" because we saw that this is what was used for HTTP/0.9 with which there are parallels: NECP has existed for some time already in slightly differing implementations and this is a codification of existing practice. There was no magic of deceit intended. If the IESG thinks we should instead go for experimental, I'd be more than happy to pursue that instead and bring this into WREC. However, development is not within the current WREC charter so we are stuck, I think? The fact that you mention interception proxies in the introduction has led to this flame war. Having used the words, you've mentioned none of the risks associated with such services both from the server side and the client side. OK - we can fix that. It is not the goal of NECP to describe "interception proxies" or their deficiencies. There is, however, a working group which has a document aimed at exactly that (amongst other things) - WREC. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: Source address (offtopic)
In message [EMAIL PROTECTED], Matt Crawford typed: The source address of a datagram was an architectural mistake, and should never have been in the mandatory packet format. Nahh, the mistake was ignoring the source address when routing forwarding. thats an implementation detail not a design mistake. there's plenty of fast classifier algorithms and data structures now for the 5-tuple which reender this debate academic - in fact, i think the lack of a idee fixe about flow id, versus src or dst or src+dst based routing, versus route hint +eid and so on is the _strength_ of the tcp/.ip model- the very lack lack of strong noel complains about foresight led to diversity and design freedom cheers jon
RE: eating our own dogfood
Hehe -Original Message- From: Randy Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 12, 2000 11:32 PM To: ietf Subject: eating our own dogfood rip.psg.com:/usr/home/randy/mp3/neil_young nslookup ietf.org. Server: cache.psg.com Address: 147.28.0.3 *** No address (A) records available for ietf.org. rip.psg.com:/usr/home/randy/mp3/neil_young ns ietf.org. Default Server: cache.psg.com Address: 147.28.0.3 Server: cache.psg.com Address: 147.28.0.3 Non-authoritative answer: ietf.orgnameserver = ns.ietf.org ietf.orgnameserver = ns.CNRI.Reston.VA.US Authoritative answers can be found from: ns.ietf.org internet address = 132.151.1.19 ns.CNRI.Reston.VA.USinternet address = 132.151.1.1 rfc2182 ignored, both servers on same backbone, probably in same site. dns hosed, ietf.org was an A RR just a few hours ago. randy
Re: interception proxies
Hello Vernon, At 21:48 12/04/00 -0600, you wrote: I also think you need to give up the idea of having computers make value judgements, but maybe that's just my lack of imagination. Sure that computers will improve doing judgements, but don´t lost the main force on Interenet, there are hundres of millons of human brains here able to do judgements, and for me, the most important Internet goal is how to get this incredible power running in an usefull way? For the information that you see the first time before anybodi else you only have computers for the jugement, but also the computers jugements can use the people past jugements i.e. about the information font... Some questions about people feedback are: How to feedback? It is required a way to feedback not only to the owner of the information but to the comunity, about the information that you see, it´s requiered to invistigate what atributes want the people to use to select the information in each categorie, then to ask the people that see this information before about any of this atributes when they are getting this information. Why to feedback? Most people will never feedback unless they don´t get a reward for it, feedback must be paid, but I don´t agree to: please reply this question about this information and you get 1$, because people will reply anything, feedback must be competitive in a feedback game, in the way that people that are more usefull to other people with their information will get the greats rewards. How to organize the feedback to be usefull? with feedback happens that is as important the jugement as who did this jugement, that´s why I think trusters can be a usefull way to organize this knowlege, because the people that join the same trusters seems to have similar values and so similar jugements. ... Not only values also e-comerce need people feedback, with the current Internet stuff mainly comercial brouchures, people will not able to do good decisions because everyting is gorgeous, wonderfull,..., to been able to take decisions people need real information not comercial garbage!, it doesn´t matter how much inteligence you put on people desktop, If you remove the garbage it will remain garbage, information that comes from independent people is not so wonderfull about everything because is real information usefull to do decions, so to impulse the e-comerce. So yes, we must improve computers jugement but much more people one! Salva Vernon Schryver[EMAIL PROTECTED]
Re: recommendation against publication of draft-cerpa-necp-02.txt
Part of the problem here is that a knife may be used as a food utensil or a weapon. Safe handling, however, is always required, and should be documented. I would add two other comments. I tried to locate the RFC for HTTP/0.9, but the best I could find was a reference to a CERN ftp site for the protocol. In any case, by the time HTTP got to the IETF it was deployed over a vast number of end stations, and comparisons to it are probably not apt. Finally, rechartering is precisely what you ought to have done, and should do, IMHO.
Request for Information
Hello, I am doing my Masters in US. I have a few ideas for my masters' project. I request you to comment about these ideas, and help me choosing the best out of these. 1. Real time video transmission using Java. 2. Internet telephony using Java. 3. Remote network management using Java. 4. Video conferencing. 5. e-business service development. Thanks for your time, du. __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
RE: Request for Information
(2) option is the best of all from my view point but you could use some real time OS like VxWorks or Nuclues -Original Message- From: du pot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 13, 2000 2:05 PM To: [EMAIL PROTECTED] Subject: Request for Information Hello, I am doing my Masters in US. I have a few ideas for my masters' project. I request you to comment about these ideas, and help me choosing the best out of these. 1. Real time video transmission using Java. 2. Internet telephony using Java. 3. Remote network management using Java. 4. Video conferencing. 5. e-business service development. Thanks for your time, du. __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote: Part of the problem here is that a knife may be used as a food utensil or a weapon. Safe handling, however, is always required, and should be documented. Granted. I would add two other comments. I tried to locate the RFC for HTTP/0.9, but the best I could find was a reference to a CERN ftp site for the protocol. Ooops. s/0.9/1.0 - rfc1945. In any case, by the time HTTP got to the IETF it was deployed over a vast number of end stations, and comparisons to it are probably not apt. NECP is a super-set of various load-balancing technologies already deployed at thousands of sites. Finally, rechartering is precisely what you ought to have done, and should do, IMHO. For the record: this is exactly what we are doing. (We were waiting for the two starter documents to be published or at least start their path via the IESG). Rgds, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: interception proxies
On 13 Apr 2000, Marc Horowitz wrote: Vijay Gill [EMAIL PROTECTED] writes: think this would be more of an end system issue rather than a "core" or a "backbone" issue, where the end system is the box prior to the ISP handoff and not quite under the ISP's control and not the end system as in the end2end tcp/ip sense of the word. As the person who mentioned this to Ted in the first place, it's BellAtlantic InfoSpeed DSL: Of course, it's hard to tell exactly where this is happening. I suspect either the DSL modem or the DSLAM. Ah yes. Perhaps it would be interesting if the vendor(s) name(s) were published, so that when they come touting the hardware to other providers, some hard questions may be asked. /vijay
