Document Action: 'Opportunistic Security for HTTP/2' to Experimental RFC (draft-ietf-httpbis-http2-encryption-11.txt)

The IESG has approved the following document:
- 'Opportunistic Security for HTTP/2'
  (draft-ietf-httpbis-http2-encryption-11.txt) as Experimental RFC

This document is the product of the Hypertext Transfer Protocol Working
Group.

The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa
Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/




Technical Summary

This document presents an experimental way to use RFC 7838 to achieve opportunistic
encryption connections to http:// schemed resources. While this does not offer
the true security guarantees of the https:// scheme, it does improve resistance
to passive surveillance by requiring some minimal level of active attack to
defeat.

Working Group Summary

The document has been closely reviewed and discussed by a small number of vocal
participants, with a larger number of other participants adding occasional
feedback. The community is generally divided about the utility of providing a
tool which is so easily defeated by an active attacker, but there have been very
few who believe this experiment would be detrimental. The primary concern voiced
by dissenters has been that widespread deployment might provide a false sense of
security, slowing the adoption of "real" HTTPS or confusing users. The
restriction in section 4.1 was added to help mitigate this concern.

RFC 7838 requires "reasonable assurances" that the alternative was under the
control of the same authority as the origin. RFC 7838 defines only one means of
having such assurance: possession of a TLS certificate for the origin. After
much discussion, this draft maintains that definition and requires the use of
fully verified certificates.

The other item of particular concern around using RFC7838 with http:// URIs was
server support for receiving requests for http:// schemed resources on ports
configured to use TLS. While HTTP/1.1 might permit and HTTP/2 mandates the
inclusion of the URL scheme with the request, it appears that almost no server
implementations treat the included scheme as more authoritative than the port on
which it was received. This is noted in section 4.4. As a result, the final
version of this document prohibits the use of HTTP/1.1 and uses the .well-known
resource as a server's self-certification that it can correctly distinguish such
requests.

A primary learning from experimentation with this draft will be to what degree
this server behavior presents a deployment issue in the real world, and the
degree to which servers will incorrectly claim this capability.

Document Quality

There is a client implementation in Mozilla Firefox, though other browsers have
expressed limited interest at this time. No explicit implementation of this
draft is required in server software (the necessary resources and headers can be
administratively configured).

Personnel

Mike Bishop is the document shepherd; Alexey Melnikov is the responsible Area
Director.

Received on Monday, 20 March 2017 21:32:41 UTC