W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 19 Nov 2013 14:46:42 -0800
Message-ID: <CAP+FsNej59agKZ+fQJGjQ4-d6O12JKDz0ghJfOWSZC8bR4u9RA@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC