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: [isdf] Palladium (TCP/MS)
T == TOMSON ERIC [EMAIL PROTECTED] writes: T Is Palladium (TCP/MS) a real/serious threat? As compared to a skilled sniper in a white van? No. T Do we have to be afraid of it? Let me reframe this in another perspective: If you put razor blades in your mouth, should you be afraid of damage? Yes, but I'm forced to ask: /WHY/ put them in your mouth in the first place? With Palladium, your answer is because Bill Gates told me to ... and you can see how juvenile the risk is -- an excuse like that was acceptable in junior kindergarten, but is it still acceptable from grown adults? This is the same Billy boy who gives you a free Elvis Costello CD with exciting new tracks, and once you insert it into your PC, your Windows XP is /forever/ controlled by Microsoft's notions of DRM. This is the same Billy boy who sells you a core infrastructure email server that is a /magnet/ for the trojans, virii and worms that cost your economies /billions/ in _unnecessary_ downtime. When I was in gradeschool, I quickly learned to avoid those sorts of class clowns. As an adult, I continue to do so. Next time you're standing in line to buy more bugfixes (er ... 'upgrades') just ask yourself am I doing this because _I_ want it, or because Billy boy /says/ I want it? -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.auracom.com/~teledyn - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
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
FW: Global PKI standard?
-Original Message- From: Franck Martin [mailto:franck;sopac.org] Sent: Wednesday, 23 October 2002 10:31 To: [EMAIL PROTECTED] Subject: Global PKI standard? Hi all, I have promised to send something about my views on how to establish a global PKI. Here it is. The document started from a simple question on the IETF list, on why not use DNS to help establishing a global PKI. I kind of tried to write it as an RFC, but I'm not yet good at it... I think this document gives some good bases of discussion and implementation, but please only positive criticism. If something is wrong, propose a way to fix it... There is one part yet I haven't figured out is, how to place a constraint in a certificate so that it can sign only certificate which are lower in the X400 naming scheme... Certificate dc=org,dc=isoc can sign dc=org,dc=isoc,dc=lists but not dc=org,dc=sopac Cheers [EMAIL PROTECTED] PS:The original file I'm working with is the Lyx file. PPS: Check the SSL-Certificates HOWTO on www.tldp.org RFCgPKI.lyx Description: application/lyx !DOCTYPE book PUBLIC -//OASIS//DTD DocBook V4.1//EN [ !entity header system header.sgml ] book lang=en!-- DocBook file was created by LyX 1.2 See http://www.lyx.org/ for more information -- bookinfotitleGlobal PKI/titledate22 October 2002 /dateauthorfirstnameFranck/firstnamesurnameMartin/surname/authorabstractparaThis document proposes a standardisation of the method used with a DNS as an helper to locate Secure Certificates. It also explains how to generate coordinated certificates following the Domain Name tree. This document provides a method to add tracability to Internet exchange throught a common usage of certificates./paraparaThe key words quot;MUSTquot;, quot;MUST NOTquot;, quot;REQUIREDquot;, quot;SHALLquot;, quot;SHALL NOTquot;, quot;SHOULDquot;, quot;SHOULD NOTquot;, quot;RECOMMENDEDquot;, quot;MAYquot;, and quot;OPTIONALquot; in this document are to be interpreted as described in RFC 2119 lsqb;RFC2119rsqb;./para/abstract/bookinfo chaptertitleIntroduction/titleparaAll the tools are in place for providing a global Public Key Infrastructure (gPKI) but so far gPKI has lacked implementation through coordination. Certificates have a LDAP (X400) naming style scheme but few LDAP servers are linked together in a coordinated fashion. At the moment the only system which is structured, unique and reliable is the Domain Name Server Architecture. A coordinated usage of the DNS would allow to locate certificates and public keys prior to any transaction on the Internet. This could be usefull for IPSec, but mainly to S/Mime. At the moment, the usage of certificates is limited to a few websites. Certification in e-mail is lacking a wide use due to the lack of coordination in implementing Public Key Infrastructures./paraparaThis document proposes a method to implement a gPKI where individual PKI would be located through the DNS system. Each PKI legal role would be limited to a role of tracability. At the level of a PKI the reposibility of such PKI would be able to legally identify the entities for who the certificates have been issued (tracability). The role of the gPKI is not to offer security, nor to ensure the security asoociated with the issuance of certificates but to be able to provide information so that any Internet transaction secured with such certificate can be traced to a legal entity./para/chapter chaptertitleDNS structure and Certificates/titleparaThe DNS Infrastructure is composed of a root (.) which points to sub domains usually divided into 2 groups, the country code Top Level Domains (ccTLD) and global Top Level Domains (gTLD). Each TLD is then subsdivided in sub-domains and so on. This architecture forms a tree. An entity can be responsible of one to many domains with parent links or not. Each domain is served by 2 to many hosts acting in master/slave role or cooperatively in a distributed fashion./paraparaThe main importance of the DNS Infrastructure is that there is only one root domain, which is widely accepted and recognised by all hosts on the internet./paraparaThe Public Key Infrastructure follows the X400 naming scheme which also provide the possibility of organising each zone in a tree structure. This scheme is usually supported by LDAP which is the tool designed to provide information following an X400 naming scheme. Unfortunately very few LDAP servers are set up cooperatively./paraparaHowever there has been several attempts to map DNS tree to LDAP tree, one of this scheme is to associate the domain name with dc fields. For instance the domain name ldquo;company.com.kirdquo; could be mapped to ldquo;dc=company,dc=com,dc=kirdquo;./paraparaSo if each certificate contains in its subject this string, then it is easy to query the right entry in the DNS infrastructure. In reverse each DNS must be able to point to a PKI repositery. This is done via the CERT record type lsqb;RFC2538rsqb;./para/chapter chaptertitleConsiderations and
