[147517] in cryptography@c2.net mail archive
[Cryptography] A stealth redo on TLS with new encoding
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Oct 5 16:55:50 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 5 Oct 2013 11:27:50 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2784209574109597429==
Content-Type: multipart/alternative; boundary=089e011770cbe10bb304e8000fca
--089e011770cbe10bb304e8000fca
Content-Type: text/plain; charset=ISO-8859-1
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.
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.
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.
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:
https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/
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.
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.
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).
http://tools.ietf.org/html/draft-hallambaker-wsconnect-04
The connect protocol produces a Kerberos like ticket which is then used to
authenticate subsequent HTTP messages using a MAC.
http://tools.ietf.org/html/draft-hallambaker-httpsession-01
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.
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).
Once a symmetric key is agreed for authentication, the use of the key for
application layer authentication is reasonably obvious.
http://tools.ietf.org/html/draft-hallambaker-wsconnect-04
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.
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.
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).
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.
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.
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.
So I have to write my key endorsement message format in Assanine.1. If I
can stomach that then so can everyone else.
--089e011770cbe10bb304e8000fca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"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 i=
f the incremental cost of each change is negligible.</div>
<div><br></div><div><br></div><div>Web Services are moving towards JSON syn=
tax. 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 enc=
oding 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 t=
o the JSON encoding for length encoded binary blobs. This approach means mi=
nimal changes to JSON encoder code and allows a single decoder to be used f=
or traditional and binary forms:</div>
<div><br></div><div><a href=3D"https://datatracker.ietf.org/doc/draft-halla=
mbaker-jsonbcd/">https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd=
/</a><br></div><div><br></div><div><br></div><div>Web services are typicall=
y layered over HTTP and there are a few facilities that the HTTP layer prov=
ides 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. Anyon=
e 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 man=
y. It would be very convenient if we could replace the HTTP layer with some=
thing that provides just the functionality we need but layers over UDP or T=
CP 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 pr=
o-tem solution though, will add in a PFS exchange at some point).</div>
<div><br></div><div><a href=3D"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 lik=
e ticket which is then used to authenticate subsequent HTTP messages using =
a MAC.</div>
<div><br></div><div><a href=3D"http://tools.ietf.org/html/draft-hallambaker=
-httpsession-01">http://tools.ietf.org/html/draft-hallambaker-httpsession-0=
1</a><br></div><div><br></div><div><br></div><div>In my view, authenticatio=
n at the transport layer is not a substitute for authentication at the appl=
ication layer. I want server authentication and confidentiality at least at=
transport layer and in addition I want mutual authentication at the applic=
ation layer.</div>
<div><br></div><div>For efficiency, the authentication at the application l=
ayer uses symmetric key (unless non-repudiation is required in which case d=
igital signatures would be indicated but in addition to MAC, not as a repla=
cement).</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=3D"http://tools.ietf.org/html/draft-hallam=
baker-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 i=
s three independent schemes that are all designed to work inside the existi=
ng HTTP-TLS-PKIX framework and they provide value within that framework. Bu=
t as I observed earlier, it is quite possible to kick the framework away an=
d 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 a=
s that is intended to be a replacement for the DNS client-server interface.=
=A0</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 t=
o 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 no=
t 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 complexi=
ty 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 enc=
oding 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.=A0</div>
<div><br></div><div>The PKIX folk have a vast legacy code base and zero int=
erest 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 moti=
vated to bring privacy to the masses rather than the specific PGP code form=
ats.</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>
--089e011770cbe10bb304e8000fca--
--===============2784209574109597429==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2784209574109597429==--
