Feature: A Response to the feature on IPv6 vs. SSL

SSL and other transport-layer protocols provide _additional_ and _different_ security functionality that IPsec (and hence IPv6) will never provide. For example, SSL
provides authentication _of a particular user or person_ over an encrypted connection to a service. IPsec only provides security between the machines. Many SSL
applications, such as Netscape's web browser, provide the user with the ability to control what level of security he uses. IPsec will never offer this sort of control to
(most) end users; that isn't its purpose."

A Response to the feature on IPv6 vs. SSL

Reto Haeni's paper on IPv6 and SSL explains a number of fundamental differences
between the two protocols but fails to communicate why they are different. It
is also quite out of date (it appears to have been written in 1996) and as a
result some of its facts are no longer true. The paper is misleading (though
clearly not intentionally) due to its age and its failure to address the
differences between SSL and IPv6 adequately.

IPv6, or more to the point, IPsec is designed to provide host-to-host,
subnet-to-subnet, and host-to-subnet encryption and authentication, as stated
in Haeni's paper. Most often it is likely to be used in either a
subnet-to-subnet model, where the goal is to encrypt the traffic between
two networks, or host-to-subnet model, where the goal is to encrypt traffic
from one machine to a network. The first model is typical of "virtual private
networks," or VPNs, where two geographically separated networks in the same
organization are connected to each other over the Internet by means of an
encrypted IPsec tunnel. The second model is typical of "road warriors,"
workers on the road, who wish to securely connect to their organization's home
network to access some service.

IPsec is also critical for securing the Internet infrastructure by encrypting
all traffic on the Net. If every gateway to a subnet is IPsec-enabled, then
traffic between it and every other subnet can be encrypted and authenticated.
This is important for data security, privacy, and prevention of many kinds of
cracker attacks that happen now.

However, IPsec secures traffic between _machines_, not people. There are many
applications of encryption and authentication that IPsec does not and should
not address.

SSL and other transport-layer protocols provide _additional_ and _different_
security functionality that IPsec (and hence IPv6) will never provide. For
example, SSL provides authentication _of a particular user or person_ over an
encrypted connection to a service. IPsec only provides security between the
machines. Many SSL applications, such as Netscape's web browser, provide the
user with the ability to control what level of security he uses. IPsec will
never offer this sort of control to (most) end users; that isn't its purpose.

Because SSL can authenticate users as well as machines, it can be used to
provide all kinds of secure, per-user access control which IPsec cannot
provide. Different services running on the same machine may allow very different access privileges to the same user, a scenario which is impossible for IPsec
to handle since it authenticates machines, not people.

Further, SSL provides end-to-end security, whereas IPsec may only provide
security from one subnet to the other. IPsec is unlikely to provide much
data privacy to users behind a subnet-to-subnet IPsec model. SSL provides
encryption _from the end user's application_ through to the other end, the
recipient application.

One can draw an analogy from package shipping. IPsec is akin to taking a
document that you want delivered securely and handing it to the shipping
person in your company, who hands it to someone else, etc, until it eventually
gets put into a locked safe on the loading dock and then is handed to the
package shipping company. The process is reversed on the other end.

SSL, on the other hand, is akin to taking your document and sealing it in a
locked, unbreakable envelope which is completely inaccessible without the
right key. The envelope is _then_ handed to the shipping people and off it
goes. Only the end recipient has the key. It may go through the above process
as well, or it may not, but you are certain of its security regardless.

It is clear that both of these models are important and useful, but in no way
are they mutually exclusive; rather, they complement each other. SSL (or other
transport-layer security mechanisms) will always be necessary and important,
regardless of the security offered at the IP layer. The best of all worlds is
SSL on top of IPsec, where the traffic between machines or networks is
encrypted and authenticated, and then further security is layered on
top at the transport layer, providing user-level authentication and
end-to-end security.

My conclusion in comparing IPv6 (specifically its IPsec component) and SSL is
that both are required and neither is sufficient on its own to provide the
kind of security, authentication, and privacy that the Internet desperately
needs.

I would also like to address some of the inaccuracies in Haeni's paper (many
of which draw simply from its age):

Haeni states, "While Netscape uses its SSL version 2 in the
Netscape Navigator browser, IPv6 is implemented only by multiple
organizations in research projects."

The "current" version of SSL hasn't been 2 for a long time... SSLv3 and TLSv1
are now the SSL standards in use. Both were much more rigorously designed
than SSLv2, and TLSv1 is an IETF standard just like IPv6.

Also, quite a number of SSL implementations exist, some of the best of which
are open-source.

Haeni states, "One of the most important mechanisms, the key exchange, is
still not defined for the IPv6 protocol."

This is no longer true. It has little bearing on the paper or my response,
but it is worth mentioning.

Haeni states, "The security specifications are clear enough to conclude that
the IPv6 protocol has enough security capabilities to provide better
authentication and confidentiality than SSL in general."

This just isn't true; SSL and IPv6 address different security issues, though
some of their respective capabilities are similar. I have attempted to show
this clearly above.

Haeni states, "SSL has a specific port number assigned that is dependent on
the application protocol where SSL is located in the next lower layer. Until
now, there are three port numbers assigned by the IANA (The Internet Numbers
Authority) and therefore can be used with SSL. These are: HTTP, NNTP, SMTP."

It may be that the IANA has only assigned ports for these SSL-enabled
protocols, but SSL can be used for many, many other things. It is in no way
limited by the choice of application protocol. That Haeni makes this point
seems to indicate that he is looking at SSL as if it were intended to
accomplish the same goals as IPv6; it is definitely not, except in the
very broad sense of security and authentication.

Haeni states, "While SSL is used for host-to-host or mostly host-to-server
services, IPv6 can be used for host-to-host, host-to-subnet and
subnet-to-subnet authentication or encryption."

Haeni fails to differentiate SSL "host-to-host" from IPv6 "host-to-host."
They are very different. Perhaps SSL "host-to-host" should really be called
"application-to-application." This is a fundamental difference as I pointed
out above.

This statement isn't true. It might be true that in a particular setup
IPv6 encryption is stronger than SSL if, for example, a user is using
an export-only web browser for SSL and the IPv6 setup uses 3DES. However,
the situation could easily be reversed and the SSL could be stronger.

In addition, the authentication offered by IPv6 may be as strong, weaker,
or stronger, but the comparison makes little sense given that the type
of authentication and its intent are very different.

I would appreciate comments on any of this. As always, my views are my own and
no one else's and they do not represent my employer in any way.