Some feedback, in no particular order: * have a hard think about handshake/termination loads. istm this scheme devolves pretty quickly to a termination per object HTTP/1.0 style so you'll be fairly quickly looking to do some kind of multiplexing and reuse on top of it for the same reasons HTTP evolved that way. as an alternative - HTTP/2 inside of a CONNECT tunnel (e.g. HTTP/2 on one stream of an HTTP/2 session) is something browsers already do and may be a carrot worth chasing if you want to give up on the dream of just deploying js into the current environment.
* read the current websockets over http/2 thread on httpbis with an eye to the discussion about CONNECT vs (a hypothetical) TUNNEL. There are some similarities to the discussion here. * also take a look at https://tools.ietf.org/html/dr aft-nottingham-bcp56bis-00 (to be adopted imminently by httpbis) - for general foo over http guidance. In particular note that requiring particular behavior from http response codes beyond what is already defined (adding semantics) is called out as a practice to be avoided. * I don't really understand how s->c data flows other than as a reply to client data. hanging get? polling? push? * istm you are using http as a reliable messaging layer. That 'reliable' part might get you into trouble.. various events can cause an http transaction to fail and I'm not sure how you recover that state without record number etc.. Is there room for a off path malicious actor to disrupt your stream state (e.g. send a get with your session ID to get a few bytes of ciphertext - which means you never get them?)? Perhaps this works better as a more generic "datagram over http" framework which you can obviously run some form of reliable stream and tls (and http) on top of. why is a tls record the best scope here? On Tue, Oct 31, 2017 at 10:26 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie > wrote: > > Hi Owen, > > On 31/10/17 21:03, Owen Friel (ofriel) wrote: > >> Interesting. One bit puzzles me: wouldn't the new content-type > >> give the game away and cause middleboxes to block this? > >> > >> S. > >> > > [ofriel] The intention isn’t to try and obscure the fact that there > > is an ATLS session. Even if that new content-type was not defined, > > it would be easy to write a simple pattern match script on the > > middlebox to identity the JSON body and leading base64 bytes of the > > TLS records in the body. > > So that leaves me puzzled still, sorry. > > I can't think of a situation with a middlebox that isn't ok > with the client doing proper TLS but is ok with ATLS. > > Can you give an example of such a situation? > > In case it helps, I can imagine that some middleboxes won't > (yet) know about this and will let it through for a while, > but that seems fairly brittle. So, I'd have thought it may > be worthwhile trying to hide what's what here if you want > it to be robust against an antagonistic middlebox or censor. > But maybe you guys analysed that already and figured it'd > not work. (Which brings me back to "puzzled":-) > > Cheers, > S. > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
