[TLS] Why there should not be a TLS 2.0

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 05 June 2014 13:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588951A00C6 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 06:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dvQ3h6wk2_t for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 06:27:55 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C171A007C for <tls@ietf.org>; Thu, 5 Jun 2014 06:27:54 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id n15so10345112wiw.15 for <tls@ietf.org>; Thu, 05 Jun 2014 06:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=lchCXp8bsZ6f3JqdhlF2cLZNH2eCZ61Fq4Q9uKAMAyY=; b=edROBYDIFnR0EHcGVn1VlUkAaXXoUs9gE9epG+45l5hDPQnLh81CtgNRWtSsXf4b/D x+z6kb856IlwMoE23HD2n+1ggOhepofPcAOakaNCL9n9m8IDYLcxLWARC5y6yN5O2k0A hTy8pr7GP3C3Bh7j/TISyU2mXXTrsb0bbSuRvJ0lyAGV9aKLSIxZ5FLBJsNfJpbH2Ba2 MzeZLZW0ex+fRACtP3tZvl02xE8fi1YJZQ/PYwQfRI/qCrm8kSewDNjnKk1LNQ49fhQO YkYZ+0ABrWMJW8Alw973wSpUoa2I32QO1qNPrGpDyJzr2bghJKyKYPRYZTwHsYyFafcS 8eOQ==
MIME-Version: 1.0
X-Received: by 10.180.7.227 with SMTP id m3mr15638412wia.59.1401974866995; Thu, 05 Jun 2014 06:27:46 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.194.79.136 with HTTP; Thu, 5 Jun 2014 06:27:46 -0700 (PDT)
Date: Thu, 5 Jun 2014 09:27:46 -0400
X-Google-Sender-Auth: 9-S4-cAR1xIpqz4jHwbCKx7lzCc
Message-ID: <CAMm+Lwiw0TO6D5qnfKFb26kg9-+mzCDHJNd9fMi+BrFf4rQaHA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RARyQqIyAev-x3qpqt6HcPj_4hs
X-Mailman-Approved-At: Fri, 06 Jun 2014 08:35:38 -0700
Subject: [TLS] Why there should not be a TLS 2.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 13:27:56 -0000

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.