RE: Palladium (TCP/MS)
Good Morning Valdis -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 29 October 2002 15:39 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) You're close. You'd want this for multihomed servers, so a PTR query works as you'd expect. Consider this case: www.big-corp.com A 10.0.0.10 A 192.186.10.10 mail.big-corp.com A 10.0.0.10 A 172.16.23.10 Then you'd want to have PTRs as follows: 192.168.10.10 PTR www.big-corp.com 172.16.23.10 PTR mail.big-corp.com (and then the magic) 10.0.0.10 PTR www.big-corp.com PTR mail.big-corp.com If you don't have 2 PTR records for that last, you can get into the situation where a system will look up the A record for www, get the IP address, then do a PTR to sanity-check, get back only the mail. address, and get upset. Having both PTR records means that you'll be able to find one to match to the original hostname either way... Forgive my ignorance, but I thought email was handled by Mail eXchange (MX) records, thus a PTR would not be required? Thinking along a bit more, setting the routers shouldn't be a big issue, after all Cisco have been producing routers IPv6 capable for a fair while now, so surely they could incorporate multiple PTR records within the routers capability? Routers don't have anything at all to do with PTR records. What I said was that if a company wanted to block all access to Microsoft's servers, they'd have to keep continual track of all the IP addresses in use - which can be interesting if round-robin DNS or other similar things are in use. I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Regards Sean Jones
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 08:48:35 GMT, Sean Jones said: Forgive my ignorance, but I thought email was handled by Mail eXchange (MX) records, thus a PTR would not be required? Just because an MTA follows an MX to find where to send a piece of mail doesn't mean that other things don't use PTR records for other purposes. To consider the headers in your note: Received: from mm_w2k1.micromedical.local (mailgate.peakflowmeter.co.uk [62.49.78.214] (may be forged)) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AUE74943; Fri, 01 Nov 2002 03:56:05 -0500 (EST) You might think about where peakflowmeter came from -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09221/pgp0.pgp Description: PGP signature
Re: Palladium (TCP/MS)
Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 09:10:59 EST, John Stracke [EMAIL PROTECTED] said: Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. And in addition, not all the net is a commercial enterprise. There's a very large worldwide presence in the gov/edu/org arenas - and a *LOT* of those organizations have political, philosophical, or other reasons for blocking Microsoft. I'm sure there's privately held companies that can afford to have similar views - and I'm waiting for a shareholder suit against the board of a publicly held company for decreasing profits by continuing to permit the use a certain MUA even though it's one of the leading causes of virus and worm propagation... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09226/pgp0.pgp Description: PGP signature
RE: Palladium (TCP/MS)
Good Afternoon again Valdis -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 01 November 2002 13:35 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) Received: from mm_w2k1.micromedical.local (mailgate.peakflowmeter.co.uk [62.49.78.214] (may be forged)) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AUE74943; Fri, 01 Nov 2002 03:56:05 -0500 (EST) You might think about where peakflowmeter came from I cheat with Exchange 2000. I manage a number of domains, and in order to make my job simpler, I have all of these domains forwarded to one domain via my ISP, then sort them on the Exchange server. Regards Sean
Re: Palladium (TCP/MS)
Wha? they go outlaw windows? Shareholders wont do non of that in realm of lawsuits because M$ the media done a good job at brain neutering the masses and furthering intellectual ejemitysp in the schools. Damn, I taking cis-2 and they concentrate in M$ details of operation and not on raw talent, teacher go ding you in the grade dept. if your comment block is not just so perfect... shit. --chris 11/1/02 7:15:08 AM, [EMAIL PROTECTED] wrote: On Fri, 01 Nov 2002 09:10:59 EST, John Stracke [EMAIL PROTECTED] said: Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. And in addition, not all the net is a commercial enterprise. There's a very large worldwide presence in the gov/edu/org arenas - and a *LOT* of those organizations have political, philosophical, or other reasons for blocking Microsoft. I'm sure there's privately held companies that can afford to have similar views - and I'm waiting for a shareholder suit against the board of a publicly held company for decreasing profits by continuing to permit the use a certain MUA even though it's one of the leading causes of virus and worm propagation... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 15:30:34 GMT, Sean Jones [EMAIL PROTECTED] said: You might think about where peakflowmeter came from I cheat with Exchange 2000. I manage a number of domains, and in order to make my job simpler, I have all of these domains forwarded to one domain via my ISP, then sort them on the Exchange server. Yes. I meant how did my mail system get peakflowmeter's name... Also, contemplate why there's a may be forged in there... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09235/pgp0.pgp Description: PGP signature
Re: [isdf] RE: Palladium (TCP/MS)
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. 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, ... My point was not about hash collisions, but rather that the dongle that holds the key often has no idea at all about the meaning of what was signed. And if it's an intruder who caused the signing, there may be no record of the cleartext. If it was a certificate, you can't revoke it because you don't know its serial number or anything else[*] about it. Matt [*] Well, if NameConstraints were implemented you could put a bound on the Subject. That's not much comfort.
RE: Palladium (TCP/MS)
Good Morning Valdis On Wed, 23 Oct 2002 09:37:44 BST, Sean Jones [EMAIL PROTECTED] said: Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP record? (Perhaps it is me in my ignorance, or lack of understanding :o) ) It's not different. Or in any case, it's not sufficiently different to cause an interoperation problem in this case. The reference to RFC2821, section 10.2 was regarding the fact that having multiple PTR records for one address *IS* legal, despite widespread belief to the contrary. The original point was that you'll need a router ACL to block a lot more than one address, and keep the list of addresses up to date. And anyhow, using a router block is a bad idea in this case. There's two cases - either you still have machines using that vendor's software, and you WANT them to reach the servers so they can update, or you don't have the software installed, in which case you don't really care if the server is reachable.. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech I have been cogitating on this for a little while. (Especially as I didn't want to sound thick when replying) Why would MS (or anyone for that matter) want multiple pointer records when one will suffice. My thoughts revolved around clustered servers, .net etc In short the Microsoft-verse. In reality it doesn't matter two hoots what MS do, they will still have to inter-operate with the rest of the Internet per se, unless you believe the scare mongering that with .Net MS want to make a corporate Internet which they control. (If they did ever go that way, I'd be one of the first to join Treehouse) Thinking along a bit more, setting the routers shouldn't be a big issue, after all Cisco have been producing routers IPv6 capable for a fair while now, so surely they could incorporate multiple PTR records within the routers capability? Regards Sean Jones A Boring old IT Manager for a SME
Re: Palladium (TCP/MS)
On Tue, 29 Oct 2002 10:54:02 GMT, Sean Jones [EMAIL PROTECTED] said: Why would MS (or anyone for that matter) want multiple pointer records when one will suffice. My thoughts revolved around clustered servers, .net etc In short the Microsoft-verse. You're close. You'd want this for multihomed servers, so a PTR query works as you'd expect. Consider this case: www.big-corp.comA 10.0.0.10 A 192.186.10.10 mail.big-corp.com A 10.0.0.10 A 172.16.23.10 Then you'd want to have PTRs as follows: 192.168.10.10 PTR www.big-corp.com 172.16.23.10PTR mail.big-corp.com (and then the magic) 10.0.0.10 PTR www.big-corp.com PTR mail.big-corp.com If you don't have 2 PTR records for that last, you can get into the situation where a system will look up the A record for www, get the IP address, then do a PTR to sanity-check, get back only the mail. address, and get upset. Having both PTR records means that you'll be able to find one to match to the original hostname either way... In reality it doesn't matter two hoots what MS do, they will still have to inter-operate with the rest of the Internet per se, unless you believe the scare mongering that with .Net MS want to make a corporate Internet which they control. Note that Microsoft is being very careful to fight the .Net war at the application level and leave transport and lower alone, simply because they know they need to interoperate. Thinking along a bit more, setting the routers shouldn't be a big issue, after all Cisco have been producing routers IPv6 capable for a fair while now, so surely they could incorporate multiple PTR records within the routers capability? Routers don't have anything at all to do with PTR records. What I said was that if a company wanted to block all access to Microsoft's servers, they'd have to keep continual track of all the IP addresses in use - which can be interesting if round-robin DNS or other similar things are in use. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09201/pgp0.pgp Description: PGP signature
Re: RE: Palladium (TCP/MS)
.net is a suite of coding publishing tools. maybe should throw together a .org suite of freeware coding tools? 10/29/02 2:54:02 AM, Sean Jones [EMAIL PROTECTED] wrote: Good Morning Valdis I have been cogitating on this for a little while. (Especially as I didn't want to sound thick when replying) Why would MS (or anyone for that matter) want multiple pointer records when one will suffice. My thoughts revolved around clustered servers, .net etc In short the Microsoft-verse.
RE: RE: Palladium (TCP/MS)
And there is the mondo(?) project at ximian.com. Having .net running on linux all in opensource. Cheers. -Original Message- From: Lloyd Wood [mailto:l.wood;EIM.SURREY.AC.UK] Sent: Wednesday, 30 October 2002 9:29 To: Christopher Evans Cc: [EMAIL PROTECTED] Subject: Re: RE: Palladium (TCP/MS) On Tue, 29 Oct 2002, Christopher Evans wrote: .net is a suite of coding publishing tools. maybe should throw together a .org suite of freeware coding tools? what, like www.gnu.org? www.fsf.org? where have you been? L. http://www.ee.surrey.ac.uk/Personal/L.Wood/[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: [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)
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
RE: [isdf] RE: Palladium (TCP/MS)
Title: RE: [isdf] RE: Palladium (TCP/MS) I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... 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 option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]]Sent: Friday, 25 October 2002 12:27 To: 'Franck Martin '; ''Gary Lawrence Murphy' 'Cc: ''TOMSON ERIC' '; ''[EMAIL PROTECTED]' '; ''[EMAIL PROTECTED]' 'Subject: RE: [isdf] RE: Palladium (TCP/MS) MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
RE: [isdf] RE: Palladium (TCP/MS)
Title: Message As this thread is becoming more and more technical, may I suggest to limit it from now on to the IETF list and then to stop cc:ing the ISDF list... -Original Message-From: Franck Martin [mailto:[EMAIL PROTECTED]] I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... 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 option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]] MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
Re: [isdf] RE: Palladium (TCP/MS)
F == Franck Martin [EMAIL PROTECTED] writes: F ...Anyone who sends me e-mail can be identified. Anything I F send can be traced to me. People wouldn't be forced to F participate, but if they remain anonymous, I might choose to F block them. I certainly wouldn't accept file attachments from F them. I know you hate this idea, but I think the Internet needs F a fingerprint. Isn't that PGP? -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
Re: [isdf] RE: Palladium (TCP/MS)
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). 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: If it's within my organization, a cert signed by my local CA is fine. I trust the guys upstairs from me to sign my organization's user's certs more than I trust some top-level CA to sign a certificate-signing-cert for some group I've never heard of. If it's an organization that we've got ongoing business with, it's easy enough to exchange certs and cross-sign them (a la PGP). Now we get to the hard case - initiating contact with a group I've never been in contact with before. Now, if all you care about is establishing an encrypted tunnel, a self-signed cert works *just fine*. So there's only two cases to worry about here: 1) A PKI *does* allow you to (somewhat) verify that the server at the other end is who it claims to be, and that you haven't been redirected by nefarious means (DNS cache poisoning, domain hijacking, etc) and that the server you are talking to really *IS* the www.example.com that you wanted. Note that the most popular application that uses SSL is IE, and that (A) IE is well-known for a lot of ways to hijack things (and that if you've been redirected via Javascript XSS, and you THINK you're talking to foo1.com, but really talking to foo2.com, then a cert for foo2.com will show no problems unless you actually click on the check cert details button and see it's issued to foo2.com. (B) few users seem to actually care. 2) Even if you've successfully connected to www.joes-junkyard-parts.com, and the certificate checks out, and all that, it tells you *NOTHING* about their business other than the fact that they qualified for a cert from some CA. It doesn't tell you if they're just in it for the credit card fraud, or if they will actually ship the parts, or whether they are in the habit of leaving all the credit cards out for anonymous FTP I suspect that the *real* reason there's no PKI yet is because there's no really motivating reason to have anything other than a cert for the company webserver (in most cases). And I suspect that this is unlikely to change until the legal climate regarding digital signatures has changed a lot. Not only does there need to be some legislation about it, but *also* some case law testing what the legislation does and doesn't mean - the biggest challenge will be defining the liability of a company if a private key is hacked/stolen and used to sign things without permission. As Schneier points out, the fact that it's signed *ONLY* proves that the data and the private key were at the same place at the same time, and says nothing about whether it's an *authorized* signature -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09183/pgp0.pgp Description: PGP signature
RE: [isdf] RE: Palladium (TCP/MS)
Don't forget that the web-of-trust of OpenPGP is really a citizen approach and you don't have to rely on a specific entity. ISOC should organize more keysigning party ;-) (ok some at IETF) adulau On Fri, 25 Oct 2002, Franck Martin wrote: This is called PGP and S/MIME. Both are valid IETF RFC. From an industry point of view, S/MIME seems to be the one that will survive in the long run, because it is implemented in nearly all mail clients and follows the certificates used in SSL/TLS which is widely adopted (IPSec to name only one). However, none of them is widely implemented for e-mail purposes because of problems to build a global PKI (in short). I still haven't found a company that will give/sell me a certificate that allows me to sign my organisational e-mails certificates. ISOC is working on it... Cheers. -Original Message- From: Gary Lawrence Murphy [mailto:garym;canada.com] Sent: Friday, 25 October 2002 11:19 To: Franck Martin Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [isdf] RE: Palladium (TCP/MS) Isn't that PGP? ___ Isdf mailing list [EMAIL PROTECTED] http://www.isoc.org/mailman/listinfo/isdf -- --Alexandre Dulaunoy -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=getsearch=0x44E6CBCD People who fight may lose.People who do not fight have already lost. Bertolt Brecht
Re: Palladium (TCP/MS)
On Wed, 23 Oct 2002 15:00:51 EDT, John Stracke [EMAIL PROTECTED] said: That doesn't necessarily follow. I read a report (*) today that the EULA for XP/SP1 and 2000/SP3 states that, if you use automatic updates, you grant MS, and its designated agents, access to your software information--which is vague enough to include any data on your system. So don't accept the EULA, and don't install SP/1 or SP/3. (Yes, I'm fully aware that failing to install patches has it's own set of issues, which I wholeheartedly invite you to discuss with the vendor, in detail). If you find that you have to run software such that you have to ban the machines from being able to contact the vendor's machines, it may be time to re-evaluate the choice of software. And my original point still stands - there's more than one IP address for the update servers, and if you're trying to block access to them, you'll have to check the DNS on a regular basis (at least once per TTL). At the moment, *my* view of 'windowsupdate.microsoft.com' is a CNAME that as of right now is a CNAME to windowsupdate.microsoft.nsatc.net, which has an IP address without a PTR entry somewhere in a hotmail.com zone. By the time you read this, it will likely be elsewhere. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09170/pgp0.pgp Description: PGP signature
RE: [isdf] RE: Palladium (TCP/MS)
Title: RE: [isdf] RE: Palladium (TCP/MS) MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't know S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period. -Original Message- From: Franck Martin To: 'Gary Lawrence Murphy' Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Sent: 10/24/02 7:31 PM Subject: RE: [isdf] RE: Palladium (TCP/MS) This is called PGP and S/MIME. Both are valid IETF RFC. From an industry point of view, S/MIME seems to be the one that will survive in the long run, because it is implemented in nearly all mail clients and follows the certificates used in SSL/TLS which is widely adopted (IPSec to name only one). However, none of them is widely implemented for e-mail purposes because of problems to build a global PKI (in short). I still haven't found a company that will give/sell me a certificate that allows me to sign my organisational e-mails certificates. ISOC is working on it... Cheers. -Original Message- From: Gary Lawrence Murphy [mailto:[EMAIL PROTECTED]] Sent: Friday, 25 October 2002 11:19 To: Franck Martin Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [isdf] RE: Palladium (TCP/MS) Isn't that PGP?
Re: [isdf] Re: Palladium (TCP/MS)
At 08:40 AM 10/22/2002 -0600, Vernon Schryver wrote: Again, other big organizations (specifically including Cisco) are not above embracing-and-extending out of ignorance, provincialism, and failures to bother to do interoperability testing (possible causes of the Microsoft PPP hassles) if not malice. Do not attribute to malice that what comes from management decisions. Robert Moskowitz Senior Technical Director ICSA Labs (248) 968-9809 Fax: (248) 968-2824 [EMAIL PROTECTED] There's no limit to what can be accomplished if it doesn't matter who gets the credit
Re: Palladium (TCP/MS)
On Wed, 23 Oct 2002 09:37:44 BST, Sean Jones [EMAIL PROTECTED] said: Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP record? (Perhaps it is me in my ignorance, or lack of understanding :o) ) It's not different. Or in any case, it's not sufficiently different to cause an interoperation problem in this case. The reference to RFC2821, section 10.2 was regarding the fact that having multiple PTR records for one address *IS* legal, despite widespread belief to the contrary. The original point was that you'll need a router ACL to block a lot more than one address, and keep the list of addresses up to date. And anyhow, using a router block is a bad idea in this case. There's two cases - either you still have machines using that vendor's software, and you WANT them to reach the servers so they can update, or you don't have the software installed, in which case you don't really care if the server is reachable.. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09151/pgp0.pgp Description: PGP signature
RE: Palladium (TCP/MS)
Well the first thing you have to realize is that there is no such thing as TCP/MS, and there for any answer you get would be highly speculative at best. This is a huge red herring, based on speculation that for some unknown reason, Microsoft will Embrace/Extend/Extinguish the IP protocol and successfully be able to put their own protocol (MS) onto the internet in such a way that you will be required to use a MS product to use the internet... I don't know about you but I find the whole scenario dubious at best, and this whole thread is becoming a massive troll Bill (Who is getting ready to take his lunch and eat it rather than feeding trolls) -Original Message- From: [EMAIL PROTECTED] [mailto:owner-ietf;IETF.ORG] On Behalf Of Sean Jones Sent: Wednesday, October 23, 2002 1:38 AM To: [EMAIL PROTECTED] Subject: RE: Palladium (TCP/MS) Good Morning Valdis Thank you for your prompt reply. Perhaps I did not phrase my question properly. I know what PTR records are, I know how TCP/IP works etc (I've done a routed IP network or two, and worked at an ISP for a while) so please let me re-phrase my question. Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP record? (Perhaps it is me in my ignorance, or lack of understanding :o) ) Regards Sean -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 22 October 2002 18:39 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said: Forgive my ignorance, but what the heck do you mean? % dig -x 207.46.230.218 ;; ANSWER SECTION: 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.net. 218.230.46.207.in-addr.arpa. 2665 INPTR www.domestic.microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR www.us.microsoft.com. Of course, it isn't that simple - those 4 PTR entries each point back at a multihomed host. I was about ready to throw a yellow flag and a 5-yard procedural penalty until I double-checked RFC2181, section 10.2 - that's legal. Gonna need a lot longer ACL on that Cisco to actually make it work (don't forget all their msft.net servers. Bringing it back to IETF territory now: Is there a need for an RFC for best practices in securing the download of software updates (DNSSEC, PGP signatures, etc)? The two scariest things about online updates (at least while wearing my security hat) are the MITM attack (as demonstrated against Apple) and the hacked download attack (as has hit windowsupdate, openssh, sendmail, and others). If it's WG fodder, I'd specifically declare the question of whether the patch *works* as off-topic - the task is merely verifying that the bits are the correct bits, and from the correct vendor. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Re: Palladium (TCP/MS)
[EMAIL PROTECTED] wrote: And anyhow, using a router block is a bad idea in this case. There's two cases - either you still have machines using that vendor's software, and you WANT them to reach the servers so they can update, That doesn't necessarily follow. I read a report (*) today that the EULA for XP/SP1 and 2000/SP3 states that, if you use automatic updates, you grant MS, and its designated agents, access to your software information--which is vague enough to include any data on your system. That's probably not what they intended, but the possibility is bad enough that financial and medical institutions in the US (and, probably, all companies in Europe) cannot legally use the automatic update systems, because they would be violating privacy laws. So a company might decide that they had to ban autoupdate, and do all updates manually, in which case it would be reasonable for them to block access to the update servers. (*) http://cin.earthweb.com/article/1,3555,10493_1485861,00.html -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Palladium (TCP/MS)
Christian Huitema wrote: Your fears appear to be based more on emotions than facts. To the best of my knowledge, the TCP/IP stack that ships in Windows conforms to the IETF standards and interoperates with the stacks that ship on other platforms -- it is certainly meant to. Several Microsoft employees participate to the IETF, volunteering a sizable amount of their time. Microsoft itself has a history of working with the IETF, including providing financial support to the RFC editor through ISOC. Christian, most of this note sounds like an apology of the form Microsoft is Okay because we give to charity, not because they do the right thing. If Microsoft is doing development on enhancements to the stack, this organization has good reason not to trust the results, based on past experience (i.e., Kerberos). Eliot
Re: Palladium (TCP/MS)
Thus spake Eliot Lear [EMAIL PROTECTED] Christian Huitema wrote: Your fears appear to be based more on emotions than facts. To the best of my knowledge, the TCP/IP stack that ships in Windows conforms to the IETF standards and interoperates with the stacks that ship on other platforms -- it is certainly meant to. Several Microsoft employees participate to the IETF, volunteering a sizable amount of their time. Microsoft itself has a history of working with the IETF, including providing financial support to the RFC editor through ISOC. Christian, most of this note sounds like an apology of the form Microsoft is Okay because we give to charity, not because they do the right thing. If Microsoft is doing development on enhancements to the stack, this organization has good reason not to trust the results, based on past experience (i.e., Kerberos). OTOH, does anyone have any evidence Microsoft is attempting to embrace and extend at or below the transport layer? This smells like a reporter's paranoia. Microsoft's application protocols (e.g. CIFS aka NetBIOS, Kerberos) are certainly problematic, but I've heard no complaints about their IP stack in several years. S
Re: Palladium (TCP/MS)
--On Tuesday, October 22, 2002 08:52:17 -0500 Stephen Sprunk [EMAIL PROTECTED] wrote: Microsoft's application protocols (e.g. CIFS aka NetBIOS, Kerberos) are certainly problematic, but I've heard no complaints about their IP stack in several years. Also, this entire paranoia stems AFAICT from the fact that it in XP (as opposed to earlier Windows releases) is possible to open raw sockets. Wow, what a security problem. -- Måns Nilssonhttp://vvv.besserwisser.org
Re: Palladium (TCP/MS)
From: Stephen Sprunk [EMAIL PROTECTED] ... OTOH, does anyone have any evidence Microsoft is attempting to embrace and extend at or below the transport layer? This smells like a reporter's paranoia. Microsoft's application protocols (e.g. CIFS aka NetBIOS, Kerberos) are certainly problematic, but I've heard no complaints about their IP stack in several years. Is PPP below transport? Some of us have memories of fun and games in the PPP working group, abeit several years old. Every outfit is vulnerable to the tempation to embrace-and-extend. Organizations such as Microsoft that are exceptionally provincial and unable to conceive of the possibility of networks that don't look like a single, large, well controlled corporate network are particularly vulnerable. (Recall the many mechanisms above TCP in Microsoft products that are almost criminal in the Internet but that might be good ideas inside the safety of big corporate networks.) An organization like Microsoft that has formally endorsed the idea and has a history of embracing-and-extending above transport and in non-network products cannot be expected to avoid the tactic below transport should it ever appear profitable, no matter how much it gives to charities including the ISOC and IETF. Again, other big organizations (specifically including Cisco) are not above embracing-and-extending out of ignorance, provincialism, and failures to bother to do interoperability testing (possible causes of the Microsoft PPP hassles) if not malice. Vernon Schryver[EMAIL PROTECTED]
Re: RE: Palladium (TCP/MS)
access-list 100 deny ip 207.46.230.218 0.0.0.0 12.246.56.92 0.0.0.0 gt 1 access-list 100 permit ip any any oh well. :) 10/21/02 9:37:42 AM, Haren Visavadia [EMAIL PROTECTED] wrote: If Microsoft can not produce secure products, what chance is there of them producing a secure protocol? IETF is more experienced than Microsoft at producing protocols.
Re: Palladium (TCP/MS)
On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said: Forgive my ignorance, but what the heck do you mean? % dig -x 207.46.230.218 ;; ANSWER SECTION: 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.net. 218.230.46.207.in-addr.arpa. 2665 INPTR www.domestic.microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR www.us.microsoft.com. Of course, it isn't that simple - those 4 PTR entries each point back at a multihomed host. I was about ready to throw a yellow flag and a 5-yard procedural penalty until I double-checked RFC2181, section 10.2 - that's legal. Gonna need a lot longer ACL on that Cisco to actually make it work (don't forget all their msft.net servers. Bringing it back to IETF territory now: Is there a need for an RFC for best practices in securing the download of software updates (DNSSEC, PGP signatures, etc)? The two scariest things about online updates (at least while wearing my security hat) are the MITM attack (as demonstrated against Apple) and the hacked download attack (as has hit windowsupdate, openssh, sendmail, and others). If it's WG fodder, I'd specifically declare the question of whether the patch *works* as off-topic - the task is merely verifying that the bits are the correct bits, and from the correct vendor. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09167/pgp0.pgp Description: PGP signature
Re: Palladium (TCP/MS)
On Mon, 21 Oct 2002 16:18:59 +0200, TOMSON ERIC said: And suppose that the majority of PC users connected to the Internet stop using TCP/IP and replace it with TCP/MS... I'll leave it as an exercise for the reader as to just how fast users will bail on Microsoft if they install TCP/MS and then find they can't reach AOL, Google, Yahoo, or Amazon, or any Cisco-powered site. Equally as critical - how fast the average IS director will ditch Microsoft once he/she discovers that TCP/MS won't talk to the Oracle database on the Solaris box... If it interoperates with TCP/IP, it's not an issue for us. And if it doesn't interoperate, it will resolve itself due to market forces. Not A Problem. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09156/pgp0.pgp Description: PGP signature
RE: Palladium (TCP/MS)
Microsoft doesn't have much control over the Internet. Well, Microsoft has some reponsiblity since they produce some the server software and client software.
RE: Palladium (TCP/MS)
Haren Visavadia [EMAIL PROTECTED] wrote: Microsoft doesn't have much control over the Internet. Well, Microsoft has some reponsiblity since they produce some the server software and client software. I certainly assume that MSN has control of its products and the quality there-of, and so bears responsibility to its customers for the bad behavior of what it sells. The fact that MSN has bought a majority mind share is critical here. Certainly, no non-market entity has much of any control over MSN stuff. So, the real problem is that the market is accepting the stuff that MSN sells, including the declarations of customer beware regarding any faults (including bad design choices) that the MSN stuff might contain. This includes massive propagation of the original IBM PROFS Christmas Virus type facilitation from back in the 1980's, where-in the PROFS mail system was given the privilege of allowing incoming messages run programs that can mail copies of themselves to everyone in the recipient's address book. I assumed back then that the lesson would be learned and the market would cure the design problem. But, my assumption was dead wrong. That FEATURE was stupid then and it is still utterly stupid, especially after almost two decades of network experience and $billions of wasted expense for the users of such stupid systems. A whole industry has grown up to deal with this one deliberate design flaw. But still, the rule is very simple: You Get What You Pay For! The main culprits are those large fortune 1000 companies that accept those strange terms of sale, which disclaim all responsibility for everything bad (and all he credit for all the good). They provide MSN with a substantial base market with huge influence over what everyone else needs to buy to interwork with them. Why else do you suppose MSN coddles them, and focuses support on them. Many of them are privileged to participate in beta testing, and no doubt receive superior technical support. In a way, they are being bought off. In any case, those beta testers seem not to be noticing that the basic deigns are bad! So, in my own small way, as a single individual, I refuse to actually use any MSN systems that deal with any Internet Protocols, such as mail or the web. If more people took such actions -- (instead of just using MSN stuff while complaining about it) -- the behavior of MSN might change. Indeed, you can get along very well without OE or IE, if you choose to. In my case, I simply forgo access to Internet stuff that requires MSN tools. If the provider does not want me to see what they mount for public viewing, it is fine with me, and thus it is their problem, and not mine! Of course, I know that MSN can hardly care less what I do, so I am only doing this to protect myself from their careless product designs. Even when I consulted for them for fee, they did not care what I wanted, and generally sent my checks to the wrong place, against the terms of my contract. As Herb Simon pointed out many years ago, and I paraphrase here: If you can figure out what is the incentive structure of a situation, you are a long way toward understanding what you can do about it. In my case, I simply cancelled my contract and went my own way. For some reason there is a massive desire (e.g., incentive) in MSN customer's minds to buy bad stuff, and this fact governs the outcome. If enough corporate Internet Users were to stop using MSN's bad stuff, their customers would soon enough notice their target audience's absence and mend their careless ways. My point is that we should ALL put our money where our mouth is;-)... The IETF is not in this loop, and cannot have any influence, therefore. It is simply not the IETF's mission to save the free world from itself. So, the IETF is not a party to the MSN Follies! The market is in control! So, go talk to the market! Cheers...\Stef
