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

[Kurt Roeckx <[e-mail]>]

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?


Kurt