[Standards] XTLS revisited

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Mon Dec 15 20:14:06 UTC 2008

On Monday 15 December 2008 11:57:36 Dave Cridland wrote:
> On Mon Dec 15 19:49:15 2008, Justin Karneges wrote:
> > TLS transports a stream of bytes.  Saying a particular TLS packet
> > must contain
> > just one stanza is like saying a particular TCP packet must contain
> > just one
> > stanza.
> Actually, TLS transmits a series of records...

And TCP transmits a series of packets...

The common application interface offered by a TCP lib, however, is that of a 
stream of bytes.

> > I don't think a TLS lib would ever cause real delay, but it might
> > attempt to
> > put two sets of recently-written bytes into the same packet (just
> > like a TCP
> > stack might do).  This is perfectly acceptable, and should remain
> > so.
> No, a TLS lib won't - you can run them in and out of buffers if you
> want, and in practise this is the hard part - persuading TLS to
> neatly talk to something that isn't a socket. Once that's done, you
> can assume that a SSL_write (or equivalent) will read in the
> cleartext, wrap it into an encrypted record, and write the result out.

Sure.  In fact, our TLS lib operates in memory and not directly on a socket.  
The interface is still a stream of bytes though.  I guess the interface could 
have been record/packet based, but nobody ever has that kind of expectation 
on TLS.

I think the only difference between TCP and TLS here is that TCP is normally 
controlled by the OS and so it makes it harder to break the abstraction.  
However, just because we might be in a better position to break the TLS 
abstraction doesn't mean we should.


More information about the Standards mailing list