My basic fear here is that, in order to make this work, we will essentially be required to reinvent much of TLS. I strongly suspect it would be easier to start with TLS providing only integrity and go from there. -=R On Tue, Nov 19, 2013 at 2:41 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Nov 19, 2013 at 01:13:45PM -0800, James M Snell wrote: > > At Mark's urging, I've posted a significantly updated draft of the > > "in-session key negotiation" draft that I had published last year. > > Please treat this as purely experimental at this point. I am not > > pushing this as a proposal just yet, just offering it up as one > > possible approach to providing message-level security as opposed to > > transport-level security. > > > > As always, feedback is welcomed and requested. > > First the trivial: > > Considering the importance of id header, should it be marked as > HTTP/2 internal header (:id)? > > > And then what makes me bit nervous: > > What about proxy doing things like: > - Changing the protected payload. Including a MAC will prevent this. > - Changing the order or replaying protected payload segments. Adding > sequence number or nonce to MAC will prevent this. > - Changing the stream of protected payload segments. No idea how to > protect against this. Stream number would have to be included, but > server's and client's views differ. > > Those may or may not matter, depending on the application. > > > -Ilari > >
Received on Tuesday, 19 November 2013 22:47:11 UTC