<div dir="ltr">I think redoing TLS just to change the encoding format is to tilt at windmills. Same for HTTP (not a fan of CORE over DTLS), same for PKIX.<div><br></div><div>But doing all three at once would actually make a lot of sense and I can see something like that actually happen. But only if the incremental cost of each change is negligible.</div>
<div><br></div><div><br></div><div>Web Services are moving towards JSON syntax. Other than legacy support I can see no reason to use XML right now and the only reason to use Assanine.1 other than legacy is to avoid Base64 encoding byte blobs and escaping strings.</div>
<div><br></div><div>Adding these two features to JSON is very easy and does not require a whole new encoding format, just add additional code points to the JSON encoding for length encoded binary blobs. This approach means minimal changes to JSON encoder code and allows a single decoder to be used for traditional and binary forms:</div>
<div><br></div><div><a href="https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/">https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/</a><br></div><div><br></div><div><br></div><div>Web services are typically layered over HTTP and there are a few facilities that the HTTP layer provides that are useful in a Web Service. In particular it is very convenient to allow multiple Web Services to share the same IP address and port. Anyone who has used the Web Server in .NET will know what I mean here.</div>
<div><br></div><div>Web Services use some features of HTTP but not very many. It would be very convenient if we could replace the HTTP layer with something that provides just the functionality we need but layers over UDP or TCP directly and uses JSON-B encoding.</div>
<div><br></div><div><br></div><div>One of the features I use HTTP for is to carry authentication information on the Web Service requests and responses. I have a Web Service to do a key exchange using SSL for privacy (its a pro-tem solution though, will add in a PFS exchange at some point).</div>
<div><br></div><div><a href="http://tools.ietf.org/html/draft-hallambaker-wsconnect-04">http://tools.ietf.org/html/draft-hallambaker-wsconnect-04</a><br></div><div><br></div><div>The connect protocol produces a Kerberos like ticket which is then used to authenticate subsequent HTTP messages using a MAC.</div>
<div><br></div><div><a href="http://tools.ietf.org/html/draft-hallambaker-httpsession-01">http://tools.ietf.org/html/draft-hallambaker-httpsession-01</a><br></div><div><br></div><div><br></div><div>In my view, authentication at the transport layer is not a substitute for authentication at the application layer. I want server authentication and confidentiality at least at transport layer and in addition I want mutual authentication at the application layer.</div>
<div><br></div><div>For efficiency, the authentication at the application layer uses symmetric key (unless non-repudiation is required in which case digital signatures would be indicated but in addition to MAC, not as a replacement).</div>
<div><br></div><div>Once a symmetric key is agreed for authentication, the use of the key for application layer authentication is reasonably obvious.</div><div><br></div><div><a href="http://tools.ietf.org/html/draft-hallambaker-wsconnect-04">http://tools.ietf.org/html/draft-hallambaker-wsconnect-04</a><br>
</div><div><br></div><div><br></div><div>OK, so far the scheme I describe is three independent schemes that are all designed to work inside the existing HTTP-TLS-PKIX framework and they provide value within that framework. But as I observed earlier, it is quite possible to kick the framework away and replace HTTP with a JSON-B based presentation layer framing.</div>
<div><br></div><div>This is what I do in the UDP transport for omnibroker as that is intended to be a replacement for the DNS client-server interface. </div><div><br></div><div><br></div><div>So in summary, yes it is quite possible that TLS could be superseded by something else, but that something else is not going to look like TLS and it will be the result of a desire to build systems that use a single consistent encoding at all layers in the stack (above the packet/session layer).</div>
<div><br></div><div>Trying to reduce the complexity of TLS is plausible but all of that complexity was added for a reason and those same reasons will dictate similar features in TLS/2.0. The way to make a system simpler is not to make each of the modules simpler but to make the modules fit together more simply. Reducing the complexity of HTTP is hard, reducing the complexity of TLS is hard. Reducing the complexity of HTTP+TLS is actually easier.</div>
<div><br></div><div><br></div><div>That said, I just wrote a spec for doing PGP key signing in Assanine.1. Because even though it is the stupidest encoding imaginable, we need to have a PKI that is capable of expressing every assertion type that people have found a need for. That means either we add the functionality of PKIX to the PGP world or vice versa. </div>
<div><br></div><div>The PKIX folk have a vast legacy code base and zero interest in compromise, many are completely wedged on ASN.1. The PGP code base is much less embedded than PKIX and PGP folk are highly ideologically motivated to bring privacy to the masses rather than the specific PGP code formats.</div>
<div><br></div><div>So I have to write my key endorsement message format in Assanine.1. If I can stomach that then so can everyone else.</div></div>