December 2003 - cypherpunks-legacy

Bionomics Institute -- New discussion group and newsletter
by Steve Gibson/Bionomics 17 Dec '03

17 Dec '03

How is new technology transforming the economy? How will it alter the fundamental qualities of economic life? We don't have all the answers. But we do have a powerful new way to look at the the revolutionary changes brought about by the emergence of the Information Age. And, we have leading edge thinkers and doers from a remarkable variety of disciplines -- high-technology, biology, economics, public policy, business and more -- who share the powerful idea that the economy is an ecosystem. That's right: the economy is _not_ some giant machine. It's like a rainforest. A virtual rainforest where coded information, like DNA, defies entropy. Where organizations (like organisms) cooperate, compete and evolve in a complex, self-organizing process that is not only unplanned, but unplan-able. (Sounds like the Internet, doesn't it.) And, now, we have a discussion group: evolve(a)bionomics.org. As well as an occasional newsletter: just.the.facts(a)bionomics.org. JOINING -- send to info(a)bionomics.org with "SUBSCRIBE Evolve" or "SUBSCRIBE Just.the.facts" in the subject line. Participants in "Evolve" will get "just.the.facts" automatically. CONTRIBUTING -- send to evolve(a)bionomics.org. This is an archived, quasi-moderated discussion. Signal-to-noise will be kept high. VANISHING -- send "unsubscribe" or any questions to info(a)bionomics.org or to our domain postmaster, klacobie(a)bionomics.org. This message comes to you because either we read this list or people keep telling it's right up our alley. Now we want you to come explore the truths and consequences of the infoweb with us. And bring your friends. (If you don't have any friends, you're probably spending too much time reading email.) You made it this far... hit <reply> and take a lurk. Become a part of the bionomic community, where high-technology and the free-market converge. Regards, Steve Gibson Executive Director The Bionomics Institute

1 0

re: IPSP and Netscape
by John Giannandrea 17 Dec '03

17 Dec '03

Eric Hughes writes: > It may be that IPSP is not the quickest or best way to link security, but > that is not the point I am making here. The original denial of IPSP's > potential utility was made in complete ignorance Widespread acceptance of IPSP may well make SSL irrelevant. I do not believe that anyone at Netscape is claiming otherwise. Nonetheless, widespread implementation of IPSP simply does not exist at this time. We need a solution for our customers _today_. SSL is one working solution to the problem of link security. By publishing our specification of SSL we are inviting others to share in our work, or criticize us for being foolish. I do not believe that we are either arrogant nor ignorant in creating SSL. The market will, of course, help decide. -jg

2 1

ABSOLUTELY NOTHING ABOUT ERIC OR JAMES IN THIS POST...
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Paul Ste. Marie offered an interesting suggestion to the use of vital signs transmitted from wired cops: ... such a device would, when worn by an officer in court, essentially become a broadcast polygraph... Tim May is correct that a "broadcast polygraph" is not planned by Fleming and Co. However, they do contemplate at least sampling vital signs using their technology. Since my opinion is that polygraphs are almost totally useless for detecting deception, I think the same would apply in spades to broadcast vital signs. In addition, all that is planned for the localizer is pulse and maybe blood pressure. That's enough to see if the officer is in trouble (or engaged in sexual activity, by the way), but not enough to test his/her veracity. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

dr. dobbs - where?
by being 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- i'd like to know where i can find dr. dobbs. i came up with a lot of stuff (52 hits actually) using gopher but i'd prefer some sort of mailing list or even better, a WWW page for it. of course, if there is a std ftp site i'd go for that as well. basically, i'm easy to please. i just want to read the crypto articles mention by bruce. life, you see, is not meant to be enjoyed. -me right now pfinerty(a)bach.seattleu.edu finerty(a)msscc.med.utah.edu finger any acct. for pgp key pfinerty(a)nyx10.cs.du.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBLu1UMbJv5rDIkn05AQGLVQH/RTZJaIU6Do1xCfU2RG586SzJZJFh6/Pb J5cG+j/zswDt/5hxmFxUl3Vk1zSMWERoo7mLP3c4s9jTuLmr7s+wOw== =xxA+ -----END PGP SIGNATURE-----

3 2

Transport layer security in a Freeh country
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

It's nice to see some technical discussion for a change. I guess one reason transport layer security seems irrelevant to Cypherpunks is that it isn't secure. Not necessarily from a cryptographic point of view, but in its procedure. For example, the Digital Telephony Bill avoided acting against Internet providers _this_ time. Being provided by the carrier, transport-layer security is succeptable to LEA arm-twisting. It may be so even now despite DT's current form. Such sabotaging of end-to-end security is much tougher, if not impossible, and with end-to-end security, transport security is redundant and possibly a painful overhead. (This is quite apart from the other hassles - proxies need to be changed etc - which only exist with transport security.) As for James Donald's criticism of the IETF for not extending HTML to support end-to-end security, well, MIME already exists. "We know everything about you that we need to know" - Coleta Brueck, IRS ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Re: IPSP and Netscape
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

