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

[ianG]

Hi John


On 18/05/2014 20:14 pm, John Kemp wrote:
> Ian,
> 
> On 05/18/2014 09:01 AM, ianG wrote:
>> Hi Rich,
>>
>> Let's go back to basics [0].  What is a datagram and what is a stream?
> 
> Do you mean the basics of network protocols, or the basics of HTTP
> itself?


Both.  An essential measurand for a revolution to replace TLS will be
how well the contender handles HTTP.


> HTTP _depends_ on network datagrams (UDP) vs. streams (TCP) but
> does not itself have such a semantic ingrained (although mostly it
> trades in request response patterns of some kind).


Right ==> Mostly.  If you follow the REST/CRUD philosophical upgrade to
the web, then we can say yes, SHOULD be.


>> A datagram has a fixed number of bytes.  It's a packet.  It's a cohesive
>> record that relates to one thing, which is transport-independent of any
>> other thing.
>>
>> A stream is a contiguous series of bytes, with no end in sight.  We
>> don't know how many are needed, we have to be prepared for more.  We
>> also have to deliver the bytes in order at the other end, and stop we
>> can't do more.
>>
>> So, when a HTTP request goes from client to server, is it a datagram or
>> a stream?
>>
>> It's a datagram.  Because we know precisely how long it is.
> 
> Mostly, yes, requests have a known content-length. But it's not always
> that simple [2].


Yes, now Jerry's comment about how we can look back at history and see
how the various additions and layers have accreted.  So, with such a
complicated and evolved history, eventually someone was going to do [2]
... because they could.

Now, what would have happened if HTTP had gone on a different path being
datagrams?  Well, someone would have done [2] in a different fashion.
No big deal.

The existence of these corner cases isn't evidence that the web is
basically a datagram request-response model, it's evidence that people
did what they could with the underlying tech assumptions.


>>  What comes
>> back is also datagram, as it is a precise length, and indeed there is an
>> internal length header so as to make it easier.
> 
> Sometimes there is. Sometimes there is not. See [1] and the following
> two sections.


Again, as above.  Probably, once we were using TCP, someone found a
corner case where they could exploit the now-unnecessary length information.

That doesn't change the basic argument.  Go back and analyse those
features using a web-as-datagrams model and you might be pleasantly
surprised -- it's just as easier, often easier.


>> Next question is, what happens when we have a request-response model
>> such as the web where a datagram request elicits a datagram response?
>> The only requirement here is that the response datagram has to make its
>> way back to the sender.  So we need a connection, or a session mechanics
>> of some form [1].
>>
>>
>>
>> It turns out that we can layer our RR over a stream connection protocol
>> such as TCP and avoid the requirement to do connection mechanics
>> ourselves.  OR, we can layer our RR over datagrams, and then we have to
>> write our own connection mechanics.
>>
>> It also turns out that we can layer a stream protocol over a datagram
>> underlying network, OR we can layer a datagram protocol over a stream
>> network.  And, sometimes it is hard to see the lines between them.
> 
> Yes, that's true. And then, there's always Websockets (TCP "over" HTTP):
> http://tools.ietf.org/html/rfc6455#page-11 ;)


The one I used to laugh about was the April Fool's RFC of layering of
datagrams over TCP ;)


>> The question is, which is the most efficient to do.  This might depend
>> on history, good design, and knowing enough of the landscape;  skip to
>> Jerry's last two paras:
>>
>>> And so ... here we are.  Living in a city built on top of
>>> generations of older cities.  Dig down and see the accreted
>>> layers.
>>>
>>> What *is* the "right" (easiest to use correctly, hardest to use
>>> incorrectly, with good performance, across a large number of
>>> distinct application API's) underlying interface for a secure
>>> network link?  The fact that the first thing pretty much all
>>> API's do is create a message structure on top of TCP makes it
>>> clear that "pure stream" isn't it.  Record-oriented designs
>>> derived from 80-column punch cards are unlikely to be the
>>> answer either.  What a "clean slate" interface would look like
>>> is an interesting question, and perhaps it's finally time to
>>> explore it.
>>
> 
> I dunno, but:
> 
> http://http2.github.io/?


Right. SPDY however (iirc) isn't enough, what it does is tweak the stack
as much as it can without breaking the stack.  Now I'm guessing that out
of SPDY came the impetus to create QUIC.  That's because if you go
through the exercise as outlined by Lynn Wheeler, you realise that there
is a better way to do it.

But it really is a completely different stack.  Hence, the subject line.


> Of course, people have experimented with these kinds of things before:
> 
> http://en.wikipedia.org/wiki/BEEP and
> http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol just
> to name a couple of interesting ones.


Right.  I do a payments-purposed one myself.  But I have little chance
to get people to adopt it [0].  Hence the subject line:  we need a
revolution before we can reset the security.


> Regards,
> 
> - johnk
> 
> [1] http://www.jmarshall.com/easy/http/#http1.1s3
> [2]
> http://stackoverflow.com/questions/8653146/can-i-stream-a-file-upload-to-s3-without-a-content-length-header


[0]  well, Bitcoin has shown one way... ;)