Code change:
protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

Related discussion:
text: I would point out that that volume of unproductive traffic is probably a good reason to use something other than a key update to deal with the sender. A reminder that the underlying analysis assumes that packets are all 2^14 in size, which is the record size in TLS. This is ~10 times larger than typical MTU on the Internet and many QUIC packets might be smaller than that, so - at least for AES-GCM - recommending a 2^36 limit is more conservative than necessary. However, if we were to allow for different limits, we'd have to address the question of packet size, as a 2^16 byte packet will be used by some deployments. For ChaCha20+Poly1305, the only value that matters is the number of packets, so we avoid that question. Quoting from Felix's email for reference (with permission):
NAME Can I request that you review this analysis for correctness? I know that you had reservations about the claims here.
Another (simplier?) option could be to just update keys much more often. I've done performance tests with msquic on the effect of updating the key ~once per round trip. There was no noticeable effect on performance. In fact, more often than not, the key update perf tests happen to perform slightly better (within noise tolerance) than without key update. I'm not suggesting we advocate once a round trip or anything near that; more like every 2^20 packets (or 2^30 bytes?) sent or received (including failed decryptions). As I understand it, this is an ultra conservative number as far as protecting from any kind of attacks, and should be free as far as any performance impact on the connection. This also has the added benefit of exercising the key update scenario more often, which should hopefully improve interoperability of the feature.
I support a change like this, but I am not qualified to say what the thresholds should be. There certainly isn't a reason to push it to very high limits. This change would not break interoperability, so it's a good one. Banning CCM might break interoperability for someone, but I'm not too concerned, particularly if we can update all the browsers to not offer it.