http2 opportunistic security negotiation

While digging further into server-side implementation details of the
current opportunistic security draft, we identified a user experience
problem.  In particular, for a site that has Virtual Hosts which are
HTTP-only (ie, there is no valid certificate for them), there is no way in
the current proposal to both support Opportunistic Security  (negotiate h2
for http scheme over TLS without a necessarily valid certificate) without
also giving users accidentally typing in https URIs a certificate mismatch
interstitial they'd be prompted to click through.

Based on a number of discussions, a preferable behavior when a client tries
to access an HTTP-only site over HTTPS is to error out the TLS negotiation
rather than present a certificate mismatch.  However, there is also a
desire for the TLS handshake for OppSec to look identical to a non-OppSec
handshake to external observers.  Because of this, the current proposal
(send alpn=h2 for OppSec http scheme and for https scheme) means the server
does not know whether to negotiate h2 for OppSec http or return a TLS
handshake error for "no certificate available for this hostname" which is
the desired https behavior).

One proposal that came out of some offline discussion would be for clients
capable of doing HTTP/2 OppSec to always send in the client_hello
alpn=h2,h2o  (where "h2o" here might be some alpn token for HTTP/2 OppSec
for HTTP scheme).
The server would then:

* Negotiate alpn=h2o with a possibly invalid cert for an HTTP-only
ServerName/Host
* Negotiate alpn=h2 with a valid cert for a ServerName/Host supporting HTTPS
* Return a TLS handshake error ("no cert for this hostname") if neither are
available  (eg, for HTTP/1.1)

The downside of this is that the "h2o" server_hello negotiation would be
in-the-clear in TLS 1.2 (not desirable), although it will be encrypted in
TLS 1.3.  In true "opportunistic" fashion this may be an acceptable
trade-off as clients and servers supporting TLS 1.3 will then get the
additional level of protection over passive eavesdroppers seeing whether
OppSec was negotiated.

Another positive of this approach is that it might be reasonable to also
use an "h1o" ALPN token to allow for OppSec negotiation of HTTP/1.1 over
TLS.  For example, extensions like "HTTPS Everywhere" could potentially use
this even without HTTP/2 support.  (The problem with an OppSec for HTTP/1.1
had been a lack of a way to negotiate the scheme securely, but a separate
ALPN token provides this.)

         Erik