Re: Clarification of my remarks about Netscape
[I'm sending this to the list because it does have some crypto content] "Kipp E.B. Hickman" <kipp@warp.mcom.com> writes:
There is no need to bypass existing efforts just to add cosmetic value to your own software.
This has nothing to do with security...
Agreed. My annoyance with Netscape is not based solely, or even primarily, on security concerns. In fact, my only annoyance with your security proposal is that it is at the wrong layer (or, more accurately, at layer which should be secondary). In my view, you picked the right technology, but applied it to the wrong problem :).
Clearly I'm an idiot. Explain it to me.
SSL is a mechanism whereby a client and a server can establish a secure, authenticated transport channel. The problem is that this isn't what I want to secure and authenticate. Most of the time, in fact, I don't care about the transport: I may be talking through a proxy (like the current CERN httpd), or bringing things in from a cache, or talking to a load-balanced server array. I want the *documents* I'm accessing to be secure and/or authenticated. I want my HTML documents signed and certified by the *author*, not the server. I couldn't care less about the server if I can verify that I've got the right document in response to my query. Similarly, if I send the contents of a form containing, say, my Amex number, I want to encrypt the session key with the public key of the merchant, not the service provider. This is what I (and many others) mean by an "end to end security model." Transport security is a nice secondary ability (it helps defend against traffic analysis, for example, and casual snooping by students with packet sniffers), but without end-to-end security, it's simply a way of providing a false sense of security. I wouldn't want to do away with the TCP checksum field simply because the modem I use for my SLIP link is "error-correcting," and I feel the same way about security.
I put my email address in there for that very reason. Jeesh.
I'd rather that technical feedback occur in a public forum like the IETF. I have no pretensions about being a security expert, and I want people to shoot down my bad ideas too. Heck, I *like* having my competitors tell me what's wrong with my ideas :).
This serves as a direct barrier to competition from other commercial vendors.
This is an outright lie. We don't use TIPEM. You could build a conformant SSL implementation using RSAREF and the freeware IDEA cipher code.
Nope, not if I want to sell it (note the word "commercial" in my comment). RSAREF cannot be used for commercial software, nor can IDEA under the PGP license. There is no feasible way to license the RSA patents for commercial use except by licensing TIPEM. I have been told this outright by Kurt Stammberger of RSADSI (their VP of marketing, I believe). This is not secondhand information. All commercial software that I know of using RSA public key encryption and RSA stream ciphers (such as RC2 and RC4) uses TIPEM and BSAFE, including Lotus Notes and Apple PowerTalk. RSA's royalty structure is based on a percentage of revenue, with the percentage on a sliding scale based on gross corporate revenue (not just on products which use RSA's patents). If you keep your margins low to compete in the marketplace, you lose. Even you folks are making your money on high-margin products (servers) rather than low-margin ones (clients), I'd wager at least in part because it's a way to make money despite having to pay RSA royalties. The RSAREF license has been loosened up some recently, but it's still restricted to freeware.
As for a barrier to competition. So what else is new? We all have barriers to overcome before we can compete. Should we get rid of TCP/IP as a barrier to using the web?
I don't have to pay royalties to sell an implementation of TCP/IP. Your analogy fails.
You are somewhat right here. In fact, this was done because we are a company interested in surviving long enough to withstand the eventual attack by microsoft.
You've already got your eggs in the right basket on this one--sell servers and services, not client software. Microsoft has a miserable track record in the server arena (witness the underwhelming success of Windows NT :)). It's also less of a commodity market, which is where Microsoft excels (no pun intended).
As a result we received critical review from some decent members of the crypto community, including:
Martin Abadi Mike Burrows Alan Schiffman Matt Robshaw Burt Kaliski
Mostly RSADSI people, by my count. Great technical background, but I wouldn't call relying on one of your technology vendors "peer review"...
As for the IETF standards process, we are pushing the document into the RFC process.
Precisely. Rather than working with others in the industry and research communities, you are trying to push your proposal into the standards track.
The market will decide one way or the other.
On this I agree completely. Amanda Walker
Subject: Re: Clarification of my remarks about Netscape [I'm sending this to the list because it does have some crypto content]
"Kipp E.B. Hickman" <kipp@warp.mcom.com> writes:
There is no need to bypass existing efforts just to add cosmetic value to your own software.
This has nothing to do with security...
Agreed. My annoyance with Netscape is not based solely, or even primarily, on security concerns. In fact, my only annoyance with your security proposal is that it is at the wrong layer (or, more accurately, at layer which should be secondary). In my view, you picked the right technology, but applied it to the wrong problem :).
Clearly I'm an idiot. Explain it to me.
SSL is a mechanism whereby a client and a server can establish a secure, authenticated transport channel. The problem is that this isn't what I want to secure and authenticate. Most of the time, in fact, I don't care about the transport: I may be talking through a proxy (like the current CERN httpd), or bringing things in from a cache, or talking to a load-balanced server array. I want the *documents* I'm accessing to be secure and/or authenticated. I want my HTML documents signed and certified by the *author*, not the server. I couldn't care less about the server if I can verify that I've got the right document in response to my query. Similarly, if I send
On Dec 12, 6:11pm, Amanda Walker wrote: the
contents of a form containing, say, my Amex number, I want to encrypt the session key with the public key of the merchant, not the service provider.
I believe that these properties of document security are orthogonal to transport security. Today we have bit off transport security. Using MIME multipart encoded documents, document security can be handled as well. There already exist standards defining the format for these (PEM etc.), all that is missing is a browser that adheres to them, and some server based tools for creating them. SSL combined with those provides a powerful solution to todays Internet problems (jeesh, now *I'm* starting to sound like a marketing person :)
This is what I (and many others) mean by an "end to end security model." Transport security is a nice secondary ability (it helps defend against traffic analysis, for example, and casual snooping by students with packet sniffers), but without end-to-end security, it's simply a way of providing a false sense of security. I wouldn't want to do away with the TCP checksum field simply because the modem I use for my SLIP link is "error-correcting," and I feel the same way about security.
Agreed. However, today, we consider it a primary concern instead of a secondary concern. To do business on the Internet, people will be filling in forms and submitting data that is sensitive to server operators. We don't want that data to be observered in transit. Data that is paid for should also be private.
I put my email address in there for that very reason. Jeesh.
I'd rather that technical feedback occur in a public forum like the IETF. I have no pretensions about being a security expert, and I want people to shoot down my bad ideas too. Heck, I *like* having my competitors tell me what's wrong with my ideas :).
I tend to agree here, but before I open something up to wide discussion I prefer to have a smaller group doing the review work. After the small group work has been done, then a larger review follows.
This serves as a direct barrier to competition from other commercial vendors.
This is an outright lie. We don't use TIPEM. You could build a conformant SSL implementation using RSAREF and the freeware IDEA cipher code.
Nope, not if I want to sell it (note the word "commercial" in my comment). RSAREF cannot be used for commercial software, nor can IDEA under the PGP license. There is no feasible way to license the RSA patents for commercial use except by licensing TIPEM. I have been told this outright by Kurt Stammberger of RSADSI (their VP of marketing, I believe). This is not secondhand information. All commercial software that I know of using RSA public key encryption and RSA stream ciphers (such as RC2 and RC4) uses TIPEM and BSAFE, including Lotus Notes and Apple PowerTalk. RSA's royalty structure is based on a percentage of revenue, with the percentage on a sliding scale based on gross corporate revenue (not just on products which use RSA's patents). If you keep your margins low to compete in the marketplace, you lose. Even you folks are making your money on high-margin products (servers) rather than low-margin ones (clients), I'd wager at least in part because it's a way to make money despite having to pay RSA royalties.
I think RSA pulled a fast one on you. We don't use TIPEM. We wrote the X.509 handling code ourselves and have tested it for interoperability. In any case, there are two classes of net consumers out there: the academia and corporation. The academia can almost always get access to source code for free and reuse it interesting manners with little trouble, as long as it's academic. Us business types get stuck paying for everything (of course we make a living that way too...). It doesn't bother me that people would have to license RSA technology to implement SSL commercially. We did, and in some sense it levels the playing field. However, in defense of SSL, I must say that there is no strict requirement for RSA technology. A careful reading of the spec will lead one to discover that different public-key technologies can be used. Since certificates are typed, and standard X.509 certificates include algorithm identifiers, it is possible to implement a different authentication mechanism that doesn't use RSA technology. For example, to choose some popular choices (:^), one could use SHS instead of MD5, skip-jack instead of RC2/RC4/IDEA and some other freely available public key algorithm.
The RSAREF license has been loosened up some recently, but it's still restricted to freeware.
As for a barrier to competition. So what else is new? We all have barriers to overcome before we can compete. Should we get rid of TCP/IP as a barrier to using the web?
I don't have to pay royalties to sell an implementation of TCP/IP. Your analogy fails.
My point was that in order to even play on the internet, one needs a computer, a network connection, and TCP/IP, *PLUS* all of the various software that one wishes to use to communicate. This is not free. It is being paid for by you whether you do it directly, or it is built into the margins of the hardware manufaturer that sold you the machine.
You are somewhat right here. In fact, this was done because we are a company interested in surviving long enough to withstand the eventual attack by microsoft.
You've already got your eggs in the right basket on this one--sell servers and services, not client software. Microsoft has a miserable track record in the server arena (witness the underwhelming success of Windows NT :)). It's also less of a commodity market, which is where Microsoft excels (no pun intended).
As a result we received critical review from some decent members of the crypto community, including:
Martin Abadi Mike Burrows Alan Schiffman Matt Robshaw Burt Kaliski
Mostly RSADSI people, by my count. Great technical background, but I wouldn't call relying on one of your technology vendors "peer review"...
Actually, 2 people from DEC, one from EIT and 2 from RSA.
As for the IETF standards process, we are pushing the document into the RFC process.
Precisely. Rather than working with others in the industry and research communities, you are trying to push your proposal into the standards track.
I'm listening! What is wrong with SSL? What defects does it have in the way that it tries to solve privacy and authentication? What should we do to make the next version better? -- --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp@mcom.com http://www.mcom.com/people/kipp/index.html
Kipp E.B. Hickman writes: | I'm listening! What is wrong with SSL? What defects does it have in the way | that it tries to solve privacy and authentication? What should we do to make | the next version better? The first thing you need to do is define a threat model. Make explicit your assumptions. What needs to be trusted, and when? Who are your threats? What are your assets, and what are they worth? Next, you should publish the model, and let us rip it into little shreds. This is hard on the ego, but good for your threat model. No one ever thinks of everything. Iterate here. This is where the time & effort belong. Once you have a solid threat model, you should see what protocols and tools are out there that can be used to defend against those threats. I suspect that most of the tools you will find you need exist. Some will not. Having found what wheels don't need to be invented, you need to code your solutions. Then you need to publish that code to allow the security community to decide whether or not to trust it. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Amanda Walker criticezes SSL because it is irrelevant to the threat that people are likely to be concerned about.
SSL is a mechanism whereby a client and a server can establish a secure, authenticated transport channel. The problem is that this isn't what I want to secure and authenticate. [...] I want the *documents* I'm accessing to be secure and/or authenticated. I want my HTML documents signed and certified by the *author*, not the server. I couldn't care less about the server if I can verify that I've got the right document in response to my query. Similarly, if I send the contents of a form containing, say, my Amex number, I want to encrypt the session key with the public key of the merchant, not the service provider.
This is what I (and many others) mean by an "end to end security model."
This seems a very relevant criticism: Has Amanda, or anyone else proposed an extension to HTML that would incorporate such things? for example: <ENCRYPT ALG=soandso PUBLICKEY=87hfkjjhfd98uyeuihdhiucschhuichcxzcxhjcxjlcx fkfdhfhjdhjkvcccv3454DFFl l79*79 y978yy98gk gkghgksdghsdkghasdsak> Encrypted and possibly signed material. </ENCRYPT ALG=soandso SIG=3489347893uisdjhkfdy897r4hf893r4hjf> (with any special html characters, such as '<' and '>', being escaped in the ascii armored bitstreams. Or did the standards groups that Netscape has been ignoring not bother to discuss such matters? -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd@netcom.com
participants (4)
-
Adam Shostack -
Amanda Walker -
jamesd＠netcom.com -
Kipp E.B. Hickman