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

Kurt Roeckx <> Sun, 08 June 2014 12:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E6451A03B5 for <>; Sun, 8 Jun 2014 05:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AATxAaHujOkW for <>; Sun, 8 Jun 2014 05:28:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A1DB1A03AE for <>; Sun, 8 Jun 2014 05:28:07 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id CF0121C219E; Sun, 8 Jun 2014 14:27:58 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 9DC501FE00EC; Sun, 8 Jun 2014 14:27:58 +0200 (CEST)
Date: Sun, 8 Jun 2014 14:27:58 +0200
From: Kurt Roeckx <>
To: Phillip Hallam-Baker <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "" <>
Subject: Re: [TLS] Why there should not be a TLS 2.0
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Jun 2014 12:28:09 -0000

On Thu, Jun 05, 2014 at 09:27:46AM -0400, Phillip Hallam-Baker wrote:
> 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.

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?