Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

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