December 2003 - cypherpunks-legacy

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

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

IDEA freeware
by A5713643665＠attpls.net 17 Dec '03

17 Dec '03

Dear Kipp, Please explain where this "freeware" IDEA code comes from. IDEA is a patented algorithm that cannot be used without a license. PGP comes with a license. I know of no other code in the US that has such a license. Tom

4 3

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 Amanda Walker 17 Dec '03

17 Dec '03

> 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. I think I'm starting to need a quick reference card :). > 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]. This is true. Just as an exercise, I'll give a description of the informal model that I have been using as I evaluate different proposals for secure HTTP (and other Internet security proposals). (1) I trust the network somewhat more than I trust the server machine. This is why I don't like SSL, for example. Now, I realize that this assumption is not a universal (someone in a college dorm would trust the server a lot more than the network), but the fact is that once you get off your organizational Ethernet, it's hard to monitor the Internet. On the other hand, servers are a problem. If someone's running a web page on Netcom, for example, I don't want to have to worry about whether or not they've been broken into this week (note that I'm using Netcom strictly as an example--the same concern holds for any public access system). I want to be able to authenticate the content I am viewing without having to worry about whether or not the transport & server systems have been compromised. I'm still vulnerable to a denial of service attack, of course, but at least I can tell when I do get something that it is genuine. This concern holds even when I don't care if the content is encrypted. If I get sales literature, I want it signed by the organization it claims to be from, and so on. And for this purpose, I like X.509. Self-signed certificates are fine, if there are other ways to verify the public key. Signed PGP keys could be used as certificates as well, of course. (2) I want authenticated content all the time, even if it's just to an anonymous key pair I've gotten through some other channel. (3) I want private content sometimes. When I want private content, I want end-to-end privacy, not just transport level privacy. (4) Occasionally, I want transaction security (sending a credit card order, for example), where I want the transaction to be encrypted, signed, and not subject to playback attacks. Ideally, the server itself won't be able to decrypt it--only the actual recipient will. In all cases, I expect the network and the server machines and software to be insecure. Anything else is simply unrealistic. Amanda Walker

1 0

Re: BofA+Netscape
by jgrubs＠voxbox.norden1.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Rick Busdiecker <rfb(a)lehman.com> writes: > Even Apple & Microsoft agree that Netscape is brain dead... Is that the same Microsoft that brought us Edlin??? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu3Lud74r4kaz3mVAQEWvwQAp/fQ5DmE28saQziqd+AJU9RIaqc9lQ8k /oDfOGLmA9RFL1R1hHbTBmQqd+rdjZgtW+o1J9WTMZ3ttoR03G8Nhr7gtrZncMTD /OmL7BmKGQTjp24MsIXk+oBdpyN/X1VqNrGZvuK9/GIDpkEA5d7Q8qlAHLYDRkv8 KcGJBMRRBFU= =0gC5 -----END PGP SIGNATURE----- ... "The greatest dangers to liberty lurk in the insidious encroachment of men of zeal, well meaning but without understanding." - Justice Louis Brandeis -- jgrubs(a)voxbox.norden1.com (James C. Grubs, W8GRT) Voxbox Enterprises, 6817 Maplewood Ave., Sylvania, Ohio 43560-1956 Tel.: 419/882-2697

2 1

Re: Hal Finney & Bob Rae and Ontario's Parliament
by jgrubs＠voxbox.norden1.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Richard Martin ( frodo ) <g4frodo(a)cdf.toronto.edu> writes: > Mea culpa. I was thrown by the US government's free use of it (I think > they get that, don't they?). On a silly note, my government is not > currently making money, and could hardly be classified as being in > business. ;) At least yours isn't planning a going out of business sale.... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu3PWd74r4kaz3mVAQHJ5AP/WbDZL2bM1Dn8GuNcOSRkM9PTR75oGOwb fg2dwp95pojg9DWsmRuhiydX4l+Jb0tXdCNn/J/Xou5/ABBQ7vngyVbK90Inv6Sq Dahptd8jXKyHQvz0xex3Jmd81+KXhM4DIR7f8dMEs3NDVzwgORnUlCvJQg116dJO j+kTyHCzGd0= =vPKv -----END PGP SIGNATURE----- ... "The greatest dangers to liberty lurk in the insidious encroachment of men of zeal, well meaning but without understanding." - Justice Louis Brandeis -- jgrubs(a)voxbox.norden1.com (James C. Grubs, W8GRT) Voxbox Enterprises, 6817 Maplewood Ave., Sylvania, Ohio 43560-1956 Tel.: 419/882-2697

1 0

