[TLS] Why there should not be a TLS 2.0

[Phillip Hallam-Baker <[e-mail]>]

There was discussion of TLS 2.0 in London. As I have been thinking
about it further I think it is the wrong direction entirely. Rather
than thinking about a TLS 2.0 we should look at a new scheme that is
the next generation of IPSEC, TLS and WS-Security. While this might
sound fantastically hard, it is in fact more practical than TLS 2.0
and has far better deployment prospects.

The immediate problem that has me thinking this way is Private-DNS
which is my proposal to provide encryption and integrity protections
for DNS which is itself built on technology that I developed to
provide the JSON/REST world with the same security features as WS-* in
a draft of 25 pages or less (done).


First lets look at the current situation. We have IPSEC and TLS
deployed. They are both enormously complicated and adopt completely
different design approaches, different encodings and different key
exchanges. But 90% of the underlying technology is identical: IPSEC
and TLS both deliver a secure tunnel between endpoints.

The only point at which IPSEC and TLS differ as a result of their
function is in the application to the communication medium. IPSEC is
applied at the IP packet layer, TLS is applied to the TCP stream. And
that is all the difference there is. There is no reason that a
protocol can't have one key exchange mechanism to serve both purposes.
The success of TLS VPNs and SSH tunneling demonstrates that this is
the case.


So rather than thinking about TLS 2.0, I think we should instead
consider the problem of establishing a security context separately
from the problem of how to apply that context to a communication
medium. Once that separation is made we can apply it at the packet,
transport and application levels. Instead of TLS/2.0 we should be
thinking about IPSEC/2.0 and HTTP-SEC.

Factoring out the key exchange has other major advantages. It makes a
three legged 'Kerberos style' interaction possible as well (or even
four legged). the machine that performs the public key crypto needed
to establish the security context does not need to be the same as the
machine that uses the security context.

This means that instead of an SSL accelerator box having to be
strapped into the middle of my communication path as a pipe, it can be
a separate server. Most boxes are more than capable of doing AES and
SHA-2-256 without impacting server performance. It is the public key
cryptography that is the problem, especially because each operation is
quite significant.

Kerberos does a lot of things right which is why people still use it.
But right now it is a separate world to TLS. A convergence of TLS and
Kerberos would be much more useful.


At the moment I am relying on TLS to secure the confidentiality and
integrity of the security context exchange in SXS-Connect:

http://tools.ietf.org/html/draft-hallambaker-wsconnect-08

A security context consists of

* A session identifier (opaque series of octets)
* Algorithm choices (e.g. AES-128 + SHA-2-256)
* A shared master secret
* Expiry/invalidity information (when to stop using, renegotiate, etc)

The size of the session identifier can be between 0 and 255 bytes
depending on how much state the issuer needs and how much of that
state is to be encoded into the identifier.

So identifiers might be

* 0 bytes - implicit in the IP Address and Port.
* 8 bytes - just a key.
* 24 bytes - is sufficient for a minimal stateless server scheme.
* 64 bytes - what my code uses for a stateless server scheme.
* 128 bytes - what my code uses during initial negotiation of a
security context.

Obviously, the lower down you are in the stack, the greater the
overhead of a large session ID. But giving this tradeoff to the issuer
allows the tradeoff to be made depending on specific needs at a
specific installation rather than making it a global tradeoff decided
by a Working Group with no knowledge of the particular requirements.