Received changes through RFC Editor sync (created alias RFC 8164, changed abstract to 'This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks.  This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.', changed pages to 10, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2017-05-10, changed IESG state to RFC Published)

[Ballot comment]
I'm balloting "yes", but I have a few minor comments:

- Abstract: I agree with the GenART review that the limitations should be mentioned in the abstract, or at least early in the document.

- Note to readers: Will this stay in the RFC?

- Introduction: What is the nature of the experiment? Is there an expectation to promote it to standards track in the future? Even if the answer is "We need to get implementation/deployment experience", it's helpful to say "out loud".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpbis-http2-encryption-10.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new registration will be made as follows:

URI Suffix: http-opportunistic
Change Controller: IETF
Reference: [ RFC-to-be ]
Related information:
Date registered: [ TBD ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed
upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: draft-ietf-httpbis-http2-encryption@ietf.org, alexey.melnikov@isode.com, ietf-http-wg@w3.org, httpbis-chairs@ietf.org, michael.bishop@microsoft.com
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-httpbis-http2-encryption-10.txt> (Opportunistic Security for HTTP) to Experimental RFC

The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'Opportunistic Security for HTTP'
  <draft-ietf-httpbis-http2-encryption-10.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document describes how "http" URIs can be accessed using
  Transport Layer Security (TLS) to mitigate pervasive monitoring
  attacks.

Note to Readers

  Discussion of this draft takes place on the HTTP working group
  mailing list (ietf-http-wg@w3.org), which is archived at
  https://lists.w3.org/Archives/Public/ietf-http-wg/ .

  Working Group information can be found at http://httpwg.github.io/ ;
  source code and issues list for this draft can be found at
  https://github.com/httpwg/http-extensions/labels/opp-sec .

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/ballot/

No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for HTTP Opportunistic Security

## 1. Summary

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

This document presents an experimental way to use
[Alt-Svc](https://tools.ietf.org/html/rfc7838) 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.

## 2. Review and Consensus

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.

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).

## 3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related
to this document has already been disclosed, in conformance with BCPs 78 and 79.
No IPR disclosures have been submitted regarding this document.

## 4. Other Points

There are no downward references. The IANA Considerations are clear, and the
Expert Reviewer for the affected registry is an author of this draft.

# Shepherd Writeup for HTTP Opportunistic Security

## 1. Summary

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

This document presents an experimental way to use
[Alt-Svc](https://tools.ietf.org/html/rfc7838) 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.

## 2. Review and Consensus

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.

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).

## 3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related
to this document has already been disclosed, in conformance with BCPs 78 and 79.
No IPR disclosures have been submitted regarding this document.

## 4. Other Points

There are no downward references. The IANA Considerations are clear, and the
Expert Reviewer for the affected registry is an author of this draft.