On Wed, Oct 04, 2017 at 07:47:20PM -0400, Patrick McManus wrote: > I'm not really looking for a fight - I'm going to focus on the basic > principles and trying to offer advice in good faith. Definitely, and thank you so much for it! Hope my reply didn't sound like i wanted to start a cookie fight ;-P. > I'm also not claiming to fully understand brski (is > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07 > right?). Yes. > *In BRSKI there are state issues with both the TLS and the HTTP process. > The TLS server certificate is not trusted by the client until after at > least one RESTful interaction occurs. Only once that has occured is the > connection considered secure. * > is the trust established by the above restful interaction trust in the > certificate (which can be extended to future connections with the same > certificate) or is it trust in the connection that did the exchange? I > presume its the former. If its the connection you have a pretty big problem > because all versions of http allow connections to be torn down at any time, > so you can never rely (in a standards way) of being able to get beyond the > initial exchange. It's the former. First transaction delivers voucher object which establishes trust into the Cert used by the peer. > *We are concerned about how the protocol could become broken if used with > HTTP2 with interleaving of requests/responses."* > > how does the protocol deal with issues like parallel connections and > pipelines in h1? Its the same problem. I think its naturally serialized by the dependencies between the possible transactions. Eg: building some request requires parts of another transactions response. And if not that very explicit dependency, then the serialization of steps specified in the protocol (such as my step 4.). > So rather that trying to restrict the protocol to h1, or to profile h2 down > into a overly complex version of h1, the right answer here is what Michael > suggested (and Martin hinted at) early on - solve it in a state machine > above the http transport level because http as a transport isn't robustly > going to give you ordering (now or in the future) - it inherently thinks of > requests as independent of each other and their connections. Right. I guess i primarily wonder how a programmer using some HTTP(S) API could unexpectedly run into reordering issues. Even if i had a multi-threaded HTTP(S) API with callbacks, it should always be possible to force serialization. I think, but not sure... > as for concerns about constrained processors, is that something the > protocol should be defining or something that should be configured for the > implementation based on their target platforms (which indeed might be > turned down for low end targets)? It seems you're better off with the > latter approach as HTTP was already designed to negotiate that stuff and > then it can evolve naturally as platforms become more capable. I think Michael was brainstorming also from the perspective of a developer for such low-end platforms. I have not enough understanding of TLS and HTTP(S) details to make a good judgemenet if low end devices would end up having to code & signal more and more unnecessary baggage along the line of evolution of these protocols - or not. Assuming of course they didn't need any new features but just had to follow the evolution anyhow to not be left behind by bigger peers. Cheers Toerless > hth.