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

[John Kemp]

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

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

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

>
>
>
> 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 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/?

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.

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

>
>
> iang
>
>
>
>
>
> [0] yes, this is a top post ;-)
> [1] the clue here is that we need it anyway...
>
>
> On 17/05/2014 15:06 pm, Salz, Rich wrote:
>>> 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.
>>
>> Not false, that was a design goal.  Make HTTP, which is a TCP protocol, "secure" (for some definition of secure which isn't relevant right now, actually).
>>
>>> 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
>>
>> SSL was invented to enable electronic commerce, and the concern was that people would have to feel comfortable that they were sending their credit card information to Sears, not Sores. So server-side authentication, in the form of trusted third parties, was felt to be the best way forward. So RSA with certificates was the answer, and IIRC RSA got a piece of Netscape equity in exchange for a license.
>>
>> Recall that this was all twenty years ago.
>>
>>> Pretty much nobody uses streams by design, they use datagrams.
>>
>> Except for the web, yeah, nobody.
>>
>>> TLS does the job so badly that using a different method is just as plausible.
>>
>> Except for the web deployed base, sure.
>>
>> 	/r$
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>