FW:delete ecard email
Hi everyone, If you get an ecard greeting from me DO NOT OPEN it. My computer seems to have been infected with some kind of worm. Delete the email immediately. I'm sorry for the inconvience. Regards, Mickey
Re: FW:delete ecard email
Ooops, I already opened it. I wonder what is going to happen to my machine. Is machine going to send out the similar email to other people? Ning At 12:54 PM 10/25/2002 -0400, mickey newnam wrote: Hi everyone, If you get an ecard greeting from me DO NOT OPEN it. My computer seems to have been infected with some kind of worm. Delete the email immediately. I'm sorry for the inconvience. Regards, Mickey
RE: FW:delete ecard email
Title: RE: FW:delete ecard email Looks like it just did! ;) -Original Message- From: Ning Zhao [mailto:[EMAIL PROTECTED]] Sent: Friday, October 25, 2002 2:20 PM To: mickey newnam Cc: Zbigniew Blaszczyk; Yvonne Gray; Yann Lossouarn; Wayne Gray; Wayne Clark; Vinoj; Udaya shankar; Tom Youngbar; Tom George; Todd Sanders; Todd Baker; Tin Dang; Tim Hinderliter; Stuart Mackie; Steve Moulton; stephen speirs; Stephen Myers; Stephane Pouillot; Sidney Goodwin; shwetal mehta; Shawn Swanson; Shahrokh Sadjadi; Seenu Banda; Scott Newnam; Scott Griffith; Russell Dunn; Ron Shanks; Rick Galatioto; Richard Waguespack; Rich Sibincic; Reynold Wong; Ray Van Natta; Ram Haridasa; Pat Gili; pankaj patel; Objectif; Nick Zhao; Nick hintgen; Hingtgen, Nick [NCRTP:JR40:EXCH]; Neil Ross; Mom & DAD; Mike Prince; Michele Adams; me; Martha; Mark Woodson; Louis Samara; Lori Brefini; Les Thomas; Leon Zachery; Larry Murphy; Kristi Wilson; Kjetil Rossavik; Kim Newnam; Kevin Lingle; Ketan Mehta; Ken Ross; keith haney; Juan Garza; Jon Beck; John Murphy; John Monaghan; John Mainini; Joe Hogan; joe hogan; Joe Hogan; Jodie Spencer; Jim Sepko; Jim Hinderliter; Jim Duke; Jim Butterworth; Jeff Ortel; Jay Jefferies; Jake VanMastrigt; IETF; Guillaume Durand; fumi myers; Frank Pleshe; FlaxStudio; Ellen Li; ed ungemach; Ed Carney; Doug Knowles; Deb Adams; David Nix; Cristina Rodriguez; Comnitel; Chad Marsh; carlos Fierro; Carl Davis; Canessa L Wilkens; Bob Dunnagan; Bipin Kapoor; Barry Voorhees; B. Ware; Anna Lee; angie lebitz; Andy Meseck; Alex Daltrini; Alan Sutherland; Al Andres Subject: Re: FW:delete ecard email Importance: High Ooops, I already opened it. I wonder what is going to happen to my machine. Is machine going to send out the similar email to other people? Ning At 12:54 PM 10/25/2002 -0400, mickey newnam wrote: >Hi everyone, > >If you get an ecard greeting from me DO NOT OPEN it. >My computer seems to have been infected with some kind >of worm. Delete the email immediately. > >I'm sorry for the inconvience. > >Regards, > >Mickey
re: Last Call: NFS version 4 Protocol to Proposed Standard
The IESG has received a request from the Network File System Version 4 Working Group to consider NFS version 4 Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2002-10-16. Damn. It's 10 days after the deadline, but here's my little comment: There is potential for confusion between the words 'release' and 'lease' for non-english speakers. Might be worth adding the note Note for non-native speakers of english: 'release' does NOT mean 'lease again'. It means 'free' or 'relinquish'. Then again, if they're reading an RFC, they probably relish difficult language :-) Cheers, Dan
re: Active Directory and DNS/Kerberos/LDAP/PKCS/X.500
Brian Bisaillon wrote: > [many questions about Microsoft Active Directory standards compliance] > Can someone please point me to some useful information / documentation / resources? You might find one or two links of interest at http://www.kegel.com/linux/edu/fileserving.html which is a page I'm putting together about AFS and Windows/Linux coexistence. It talks a bit about Kerberos and Active Directory. - Dan
RE: FW:delete ecard email
FYI http://www.msnbc.com/news/826033.asp?cp1=1 Regards Sean > Subject: Re: FW:delete ecard email > Importance: High > > > Ooops, I already opened it. I wonder what is going to happen > to my machine. > Is machine going to send out the similar email to other people? > > Ning > > At 12:54 PM 10/25/2002 -0400, mickey newnam wrote: > >Hi everyone, > > > >If you get an ecard greeting from me DO NOT OPEN it. > >My computer seems to have been infected with some kind > >of worm. Delete the email immediately. > > > >I'm sorry for the inconvience. > > > >Regards, > > > >Mickey > >
RID-DoS Mailing list (Inter-network messaging)
Hello, I set up a mailing list to discuss the Internet Draft: Distributed Denial of Service Incident Handling: Real-Time Inter-Network Defense http://www.ietf.org/internet-drafts/draft-moriarty-ddos-rid-02.txt It is a managed list, so please send me an email message if you would like to be added to the list to [EMAIL PROTECTED] I am thinking about setting up a BoF in the Operations and Management Area at an upcoming IETF meeting and would appreciate some feedback on my draft. Abstract: One of the latest trends attacking Internet security is the increasing prevalence of Denial of Service (DoS) attacks. DoS attacks target system and/or network resources and seek to prevent valid access by consuming resources. Internet Service Providers (ISPs) need to be equipped and ready to assist in tracing these attacks with tools and procedures in place before the occurrence of a DoS attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across ISP boundaries to identify the source(s) of an attack. The various methods implemented to trace attacks must be coordinated both on the ISPs network as well as provide a communication mechanism across network borders. It is imperative that ISPs have quick communication methods defined to enable neighboring ISPs to assist in tracking a security incident across the Internet. This proposal makes use of current tracing practices for traffic and performance management, which could be extended for DoS incident handling. Policy guidelines for handling these incidents are recommended and can be used by Internet Service Providers (ISPs) and extended to their clients in conjunction with the technical recommendations. Brief overview of messaging mechanism: The main purpose of the messaging mechanism is to allow for traces of security incidents to be passed to the next upstream network, client to ISP or ISP to ISP. The messages are merely requests and response messages to continue traces and to send notification of trace results/mitigation. The receiving management system of a trace request can make a decision as to whether or not the trace will continue based on resources and/or the confidence rating. The decision can be automated or left to be decided by the network management staff. The trace continuance across each network is decided upon by the managers of that network since it requires access to the systems on that network. RID-DoS passes along the superset of information needed by all trace mechanisms used across a single network (non changing fields of IP header, first 8 bytes of payload, and time of event). If there is additional information needed by a trace system I am not aware of, please let me know. When the source is found, a message is sent back to the system who originated the trace to notify them of the source and any action taken (in accordance with SLA agreements). Current Work: 1. The security section needs to be extended to include authorization details on the trace requests and other messages. 2. The details of the communication between systems needs to be expanded upon. a. The security of the machines themselves b. The security of the networks (out-of-band or encrypted tunnels) 3. The draft needs to include details on how a confidence rating is chosen to help mitigate abuse of the system. Social aspects: Some of the social issues are not addressed in the draft, but I have several ideas of how they might be addressed. 1. How do you get ISPs to use a system like this? a. Establish RID-DoS communication mechanism when configuring peering points b. Include the requirement for RID-DoS in peering agreements (larger ISPs may be able to drive this). c. Peering agreements may be the place to set up the policy for the communication of these systems (may be similar to Certificate policy where physical security, access control, etc. are clearly defined). 2. Where would funding come from to support the addition of this system? a. Extend the service to client networks. Value added service Include arrangements in SLA Finally, I presented this at the SANS DDoS Symposium last week and have received feedback from some ISPs and vendors. Thank you for your time reviewing the draft and any feedback you may have. -Kathleen __ Kathleen M. Moriarty MIT Lincoln Laboratory [EMAIL PROTECTED]
Re: [isdf] RE: Palladium (TCP/MS)
On Sat, 2002-10-26 at 03:26, [EMAIL PROTECTED] wrote: On Fri, 25 Oct 2002 13:17:29 +1200, Franck Martin said: > Note that you can set your exchange server to convert s/mime messages > automatically... On my exchange 5.5 in the Internet connector there is an This is, of course, assuming you are willing or able to use an exchange server. Not all the world uses the same proprietary package (which happens to be what originally STARTED this thread). I was answering a specific point about outlook web mail, to help one user. > We are in chicken-egg situation, that will be solved with a global PKI (my > opinion)... You might want to stop, take a deep breath, and ask yourself exactly what problems a "global PKI" will solve (you might want to go read the chapter on PKI in Schneier's "Secrets and Lies" if you haven't already). Now let's see: You may want to think about SPAM. Certificates for web access and protocols is well defined and working. I agree with you about all the cert usage possibilities. They are all valid. I will check the refrence you gave, but I have also read Peter Gutmann tutorial on security. I think the only question of a PKI in our case, is to initiate communication between two people who never met. If you have to do an handsake before the message is sent, I think it is overkill and may not work, however tmda.sourceforge.net proposes exactly that. The question of a global PKI is to remove anonymity. You can trace back to a real person (legal person) from the certificate. Who can offer that? What has to be done? This is my question... I don't beleive (personnal view) that the web of trust is fully good. This is interesting and I'm curious about it but someone can proxy someone, etc.. so that When I'm trying to know who I'm dealing with I'm lost in a web of "front companies" to name an analogy. If signed e-mails become standard, I may decide to accept only signed e-mail, because I will be able to know who it is, and take action... Think about SPAM and viruses that impersonate other people... The other application would be with IPsec, to initiate an IPSEC channel between 2 computers that do not know each other.. At USD300 a certificate per year, IPSEC will made a few VERY rich... May I put an analogy between the evolution of software cost to the evolution of IP protocols cost: From Free to low cost (https) to major cost (IPsec, e-mail) and unavoidable. This is not an easy subject I realise that...
Re: FW:delete ecard email
On Fri, 25 Oct 2002 12:54:34 EDT, mickey newnam <[EMAIL PROTECTED]> said: > Hi everyone, > > If you get an ecard greeting from me DO NOT OPEN it. > My computer seems to have been infected with some kind > of worm. Delete the email immediately. Seems somebody chose mail software from a vendor that didn't read the warning in RFC1341, section 7.4: The "application" Content-Type is to be used for data which do not fit in any of the other categories, and particularly for data to be processed by mail-based uses of application programs. This is information which must be processed by an application before it is viewable or usable to a user. Expected uses for Content-Type application include mail- based file transfer, spreadsheets, data for mail-based schedulingsystems,andlanguagesfor "active" (computational) email. (The latter, in particular, can pose securityproblems which should be understood by implementors, and are considered in detail in the discussion of the application/PostScript content-type.) > I'm sorry for the inconvience. Happens all the time. Complain to your vendor. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09196/pgp0.pgp Description: PGP signature
Re: [isdf] RE: Palladium (TCP/MS)
On Sat, 26 Oct 2002 09:38:50 +1200, Franck Martin said: > The question of a global PKI is to remove anonymity. You can trace back > to a real person (legal person) from the certificate. Who can offer No. You can trace back to the fact that the signed data was at the same place as the private key, at the same time. It most certainly does *not* prove that a given person intentionally signed it. I want you to think about how many people have had things mailed out because they've gotten an email-based worm - and then think about the fact that the FBI *seriously* considered something called Green Lantern. Then think about how lax security has to be on the average to have Green Lantern actually work. The designers of Curious Yellow (http://blanu.net/curious_yellow.html) have some thoughts regarding worms and PKI, which you might want to read - and consider that said worms do nothing that an attacker can't do on a one-off basis. I'll bet there's at least a dozen different ways to code a malicious webpage that contains Javascript that will download a file, sign it on the victim's PC, and upload it back to the server. No, I don't know of any, but anybody who watches Bugtraq probably goes *yawn* at the discovery of *another* browser hole or cross-site scripting exploit (and note that the latter can possibly be abused as well...) An amazing number of people never even notice they're mailing out tons of attachments. But let's assume the user actually notices, and realizes their key may be compromised (and the average user will *NOT* correlate "worm" with "compromised key") You get lots of bonus points for designing a PKI that's able to issue a new key and a CRL for the old one every time somebody gets bit by Klez or *any other* worm that mails out attachments - unless you can *prove* the attachment wasn't your key, you need a new one. The 4 Mirapoints on our mail hub are fast closing in on *5 million* trapped viruses. And we're one relatively small site, with only 60K mailboxes. Extrapolate to 600 million mail users. That makes for massive churn on the CRL... There's a subtle difference between the average PKI and credit cards too - if I *lose* my credit card, it's easy to cancel - but a lot of fraud doesn't surface till I get my bill weeks later. That's OK, because I can protest the fraudulent transactions and agree to pay the legitimate part of the bill. The average PKI has a hard time dealing with this sort of thing - even if it's able to deal with "we got hacked 3 weeks ago and just found out", there's very fundemental issues with what to do with the 95% of transactions since then. Any sane PKI scheme will insist that everything in the last 3 weeks be invalid and needs to be redone. Good luck doing THAT, especially if the goods and money have already been exchanged in the 95% good transactions > that? What has to be done? This is my question... First off, you need a PKI that *guarantees* that this never happens: http://www.cert.org/advisories/CA-2001-04.html Then you need to consider that we're averaging a CERT advisory *A WEEK* so far this century. Right now, saying "it has a digital signature, therefor the person signed it" is like saying "we didn't see the driver, but because this pickup truck hit somebody, the owner did the hit and run" when the defense has a dozen witnesses that will testify that the defendant habitually left the keys in the ignition -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09197/pgp0.pgp Description: PGP signature
Re: [isdf] RE: Palladium (TCP/MS)
> > The question of a global PKI is to remove anonymity. You can trace back > > to a real person (legal person) from the certificate. Who can offer > > No. You can trace back to the fact that the signed data was at the same ^ a hash of > place as the private key, at the same time. It most certainly does *not* > prove that a given person intentionally signed it. I've seen people *who operate CAs* lose sight of the fact that it's the hash that's signed, not the full data.
Re: [isdf] RE: Palladium (TCP/MS)
On Mon, 28 Oct 2002 12:35:52 CST, Matt Crawford said: > > > The question of a global PKI is to remove anonymity. You can trace back > > > to a real person (legal person) from the certificate. Who can offer > > > > No. You can trace back to the fact that the signed data was at the same > ^ > a hash of > > place as the private key, at the same time. It most certainly does *not* > > prove that a given person intentionally signed it. > > I've seen people *who operate CAs* lose sight of the fact that it's > the hash that's signed, not the full data. OK, if you want to be pedantic. ;) However, let's remember that although a hash collision is *possible* to generate, you'd need on the order of 50K-100K Pentium-4 class boxes for a *year* to generate *one* hash collision(*). Well within the capacities of distributed.net, but hardly the method of attack I'd choose when there's a plethora of easier ways. If things ever actually get secure enough that the distinction between signing the data and a hash thereof actually matters for a real-world threat model, I'll declare victory and retire. ;) /Valdis (*) That's for just a collision. You want a collision where both hashed items make sense as data, that will cost extra. A *lot* extra... msg09199/pgp0.pgp Description: PGP signature
