Subject: Re: Time to refresh HTTP/2?

From: Lucas Pardue <[email-masked]>
Date: Mon, 7 Sep 2020 12:36:44 +0100

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 <[email-masked]> 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
>
>

---

From: Ian Swett <[email-masked]>
Date: Mon, 7 Sep 2020 19:41:42 -0400

I'd support:

1) Removing h2c!
2) Removing priorities entirely, but not adding anything new
3) Adding TLS 1.3
4) Adding GREASE, or at least clarifying the text to make it clear that
greasing is allowed, since there was some confusion on that.
5) Adding security considerations/etc for the Netflix/Purple Wolf attack
vectors.

Hopefully, not much else, besides errata.

Is the intent to change the ALPN?  Because given the
challenges GREASEing SETTINGS and various extension frames, I think that
could be helpful. +Bence Béky <[email-masked]>

On Mon, Sep 7, 2020 at 7:40 AM Lucas Pardue <[email-masked]>
wrote:

>> To be perfectly frank, I wasn't planning on addressing any of these.
>> It's a long and slippery slope.
>>
>> > turns out that they are not useful, or actively harmful,
>> implementations will be requested
>> 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.
>>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 08 Sep 2020 10:23:27 +1000

Thanks, that's a helpful list.

If you feel like adding anything, I'm keeping a list here: https://github.com/martinthomson/http2-spec/issues

On Tue, Sep 8, 2020, at 09:41, Ian Swett wrote:
> 5) Adding security considerations/etc for the Netflix/Purple Wolf 
> attack vectors.
> 
> Is the intent to change the ALPN?  Because given the challenges 
> GREASEing SETTINGS and various extension frames, I think that could be 
> helpful. +Bence Béky

I think that none of the above require anything that drastic.  What I would instead suggest is that the specification identify where there are challenges.   That is, it would mention that priorities exist, but explain that using them was not interoperable.  It probably needs to include the format of the frames in order to ensure that implementations know when to generate errors or not in relation to them (there are some MUST-level requirements that the unwitting might trip otherwise), but the semantic descriptions can be cut.