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

Phillip Hallam-Baker hallam at gmail.com
Tue May 13 19:23:13 EDT 2014


On Fri, Apr 25, 2014 at 4:42 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Tony Arcieri <bascule at gmail.com> writes:
>
>>http://clearcryptocode.org/tls/
>>
>>Probably not going to happen, but it's nice to dream...
>
> And it is a dream.  This is another one of the "let's replace TLS with My Pet
> Secure Protocol and then we'll be safe", ignoring the fact that an
> implementation of MPSP can and will be just as buggy as an implementation of
> TLS.  As with "let's replace C with My Pet Programming Language", you can
> write crap in any language you want.  The problem isn't the language, or
> protocol, or OS, or whether you use a Qwerty or Dvorak keyboard, but the
> culture that creates the implementation.

Yes and no.

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.

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).


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.

The key exchange part could also be modified. Right now it relies on
the authentication and confidentiality provided by TLS but it would be
better if it only relied on the authentication. It would be easy to
introduce a lightweight DH exchange to achieve that. We could even
introduce a new binding mechanism that dispenses with TLS entirely.


The point I am trying to make here is that looking for a 10% better
version of TLS is probably not the best use of time because any TLS
2.0 library will inevitably have to be backwards compatible with
legacy TLS and so any libraries will only be larger [2].

The improvements I look for are ones that make the code base a lot
smaller. And that requires rather more radical thinking than a 2.0
protocol. Refactoring the protocol so that the interfaces between the
abstraction layers expose different information for example.



[1] Yes I am aware that a farcical 'study' was purchased from a
K-street outfit which purports to tell 'the fable of the keys' which
disputes the Dvorak keyboard story. The study didn't even come close
to justifying its conclusions, the strongest claim it could make was
that nobody properly researched whether Dvorak was better. Well what a
surprise, because it was clear to everyone that no speed advantage
would be sufficient to justify retraining the typists.

[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.
-- 
Website: http://hallambaker.com/


More information about the cryptography mailing list