- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 19 Nov 2013 14:49:17 -0800
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CABP7RbdVN83b8xCWgUXbnDkb0T5zOYgZttUxUY5zg=Q2R5afFA@mail.gmail.com>
On Nov 19, 2013 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)? > Possibly yes. > > And then what makes me bit nervous: > > What about proxy doing things like: > - Changing the protected payload. Including a MAC will prevent this. Yep. I intentionally left this out and define it as a property of the negotiated agreement. In other words, I decided to punt on it for now :) > - 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:49:46 UTC