Require auth, clarify http-opportunistic use

For #234 and #235

draft-ietf-httpbis-http2-encryption.md

@@ -66,9 +66,9 @@ This document describes a use of HTTP Alternative Services {{RFC7838}} to decoup
 the URI scheme from the use and configuration of underlying encryption, allowing a `http` URI
 {{RFC7230}} to be accessed using Transport Layer Security (TLS) {{RFC5246}} opportunistically.
 
-Serving `https` URIs requires acquiring and configuring a valid certificate, which means that some
-deployments find supporting TLS difficult. This document describes a usage model whereby sites can
-serve `http` URIs over TLS without being required to support strong server authentication.
+Serving `https` URIs requires avoiding Mixed Content {{}}, which is problematic in many
+deployments. This document describes a usage model whereby sites can serve `http` URIs over TLS,
+thereby avoiding mixed content problems.
 
 Opportunistic Security {{RFC7435}} does not provide the same guarantees as using TLS with `https`
 URIs; it is vulnerable to active attacks, and does not change the security context of the
@@ -100,7 +100,7 @@ specification by providing an alternative service advertisement {{RFC7838}} for
 identifier that uses TLS, such as `h2` {{RFC7540}}.
 
 A client that receives such an advertisement MAY make future requests intended for the associated
-origin ({{RFC6454}}) to the identified service (as specified by {{RFC7838}}).
+origin ({{RFC6454}}) to the identified service (as specified by {{RFC7838}}), provided that the alternative service opts in as described in {{auth}}.
 
 A client that places the importance of protection against passive attacks over performance might
 choose to withhold requests until an encrypted connection is available. However, if such a
@@ -117,21 +117,18 @@ creating new TLS connections to alternative services for the purposes of this sp
 NOT present them. Established connections with client certificates MAY be reused, however.
 
 
-# Server Authentication {#auth}
+## Alternative Server Opt-In {#auth}
 
 {{RFC7838}} requires that an alternative service only be used when there are "reasonable
 assurances" that it is under control of and valid for the whole origin.
 
 As defined in that specification, a client can establish reasonable assurances when using a
 TLS-based protocol with the certificate checks defined in {{RFC2818}}.
 
-For the purposes of this specification, an additional way of establishing reasonable assurances is
-available when the alternative is on the same host as the origin, using the "http-opportunistic"
-well-known URI defined in {{well-known}}.
-
-This allows deployment without the use of valid certificates, to encourage deployment of
-opportunistic security. When it is in use, the alternative service can provide any certificate, or
-even select TLS cipher suites that do not include authentication.
+However, it is possible that the server might become confused about whether requests' URLs have a
+HTTP or HTTPS scheme, for various reasons; see {{confuse}}. To assure that the alternative service
+has opted into serving HTTP URLs over TLS, clients MUST check the "http-opportunistic" well-known
+URI defined in {{well-known}} before directing HTTP requests to it.
 
 When a client has a valid http-opportunistic response for an origin (as per {{well-known}}), it MAY
 consider there to be reasonable assurances as long as:
@@ -170,20 +167,12 @@ specification; it does not apply to other uses of alternative services unless th
 it.
 
 
-# Interaction with "https" URIs
+## Interaction with "https" URIs
 
 When using alternative services, requests for resources identified by both `http` and `https` URIs
 might use the same connection, because HTTP/2 permits requests for multiple origins on the same
 connection.
 
-Since `https` URIs rely on server authentication, a connection that is initially created for `http`
-URIs without authenticating the server cannot be used for `https` URIs until the server certificate
-is successfully authenticated. Section 3.1 of {{RFC2818}} describes the basic mechanism, though the
-authentication considerations in Section 2.1 of {{RFC7838}} also apply.
-
-Connections that are established without any means of server authentication (for instance, the
-purely anonymous TLS cipher suites) cannot be used for `https` URIs.
-
 Because of the risk of server confusion about individual requests' schemes (see {{confuse}}),
 clients MUST NOT mix "https" and "http" requests on the same connection unless the
 http-opportunistic response's origin object {{well-known}} has a "mixed-scheme" member whose value
@@ -235,9 +224,7 @@ used (e.g.,  a "lock device").
 
 ## Downgrade Attacks {#downgrade}
 
-A downgrade attack against the negotiation for TLS is possible. With commitment (see {{commit}}),
-this is limited to occasions where clients have no prior information (see {{privacy}}), or when
-persisted commitments have expired.
+A downgrade attack against the negotiation for TLS is possible. 
 
 For example, because the `Alt-Svc` header field {{RFC7838}} likely appears in an unauthenticated
 and unencrypted channel, it is subject to downgrade by network attackers. In its simplest form, an