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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 09 June 2014 14:57 UTC

Return-Path: <jsalowey@cisco.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 37F591A01D5 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 07:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 PaJwub1alY-i for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 07:57:30 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D1A1A01C2 for <tls@ietf.org>; Mon, 9 Jun 2014 07:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4781; q=dns/txt; s=iport; t=1402325850; x=1403535450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wE+mAbYoyxTgd+l67/lufw8g/MEBf+khGTaLYR+3Tv4=; b=CEGmhQS9tHArENxPDEC6L55+V7IBDTCYVKTNrRFvbfX3fy8pPEqQ9A14 3Xp/1tuUcD8KGAnD0BFO3DLgDIR5yaatlm8bY4ogKVXTmXoUMEj8Eocwr JFWZmim+ImD+FkxiUV4fgpKkII4Icy6TQ+ned2abxDyv+dTYZKzNpZ1Ur 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwLAFvKlVOtJV2P/2dsb2JhbABZgw1SWapkBQGRVIc8AYERFnWEAwEBAQMBAQEBNzQCCQULAgEINhAnCyUCBA4FiDoIDcp/F4VdiDshMweDK4EWBJohgUKSA4M8gi8
X-IronPort-AV: E=Sophos;i="4.98,1002,1392163200"; d="scan'208";a="331697592"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jun 2014 14:57:29 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s59EvTEj016850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jun 2014 14:57:29 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.225]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 9 Jun 2014 09:57:28 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Why there should not be a TLS 2.0
Thread-Index: AQHPgZ0BKVDNb367OUq6Hxi/1wjpMptpNtgA
Date: Mon, 09 Jun 2014 14:57:27 +0000
Message-ID: <A872C115-3665-4359-9EB9-418A7F3A758A@cisco.com>
References: <CAMm+Lwiw0TO6D5qnfKFb26kg9-+mzCDHJNd9fMi+BrFf4rQaHA@mail.gmail.com>
In-Reply-To: <CAMm+Lwiw0TO6D5qnfKFb26kg9-+mzCDHJNd9fMi+BrFf4rQaHA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.51]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B5D17D05EFC4494599EB1FF0EB344236@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PPzJ1riW7Zw2T_rGHfcprY3tarQ
Cc: Phillip Hallam-Baker <phill@hallambaker.com>
Subject: Re: [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: Mon, 09 Jun 2014 14:57:32 -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]
On Jun 5, 2014, at 6:27 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls