On 08/25/2010 10:40 PM, James A. Donald wrote:
This is inherent in the layering approach - inherent in our current crypto architecture.
one of the things ran into the (ISO chartered) ANSI X3S3.3 (responsible for standards related to OSI level3 & level4) meetings with regard to standardization of HSP (high speed protocol) ... was that ISO had policy that it wouldn't do standardization on things that violated OSI model. HSP violated OSI model by (and was turned down by X3S3.3) 1) went directly from level 4/5 interface to the MAC interface (bypassing OSI level 3/4 interface) 2) supported internetworking ... which doesn't exist in OSI model ... would set in non-existing layer between level3 & level4 3) went directly to MAC interface ... which doesn't exist in OSI mdoel ... something that sits approx. in the middle of layer3 (above link layer and includes some amount of network layer). In the IETF meetings at the time of original SSL/TLS ... my view was that ipsec wasn't gaining tranction because it required replacing parts of tcp/ip kernel stack (upgrading all the kernels in the world was much more expensive then than it is now). That year two things side-stepped the ipsec upfront kernel stack problem * SSL ... which could be deployed as part of the application w/o requiring changes to existing infrastructure * VPN ... introduced in gateway sesssion at fall94 IETF meeting. This was implemented in gateway routers w/o requiring any changes to existing endpoints. My perception was that it upset the ipsec until they started referring to VPN as lightweight ipsec (but that opened things for ipsec to be called heavyweight ipsec). There was a problem with two classes of router/gateway vendors ... those with processors that could handle the crypto load and those that had processors that could handle the crypto load. One of the vendors that couldn't handle the crypto load went into standards stalling mode and also a month after the IETF meeting announced a VPN product that involved adding hardware link encryptors (which would then required dedicated links between the two locations as opposed to tunneling thru the internet. .... I would contend that various reasons why we are where we are ... include solutions that have champions with profit motivation as well as things like ease of introduction ... and issues with being able to have incremental deployments with minimum disruption to existing facilities (like browser application based solution w/o requiring any changes to established DNS operation). On the other hand ... when we were brought in to consult with the small client/server startup that wanted to do payment transactions (and had also invented SSL) ... I could mandate multiple A-record support (basically alternative path mechanism) for the webserver to payment gateway TCP/SSL connections. However, it took another year to get their browser to support multiple-A record (even when supplying them with example code from TAHOE 4.3 distribution) ... they started out telling me that multiple-A record technique was "too advanced". An early example requirement was one of the first large adopters/deployments for e-commerce server, advertized on national sunday football and was expecting big e-commerce business during sunday afternoon halftime. Their e-commerce webserver had redundant links to two different ISPs ... however one of the ISPs had habit of taking equipment down during the day on sunday for maintenance (w/o multiple-A record support, there was large probability that significant percentage of browsers wouldn't be able to connect to the server on some sunday halftime). -- virtualization experience starting Jan1968, online at home since Mar1970 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
