[Cryptography] [cryptography] Is it time for a revolution to replace TLS?

[ianG]

On 14/05/2014 00:23 am, Phillip Hallam-Baker wrote:
...
> In general any proposal of the form 'lets replace X with something 10%
> 'better'' is a losing proposition. Particularly when we are talking
> about systems where network effects dominate such as protocols, APIs
> and keyboard layouts[1].
> 
> And the proposals that are utterly doomed are the proposals of the
> form 'lets add this one feature to X that I am obsessive about while
> ignoring the fact that the alternative proposed does not support
> features A, B, C that experience has proved to be essential'. So
> proposals for new PKIs that assume admins never screw up are kinda
> doomed.
> 
> However there are occasions where such changes do happen. For example
> QWERTY will survive until handwriting or voice recognition becomes
> good enough that they become more convenient modes of text entry.
> 
> To replace a protocol such as TLS it is futile to propose a
> replacement that does the same job in the same way but with slightly
> fewer bits used. But a protocol that is useful in an application that
> is not part of the core TLS use cases and TLS does not support well
> could be a different matter.


TLS does the job so badly that using a different method is just as
plausible.  People fight to avoid TLS already, they'd rather send stuff
in the clear if they could.  So just solve the problems they have.


> For example, in Web Services we frequently require message layer
> security in addition to transport layer security because a Web Service
> transaction might involve more than two endpoints and messages that
> are stored and forwarded etc. This is why WS-* is not TLS. (It is
> unfortunately horribly baroque but that was not my doing).


Yes, this is the way in.  One problem that occurred with TLS was that
there was an assumption that the job was to secure the reliable stream
connection mechanics of TCP.  False assumption.

Pretty much nobody uses streams by design, they use datagrams.  And they
use them in a particular fashion:  request-response.  Where we went
wrong with TCP was that this was the easiest way to handle the mechanics
of getting the response back to the agent that sent the request.
Without TCP, one had to deal with the raw incoming datagrams and
allocate them to the different sending agents.

A second problem was that the design was too intertwined with commercial
PKI so certs were hung on the side as a millstone for server
authentication and discarded as client side, leaving passwords to fill
that gap.  A mess, which is an opportunity for redesign, frequently
exploited by many designs already.


> So while I don't see a value in a replacement for TLS that is just a
> better SSL. But there are areas that are currently poorly served by a
> protocol where the key exchange part is welded to the transport part.
> For example:
> 
> http://tools.ietf.org/html/draft-hallambaker-wsconnect-07
> 
> Note that in this particular case SXS-Connect is actually built on top
> of the TLS key exchange because all we are looking to do is to
> establish a ticket and shared secret that can be used in later
> transactions. The value comes from the separation of the two parts
> rather than having it as an 'all in one'. But having separated out the
> two parts we can vary each independently. For example, I am already
> using two separate transport packaging schemes, one layered on HTTP
> and the other layered on UDP.


Right, divide and conquer.  This is one way forward.  What I can't see
is the right way forward.  This is why I see the market for replacements
in some form of competition already, and maybe the way to accelerate
this process is to formalise the competition;  as part of the
competition we also leave the requirements open.


...
> [2] Yes I know that in theory a 2.0 version could be backwards
> incompatible. But life does not work that way. What you would have to
> do is support both versions of the protocol. All 2.0 means is that you
> don't necessarily need to do both at once so you sitll have to do the
> old junk and the new junk but not both at the same time.


Right.  Compatibility support will happen regardless.  But if you make a
clean break, then people can work to that target -- they can upgrade all
their code to the 2.0 version and one day a time comes to start cutting
out the old.  But to do that we have to have a clean target.



iang