Re: Time to refresh HTTP/2?

I'll add one more to the laundry list. In August 2019 Netflix disclosed
resource exhaustion vectors [1]. Given the range of affected
implementations, I wonder if there is any room to improve or expand RFC
7540 section 10.5

Lucas

[1] -
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

On Mon, Aug 31, 2020 at 1:14 AM Martin Thomson <mt@lowentropy.net> wrote:

> It seems like everyone wants their swing at this.
>
> To be perfectly frank, I wasn't planning on addressing any of these.  It's
> a long and slippery slope.
>
> But I will start a list and we can discuss where to draw the line.
>
> On Fri, Aug 28, 2020, at 23:00, Mark Nottingham wrote:
> > What about priorities?
>
> I would be opposed to publishing a new version with a replacement
> priorities scheme before that scheme were proven.  It might be OK to
> publish a version with text with the priority scheme removed, with a note
> about it not being interoperable in practice or some such.
>
> Here's some historical info that seems relevant.  The following text
> appears in the draft, commented out:
>
> > Note that stream dependencies have not yet been validated in practice.
> The theory
> > might be fairly sound, but there are no implementations currently
> sending these.  If it
> > turns out that they are not useful, or actively harmful, implementations
> will be requested
> > to avoid creating stream dependencies.
>
> While this might be true, I don't want a reprise.
>
> On Sat, Aug 29, 2020, at 00:54, Cory Benfield wrote:
> > I'm +1 on this as well. I'd like to see the extensions rolled in,
> > along with GREASE. I'm a bit more nervous about the priority changes
> > given how relatively young they are.
>
> Cory agrees with me, so I'm probably right....  As for GREASE, I'm
> reluctant to include new design work, but it might be small enough to meet
> the cut.
>
> On Fri, Aug 28, 2020 at 12:59:03PM +0200, Julian Reschke wrote:
> > Actually, I was going to suggest that as well, but mainly to align
> > HTTP/2 with the new core specs - it would be good to say how the cleanup
> > affects the references from HTTP/2.
>
> I definitely had that in mind.  My plan is to do that once the -core
> drafts leave the working group (so that there is no further risk of
> reshuffling.
>
> > Am 28.08.2020 um 13:27 schrieb Willy Tarreau:
> > +1 as well. Wouldn't it be an opportunity to also reference (or even
> merge)
> > the extensions such as RFC8441 which adds the ":protocol" pseudo-header ?
>
> I tend to think that 8441 wouldn't make the cut; it's discrete in the same
> way that the ORIGIN or ALTSVC frames are.
>
> On Fri, Aug 28, 2020, at 21:52, Julian Reschke wrote:
> > And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...
>
> 8740 might make the cut.
>
> Just to add to the list:
>
> * midders (or multiple trailers or whatever they are) are something I'm
> still uncertain about
> * a re-design that included better 0-RTT design is probably off the table
> * removing h2c is very tempting, with similar rationale to PRIORITY
>
>