Nicolas Williams wrote:
I don't have one that exists today and is practical.  But we can
certainly imagine possible ways to improve this situation: move parts of
TLS into TCP and/or IPsec.  There are proposals that come close enough
to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS
WG) that it's not too farfetched, but for web stuff I just don't think
they're remotely likely.

my view of ipsec was that it faced a significant barrier to entry since
it required upgrading lots of installed kernels all over the infrastructure
(aka tcp/ip protocol stack have been integrated kernel implementations)

both SSL and VPN offered implementations that require having to
upgrade existing deployed kernels (something that has gotten
somewhat easier in the last decade plus).

about the same time as SSL, a friend that we had worked on & off with
over a couple decades introduced what was to become called VPN
in gateway committee at fall '94 IETF meeting in san jose.

my view was this resulted in some amount of consternation
with the ipsec forces as well as some of the router vendors.
the ipsec forces were somewhat mollified by being able
to refer to vpn as "lightweight" ipsec (while others then
would refer to ipsec as "heavyweight" ipsec).

the initial proposal involved border routers providing
authentication and (encryption) tunneling through the
internet. some of the router vendors had processors
that could handle the encryption load. however, there
was opposition from the router vendors that didn't
have products with processors that could handle
the encryption load (or at least stalling until they
had such a product).

in any case, uptake of both SSL and VPN ... was
the significantly easier and less complex deployment
... vis-a-vis ipsec.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to