Authentication vs encryption: CPs on the web
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I notice in these discussions of security on the web that the topic blurs back and forth between authentication and encryption. Particularly when discussing using MIME with security extensions to "secure" a document by pre-signing it, this form of security does not add privacy. It does provide a useful service by allowing you to verify authorship, but my interests are in using cryptography to protect privacy. I think it is useful to keep a clearer distinction between these. I notice that the people who come to this topic from an institutional point of view tend to be more interested in the authentication aspects. This seems to fit better into the control-oriented mindset. With authentication you can track what people are doing better; non-repudiable signatures could actually work in some ways against the signer. I think that may be one reason Phil Zimmermann is famous for not signing his messages. :-) But encryption can actually work against institutional interests (compared to individual ones) by making it harder to keep track of people's activities. I exchanged email on this with Vint Cerf during the PEM standardization process. I objected to the fact that with PEM you could not encrypt a message unless you signed it. Now of course you can always fake the signature if you need to but the principle seemed skewed to me. Cerf honestly could not understand why you would ever want to do this. What security could there be if the message were not signed, he wondered. To me the issues are separate. Encryption is used to make sure the message is seen by only those for whom it is intended, and signatures are used to verify the source of the message. The choice of which of these two transformations to apply should be up to the users. I don't speak for other cypherpunks, but my interests with regard to web security extensions would lie in the following areas. I want to be able to use the web and maintain my privacy. I don't want snoopers on the net or on my local machine to know which web sites I visit or what material I download. (This ties into the electronic cash issue - what use is "anonymous" cash if everyone can see where I'm spending it and what I'm buying?) I also want to be able to hide my identity from the web servers themselves, at least if this is mutually agreeable. If a server wants to accept only authenticated connections where it knows who the users are that it is serving, fine. But I want the options to be there. I want to be able to make payments to access and download information while protecting my privacy. I don't want to be put onto mailing lists or get my name into databases of people who like X without my permission. This implies a range of payment mechanisms including credit cards, digital checks, and digital cash. And it also requires the privacy and anonymity features above. I want these features to be a matter of mutual negotiation between client and server. The protocols should not build in veto power for either side over how much privacy the transaction includes (although either side may choose not to participate if mutually agreeable terms can't be worked out). And therefore these features should not be restricted to just a small fraction of transactions, where we drop into "secure mode" momentarily so I can send my credit card number. I want to be in secure mode all the time. This is IMO the standard cypherpunks wish list as applied to the WWW. But it does not seem to match up with either the commercial or institutional interests which are driving the standards process. I hope those CP's who are involved in these efforts can work to spotlight the need for individual privacy. We should give as much power, choice, and control as possible to the individual end-users of the web. Otherwise privacy is going to be very difficult to maintain in this world of electronic commerce. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLu3dHRnMLJtOy9MBAQGZlwH+PYN4FahcHflm4XFPkaJE3h/QLY3lMZV5 BY4U7w7OwpVSTEUqDKd7SvjIg4tt14QI/DGGj0jyHbIS9lWew8U3rQ== =QbAD -----END PGP SIGNATURE-----

2 2

More 40-bit RC4 nonsense
by raph＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- If I recall correctly, the first byte out of the RC4 stream has about a 40% chance of being the first byte of the key. Thus, if the 40-bit "secret" part of the key is the _beginning_ of the full 128-bit key, then the keyspace is effectively reduced by about seven bits, meaning that I would be able to crack a key on my PC in a couple of days or so. Of course, if the "clear" 88 bits went first, there would be no advantage whatsoever. The SSL document very carefully does not say how they combine the two key parts to form the 128-bit key. Does anyone know? Raph -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLu3cI/4BfQiT0bDNAQEToQQAtcy2v0sBd+g5GBrm+Pa1AykqS4tTctfu EYga7kPry4wvGmI7/HpD+SVVDQRcJe+O9CxH9cpvRgBRIBhyvsFXVBSTW0OTJgXb 1bYh5qerD5J/gXAs0XWIp0+Hj8GqeTIRkFTseU4MDcDfQ7tOSEFvul97iSNYIytX AMkmAEmMXxU= =S80T -----END PGP SIGNATURE-----

3 2

Re: Clarification of my remarks about Netscape
by kipp＠warp.mcom.com 17 Dec '03

17 Dec '03

In article <199412130729.XAA01473(a)jobe.shell.portal.com>, you write: > -----BEGIN PGP SIGNED MESSAGE----- > > It is nice to have a lot of people on the list from Netscape. > Here is a question about SSL relating to the use of certificates: > > + The issuer name must resolve to a name that is deemed > acceptable by the application using SSL. How the application > using SSL does this is outside the scope of this memo. > > What does Netscape actually do about this? If I want to make a server > which will interoperate with existing Netscape clients what kind of > certificate do I need, and what kind of name should be in there? > Thanks - > > Hal Finney > hfinney(a)shell.portal.com > > -----BEGIN PGP SIGNATURE----- > Version: 2.6 > > iQBVAwUBLu1NOxnMLJtOy9MBAQGItwIAr4eerI+FSmPpOIcwITepnXzcUUFkPwsK > +Rz2FC4Y6hV0HoDEt1JnpvCPVV5N74Jtc9xMmF8CcRlBybk25PkxVQ== > =LOql > -----END PGP SIGNATURE----- Because online directory services are not one of the extant solved problems on the Internet, Netscape uses a simple approach - a small set of "important issuer" certificates are compiled into the browser. A future release will support "key rings" ala PGP. This is all we had time for in this release... All you need to do is get your server certificate from one of several places, including: RSA (commercial CA or server CA) Netscape (not likely; we can't afford the liability) MCI (I don't know if they are selling this). So the short answer is: it's hard to do right now. In six months it should be a very different scenario. --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp(a)mcom.com http://www.mcom.com/people/kipp/index.html

1 0