Being #6.2 in a series of hypotheses.
It's OK to design your own protocol. If there is nothing out there that seems to fit, after really thrashing #6.1 for all she is worth, design one that will do the job -- your job.
Consider the big weakness of SSL - its a connection protocol!
The mantra of "you should use SSL" is just plain stupid. For a start, most applications are naturally message-oriented and not connection-oriented. Even ones that are naturally stream-based -- like voip -- are often done as message protocols because they are not stream-based enough to make it worthwhile. Another example is HTTP which is famously a request/response protocol, so it is by definition a messaging protocol layered over a connection protocol. The only real connection-oriented need I can think of is for the secure terminal work done by SSH; that is because the underlying requirement (#6.1) is for a terminal session for Unix ttys that is so solidly connection based that there is no way to avoid it. Yet, even this slavish adoption of connection-oriented terminal work is not so clearcut: If you are old enough to remember, it does not apply to terminals that did not know about character echo but instead sent lines or even entire pages in batch mode.
What this principle means is that you have to get into the soul of your application and decide what it needs (requirements! #6.1 ! again!) before you decide on the tool. Building security systems using a bottom-up toolbox approach is fraught with danger, because the limitations imposed by the popular tools cramp the flexibility needed for security. Later on, you will re-discover those tools as shackles around your limbs; they will slow you down and require lots of fumbling and shuffling and logical gymnastics to camouflage your innocent journey into security.
Posted by iang at May 8, 2007 05:39 PM | TrackBackthese posts mention being called in to consult with small client/server startup that wanted to do payments on their server ... and they had this technology called SSL.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
some of the work for deployment including doing some of the stuff for taking a technology and turning it into a business process. this is now frequently called electronic commerce and is probably the main use of SSL in the world today.
misc. other posts about the business process related to the digital certificates for the SSL process
http://www.garlic.com/~lynn/subpubkey.html#sslcert
i've mentioned before that we subsequently worked on x9.59 financial transaction protocol
http://www.garlic.com/~lynn/x959.html#x959
which can be considered to obsolete much of the work that we had previously done in conjunction with SSL (for what is comingly now called electronic commerce). recent post here
http://www.garlic.com/~lynn/aadsm26.htm#70 WSJ: Soft evidence on a crypto-related breach
Now this recent post makes some slight reference to issues with using a connection protocol for transaction operation
http://www.garlic.com/~lynn/2007j.html#38 Problem with TCP connection close
... for some minor historical drift ... while tcp/ip is the technology basis for the modern internet, we claim that the operational basis for the modern internet came with the NSFNET backbone. Here is some old collected email working on various aspects of NSFNET backbone ... and then not being allowed to bid (even tho subsequent NSF audit
of what we already had running claimed that it was at
least five yrs ahead of all NSFNET backbone bids to build something new):
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
we also served on what was the "XTP" technical advisory board ... attempting to do both high-speed protocol as well as support reliable transactions. The above post references that session TCP operation requires a minimum of seven packet exchange ... and that VMTP/RFC1045 required minimum of five packet exchange. XTP only needed a minimum of three packet exchange for reliable transaction operation.
misc. posts mentioning XTP as well as folly of attempting to get an XTP high-speed protocol work item into ISO standards ... where ISO network standards had a requirement that only work on network standards could be done for things that dont' violate OSI model (and turns out that both IP, internetworking protocol and LAN/MACs violate OSI).
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
now these series of posts mention that general internet public key distribution could be done as part of DNSSEC that includes registering public keys with DNS as part of domain name registration. The basic objective improves the integrity of DNS ... which the SSL domain name certification authorities rely on when they are attempting to validate SSL digital certificate applications. However, it could also be used to obsolete the need to have SSL digital certificates for public key distribution (doing real-time, online, trusted distribution) ... creating something of a catch-22 for the certification authority industry
http://www.garlic.com/~lynn/subpubkey.html#catch22
If registered public key could be piggy-backed on the standard DNS domain to ip-address response (along with any required crypto preferences) ... then the client would have the server's public key before even contacting the server (w/o any additional protocol chatter). for other topic drift some old crypto related email
http://www.garlic.com/~lynn/lhwemail.html#crypto
including one from may81 about a online network service for trusted public key distribution
http://www.garlic.com/~lynn/2006w.html#email810515
Coupled with XTP, an extremely simplified, transaction SSL is possible ... a client could generate a random secret key, encrypt transaction message with the secret key, encrypt the secret key with the server's public key ... and send the combination (encrypted transaction message and encrypted secret key) to the server in a single message
This is separate from the x9.59 transaction scenario with regard to whether it is necessary to hide/encrypt the information at all; x9.59 transaction could be sent via XTP to a server w/o requirement for hiding/encryption.
re:
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy
for a little additional topic drift ....
in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments ... which results in x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959
there were various other efforts going on in the area of secure payment protocols at the time ... attempting to improve what had already been done for electronic commerce with SSL
typical of the genre from the period ... there were protocols proposed that would increase the payload of typical payment transaction by a factor of 100 times (enormous payload bloat) as well as processing by a factor of 100 times (enormous processing bloat) ... misc. past posts mentioning some of the activity from the period that would result in enormous bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat
"Most apps are message oriented" too true, plus a lot of your risk of winding up in the WSJ (in a bad way) is in the data/message. Further, yoru average corporate data center terminates SSL at its outer edge, many hops from the web/app server.
Posted by: Gunnar at May 10, 2007 11:24 AM