reframing draft-ietf-httpbis-http2-encryption to focus on deployment aid rather than security?

Based on some discussions in Prague, one of the challenges with
draft-ietf-httpbis-http2-encryption is that it is trying to serve two
purposes where some trade-offs need to be made between them.

The first purpose is to enable the deployment of HTTP/2 for "http" scheme
traffic over the open Internet by encapsulating it within TLS to avoid
causing problems with middle boxes.  The second purpose is to defend
against pervasive monitoring by purely passive adversaries.

The current document is focused on the second purpose (opportunistic
security), with first (deployment aid for http scheme traffic) as a side
benefit.  At least some potential implementors are more interested in this
first deployment aid and have little-to-no interest in doing this purely
for opportunistic security.

I'd suggest that we consider refocusing the document to treat 'deployment
of HTTP/2 for "http" scheme traffic' as primary with opportunistic security
against purely passive adversaries being a nice side-benefit.

This might not change too much technical content, but might change interest
in implementing this functionality.  In particular on technical details:

* Clients would still want to treat this as "http" scheme traffic and show
no security indicators

* We could either continue to ignore server certificate mismatches or
perhaps require or strongly encourage anonymous authentication  (eg,
TLS_ECDH_anon_WITH_AES_128_GCM_SHA256)

* Negotiating those mode explicitly with its own ALPN token makes some
things safer and easier (although does make things marginally easier for
semi-active attackers who can block those connections to force fallback,
but those same attackers could just as easily try and block TLS for SNI
values where HTTP cleartext sends an Alt-Svc).

Having a separate ALPN token has the benefit that it means that there would
not be confusion between clients and servers about whether they support
this functionality.  A risk highlighted in a mail thread a month or so ago
is that many server implementations effectively ignore :scheme and look
purely on the port and :origin.  While arguably a bug, this seems like a
very common implementation behavior with servers negotiating the "h2" ALPN
token.

For better or worse, a separate ALPN token does mean that middle boxes
could terminate this traffic in cases where today they terminate clear-text
http traffic as long as they correctly know how to implement HTTP/2.  If
our focus is on TLS as a deployment aid for http/2 then this is not a bad
thing.  And even for opportunistic security, traffic is still at least
encrypted hop-by-hop on the wire, and any middle box that could do this is
already an active attacker that could find some other possibly more
invasive/problematic heuristic for intercepting opp sec traffic.

What are peoples' thoughts on shifting the focus in this manner?  Would it
make you more or less willing to implement?

    Erik