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

Michael StJohns <msj@nthpermutation.com> Mon, 09 June 2014 17:00 UTC

Return-Path: <msj@nthpermutation.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 658CD1A0274 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 10:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Br_B1-DsPnyw for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 10:00:01 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F701A01EF for <tls@ietf.org>; Mon, 9 Jun 2014 10:00:01 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id x13so951600qcv.2 for <tls@ietf.org>; Mon, 09 Jun 2014 10:00:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ad/bI76DgEgBAmyykwTzNNIDa2TgU1vSh2mj8Y55JOY=; b=BEb2S3LYE5JAXMaKVZg6nljmJVd5gtYQQnAHqbHBQydK4r5bx8GINN23ZSyRQaEKOa mIKHQIBB32tfK1M7bTZ2zhB8tYYbbaJzQ6gcqcGtFWjWJrOFq6INWp5IKogQv4nqY+e+ 41G9+3uKbzAJt4GNQ2SThzp/0XAJNB/Df3WtIEuidVmngk36UjWRtLoc1pRopJawPw2G AiKdGfuP9Pa9emLRsndOA61NzRQC+tmzvjoSn4O1/u4Sg879373kRUy1HwcZ+S57z/fw SfgO9AUEIzLJaiRO6Z1QyxH7fep2dJhPfx/eFmUoj5eQ4PdV9E5CJu1hsdqDCRvnb1sc X1qA==
X-Gm-Message-State: ALoCoQmtP8urGHcvim8oL+t6VrCxrYnkUJORYot8iZXvx+gWciQ7TwuVLWh/ieICIW4QgmaFBTFv
X-Received: by 10.229.227.5 with SMTP id iy5mr34356382qcb.1.1402333200150; Mon, 09 Jun 2014 10:00:00 -0700 (PDT)
Received: from [192.168.1.114] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id g7sm31292688qab.8.2014.06.09.09.59.59 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 09:59:59 -0700 (PDT)
Message-ID: <5395E810.5020003@nthpermutation.com>
Date: Mon, 09 Jun 2014 13:00:00 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CAMm+Lwiw0TO6D5qnfKFb26kg9-+mzCDHJNd9fMi+BrFf4rQaHA@mail.gmail.com> <A872C115-3665-4359-9EB9-418A7F3A758A@cisco.com>
In-Reply-To: <A872C115-3665-4359-9EB9-418A7F3A758A@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LK3NdWZeQlIXLviMfFJGGVHnCM4
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 17:00:03 -0000

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





On 6/9/2014 10:57 AM, Joseph Salowey (jsalowey) wrote:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>