>One may be a reasonable inference, as I inferred >that Chomsky sought to justify mass murder and >brutal terror. The other is a lie. Somebody make him stop! Please! -j -- On the internet, no one knows you're a deity. ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com> After December 16th ---------> <foodie(a)netcom.com>

1 0

Re: HTTP security
by Amanda Walker 17 Dec '03

17 Dec '03

> This seems a very relevant criticism: Has Amanda, or anyone else > proposed an extension to HTML that would incorporate such things? Actually, it's not an extension to HTML, but to MIME (whose formats HTTP uses top tag and label data), and it just went to Proposed Standard (the last step before Internet Standard). The MIME multipart/signed and multipart/encrypted body parts allow anything using MIME encapsulation to sign and/or encrypt arbitrary body parts. Since it's at the document layer, it requires no special transport software, works with existing proxies and caching servers, and allows secure HTTP software to share code with secure email software (since it would use exactly the same formats). The framework is general enough to allow use with either PEM-compliant signatures and encryption or others (such as PGP). I believe that can also be used with symmetric key management, which could be useful for special purpose applications. EInet's secure SHTTP proposal is also an end-to-end security framework. Amanda Walker InterCon Systems Corporation

2 1

Re: Clarification of my remarks about Netscape
by Amanda Walker 17 Dec '03

17 Dec '03

> Amanda, we're not trying to push anything into the standards track. > We're publishing SSL as an informational RFC, and we have > separately submitted SSL as a proposal to the W3O working group > on security (in parallel with SHTTP and a handful of other > proposals). Nothing is being pushed into the standards track. Aha. This was not particularly clear from my reading of the SSL spec and the other stuff about SSL on your WWW server. If you're just issuing an informational RFC, then I have just become much less annoyed. Amanda Walker InterCon Systems Corp.

2 1

Correction
by ekr＠eit.COM 17 Dec '03

17 Dec '03

My previous message about HTTP Security implied that you would (in SHTTP) reuse the DEK from say an HTTP request for the reply. You most certainly would not do this. (It's horribly bad key hygiene.) Rather, SHTTP provides a way to exchange a symmetric encryption key (in an HTTP message) that can subsequently be used cover subsequent DEKs. Sorry for the possible confusion... -Ekr

1 0

Re: HTTP security
by ekr＠eit.COM 17 Dec '03

17 Dec '03

See what happens when you call my name (or at least try to...) James is > Amanda is >> >> This seems a very relevant criticism: Has Amanda, or anyone else >> proposed an extension to HTML that would incorporate such things? >Actually, it's not an extension to HTML, but to MIME (whose formats HTTP uses >top tag and label data), and it just went to Proposed Standard (the last step >before Internet Standard). The MIME multipart/signed and multipart/encrypted >body parts allow anything using MIME encapsulation to sign and/or encrypt >arbitrary body parts. Since it's at the document layer, it requires no >special transport software, works with existing proxies and caching servers, >and allows secure HTTP software to share code with secure email software >(since it would use exactly the same formats). The framework is general >enough to allow use with either PEM-compliant signatures and encryption or >others (such as PGP). I believe that can also be used with symmetric key >management, which could be useful for special purpose applications. Uh, PEM-MIME no longer supports symmetric key management. >EInet's secure SHTTP proposal is also an end-to-end security framework. Actually, it's EIT. EInet is an MCC (the people who did MacWeb, not to be confused with MCOM, the people who did Netscape. Confusing, ain't it?) project. Anyway, the approach that Amanda describes is pretty much the one that SHTTP takes. We use already established encapsulation formats to do data encapsulation. SHTTP can be used to enhance either entire protocol messages or objects or both. (You can do both in the same message using a recursive encapsulation). I think Amanda has done an adequate job of talking about end to end security, so I won't talk about that. I would like to briefly motivate why just using PEM-MIME isn't enough, though. (We considered it and believe me it would have been a lot easier on our brains and fingers...) PEM-MIME and to a lesser extent PGP are basically cryptographic messaging formats intended for email type applications. However, the email model is fundamentally different from the Web model in a number of ways. Let me just give one example: In the email world, you don't necessarily have any sort of prior relationship with the person you're communicating with and that public key cryptography is relatively cheap. (When it takes minutes to ship mail across the net, who's going to notice a second or two of signature verification?) However, in the case of the Web, things are very different. When a server replies to one of my requests, we have definitely exchanged at least one message. Now, assume for the moment that my request was encrypted and that I desire confidentiality for the reply. There is no need for the server to perform public key crypto because we've had the opportunity to exchange a key already. This means a substantial performance improvement. [It incidentally means that a server and I can communicate privately even if I don't have a key pair]. When I say that just PEM-MIME is inadequate, I don't mean to imply that using it is inadequate, however. On the contrary, we use PEM and PKCS7 already and are gearing up to include PEM-MIME, now that it's going to proposed standard. [Incidentally, there's no reason you couldn't use PGP too, although I propose that it's most useful in the proposed PGP-MIME multiparts...] And you should be able to reuse your PEM-MIME engines to write SHTTP handlers. It's just that we also took on some issues that we thought were important that we couldn't steal solutions for.. -Ekr

2 1