towards https everywhere and strict transport security

Anne & Lynn Wheeler lynn at
Thu Aug 26 12:49:51 EDT 2010

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 majordomo at

More information about the cryptography mailing list