Re: Time to refresh HTTP/2?

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 <bnc@google.com>


On Mon, Sep 7, 2020 at 7:40 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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
>>
>>