constraining scheme (http vs https) on a connection

[Erik Nygren <[e-mail]>]

In some recent discussions, it has come up that we don't clearly specify
whether multiple schemes (eg, http and https) can share a single
connection.  For example, if www.example.com  has a valid certificate for
www.example.com then by the reading of rfc7540 a client could potentially
use a single connection for http://www.example.com/ and
https://www.example.com/

By the reading of rfc7540, it also seems like if www.evil.com resolves to
the same IP address as www.example.com (which www.example.com has no
control over) a client might be willing/able to send requests over the
www.example.com connection?

This seems like it has the potential for confusion.  For example, if
www.example.com is using client cert auth.  Or if a server is
distinguishing HTTP vs HTTPS based on port number as described as a risk in
draft-ietf-httpbis-http2-encryption and discussed here.  There also seem
like some potential attacks that become easier if a client is making HTTP
requests over HTTP/2 sharing a connection with HTTPS.  (For example,
side-channel attacks between HTTP and HTTPS seem easy here, and there might
be some compression based attacks.)  Am I alone in thinking this connection
sharing (which servers can't really control today outside of returning a
421 for HTTP-scheme requests) is a bad idea?

Some things seem worth considering here:

* The ORIGIN frame helps here as an origin can list only supporting the "
https://www.example.com" origin.

* We likely want to have draft-ietf-httpbis-http2-encryption prohibit
sharing requests for secure and non-secure schemes over a single
connection, even if authenticated.

Is there any other guidance we should be proposing on this front?  For
example, to discourage clients from doing this sharing and to encourage
servers to return 421 if they see mixed schemes on a connection?

Best, Erik