Subject: [TLS] Why there should not be a TLS 2.0

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Jun 2014 09:27:46 -0400

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.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 8 Jun 2014 14:27:58 +0200

> thinking about IPSEC/2.0 and HTTP-SEC.

So I understand you want to split the encryption from the
authentication?  Would there still be a need for HTTP-SEC,
and can't it be plain HTTP in that case?

Do you expect the client (browser) to set up this IPSEC/2.0
possibly by a library, or do you expect a separate daemon or
the kernel to provide that functionallity?

I would imagine that the client would like to do a "please give me
a tunnel to that hostname", and then get back some descriptor that
it can use to talk to it.  Please note that I say hostname,
because I think that you can have several names each which it's
own certificate on the same IP address.

But then I wonder if it should be to a combination of hostname and
port or not.  Maybe you want to use a different certificate for
HTTP and email?  And if you do it to a combination of hostname
and port, what really is the difference with TLS other than that
it might run at a different layer?

Kurt

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 8 Jun 2014 15:49:01 +0000

> own certificate on the same IP address.

Yes, but stronger yet, one needs (ala GSSAPI + Kerberos, which for
all its limitations gets some things right) to be able to ask for
service@hostname, not just hostname.  The underlying Kerberos
stack works with service/instance@REALM, which also makes sense.

We could define new DANE record formats for scalable public-key
cross realm authentication with Kerberos or a Kerberos-like system,
and DNSSEC for a suitably secure hostname->realm mapping.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 8 Jun 2014 12:46:53 -0700

> stack works with service/instance@REALM, which also makes sense.

See also Ethos, where the network protocol authenticates services and
users to each other. The kicker is services no longer need to
authenticate users.
> and DNSSEC for a suitably secure hostname->realm mapping.

Or one could use a certificate format that supported this natively.
The fact that TLS is (mostly) tied to X509 is a real shame when it
comes to extending.

Yes, you could define extensions for certificate type and use them: at
some point SPKI may have been used this way. But as Viktor points out
GSSAPI dominates this space (unfortunately: anonymous users are hard
to rope in here).

Sincerely,
Watson Ladd

>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Jun 2014 01:24:55 +0000

> GSSAPI dominates this space (unfortunately: anonymous users are hard

Kerberos has "kinit --anonymous" (Heimdal CLI syntax).  The client
principal is then (IIRC) WELLKNOWN/ANONYMOUS@REALM.  In this context
the KDC has a client-trusted public key issued by some suitable
X.509 trust anchor (no DANE binding yet).

-- 
	Viktor.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 9 Jun 2014 14:57:27 +0000

Hi Folks,

This working group is chartered to work on TLS.   While there are many things to talk about that are not TLS, they do not belong on this list. You may send an announcement for a place to discuss other related work that is not TLS to the list, but the discussion should be handled off the TLS list.    

Thanks,

Joe 
[For the Chairs]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 09 Jun 2014 13:00:00 -0400

Hi Joe -

Not to push back too hard, but how is discussion of items that might be 
added/deleted/modified from the charter not a valid topic for discussion 
on this list?  Admittedly this particular thread is a little off in the 
weeds, but it's still talking about transport layer security and how it 
fits in with other things.  I (*sigh*) can see how this might generate 
discussion on a TLS kerberos extension.

Perhaps let it die its own death rather than setting out to kill it?  
It's only bits and its less noisier than some threads in the last year.

Mike