> I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct?

Yes, the server can ignore both and always start a new session. And you could modify a client to never send either, but if you are already modifying the client code you could also modify it to always use a separate connection.

> HTTP/2 over cleartext TCP is also possible?

In theory yes, in practice most will only implement it over TLS, to avoid middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2, so it'll fallback cleanly in that case.

> Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?

Alt-Svc to a different hostname will always use TLS. From the draft: "Clients MUST NOT use alternative services with a host that is different than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin."

And with current TLS, the hostname is sent on the handshake (SNI), so it can't use the same session for different hostnames.

I think the security.ssl.disable_session_identifiers pref in Gecko browsers is meant to allow for it without modifying the code, and I haven't spotted a similarly easy way of controlling HTTP/2 connections. Otherwise, point taken.

Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?