Re: Fwd: New Version Notification for draft-snell-httpbis-keynego-01.txt

The bigger problem is that the proxy might prevent the negotiation from
occurring.
The only way to prevent this downgrade is to always require end-to-end
integrity. Without it, one can make no assertions.
-=R


On Tue, Nov 19, 2013 at 2:49 PM, James M Snell <jasnell@gmail.com> wrote:

>
> 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:54:45 UTC