[Standards] XTLS revisited

Dave Cridland dave at cridland.net
Mon Dec 15 19:57:36 UTC 2008


On Mon Dec 15 19:49:15 2008, Justin Karneges wrote:
> On Monday 15 December 2008 11:36:18 Jonathan Schleifer wrote:
> > Am 15.12.2008 um 20:33 schrieb Dirk Meyer:
> > > Jonathan Schleifer wrote:
> > >> Maybe we should make it a requirement that one stanza can only
> > >> include
> > >> one message. That'd make things a lot easier.
> > >
> > > No, you need to have control over your TLS lib to do so. With  
> the
> > > current way you just feed your stanzas into your TLS lib and  
> everytime
> > > it outputs something, you send it away. As simple as possible.
> >
> > That means the TLS lib might delay a stanza, so that's bad  
> anyway. So
> > we need control over the TLS lib anyway. We wouldn't want to  
> delay a
> > message until another is sent.
> 
> 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...


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

So we *can* insist that each encrypted stanza be transmitted in its  
own unencrypted stanza, I think it's just asking for longer term  
trouble, inefficiency, and traffic analysis, and I don't see what  
benefit it gains us - you could do 198 or 199 over the encrypted  
channel to get confirmations.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list