Surprisingly, we found that not only do our attacks remain possible, we can
even increase the damaging effects of our attacks by abusing new features of HTTP/2.
The paper goes on to describe why. The short version is a big part of HTTP/2's performance comes from header compression via the HPACK algorithm. Anything that compresses can be compromised if the attacker can inject data into the compressed output. This paper does a really nice job of concisely explaining BREACH and CRIME.
There's a provision in RFC 7541 that applies here. There's a way to indicate that a header field must not be compressed. Security-critical header fields such as keys and nonces should not be compressed. The RFC notes: "Note that these criteria for deciding to use a never-indexed literal representation will evolve over time as new attacks are discovered."
So the protocol has a feature for this. Everything that sends HTTP2 needs to update the list of fields not to compress, but that can be done by the sending end without any change to the receiving end.
True, but the HTTP/2 people were building a wrapper for data, not a security protocol. At least they put in a feature to suppress compression. Because of that, this can be fixed from one end; it's not necessary to deploy new browsers.
That casual dismissal can be applied just as casually to the entire history of networking technologies, and it would be just as lazy and intellectually dishonest.
I don't think it's that surprising, it's pretty much a truism that more features mean more complexity, chance for bugs, and attack area --- especially features which have yet to mature for a while in practical use.
Interesting!