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

[Michael StJohns <[e-mail]>]

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