One of the approaches considered for improving security is opportunistic encryption.
Two variants have been discussed; "relaxed" where server authentication is not checked, and "strict", where it is. In discussion, it appears that there's a preference for just using HTTPS URLs over "strict", but there is still some interest in "relaxed."
There appears to be some implementer interest in this approach, but not yet readiness to implement, so this issue is on hold.
Note that opp encryption might also be applied to HTTP/1.1.
See a breakdown of terminology at:
The description of this topic still only lists draft-nottingham-http2-encryption as an approach. Please add draft-hoffman-httpbis-minimal-unauth-enc, which does opportunistic encryption in a very different way than draft-nottingham-http2-encryption.
Discussed in Zurich; further discussion in London; mark and patrick to revise draft and experiment. However, this will not block HTTP/2 unless delay is minimal.
Notes from Zurich:
authenticated == HTTPS
not WebPKI-authenticated (TACK? DANE? ETC. ETC.) -- NOT US
a. In-band Hint (header) - optional to use.
b. DNS -- not now.
c. use existing 443 connection for defaulted ports - some interest (esp. in addition to other mechanisms); needs refusal. SETTINGS indicator for support; refusal error code (?)
d. encryption inside HTTP/2 -- no
e. speculative connection -- we will say nothing about this
i. Refusal (you got the endpoint wrong)
ii. implicit shortcut
Discussed in London; support for documenting this.
See also: http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00
which was discussed in UTA.
@mnot What are the fundamental difference between opportunistic TLS and RFC 2817?
@mcilvena take it to the mailing list? RFC2817 is quite different than the current Alt-Svc proposal. See http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03
https://tools.ietf.org/html/draft-nottingham-http2-encryption-03 is the latest proposal in this regard.
Discussed in NYC; agreed to adopt as WG Experimental. Martin to edit.