The ORIGIN HTTP/2 Frame
draft-ietf-httpbis-origin-frame-06

[Ballot comment]
I'm in agreement with Adam on his first comment and am watching the thread for a resolution.  Whether or not there is a change, more text is clearly needed in the draft.

[Ballot comment]
I share Adam's concern about removing the need for the DNS check and his question about wildcards.

-2, first sentence: I originally read this as citing RFC 7540 for "Origin HTTTP/2 frame" rather than just "HTTP/2 frame". That is, of course, non-sensical, but the wording seems ambiguous.

[Ballot comment]
This seems a good mechanism overall. The security property of no longer requiring DNS checks seems a slight bit troublesome, as it (as the draft acknowledges) makes mounting an attack significantly easier: all that is required is exploiting a CA, rather than the two-step process of doing that plus hijacking DNS in some way. Was there consideration given to advising that implementations perform DNS checks after the fact? This would provide the latency benefits this mechanism is defined for while allowing at least for detection of origin hijacking.

Is the omission of wildcard-style origins intentional? Or was this an oversight? It seems that being able to, e.g., send an ORIGIN frame that claims authority over "https://*.blogspot.com:443" would be far more efficient than blasting out the several million or so origins that such machines would be authoritative for (yes, I know this won't be done in practice -- such domains simply won't be able reap the benefits of this mechanism). Ideally, I'd like to see text in here explaining why wildcards shouldn't be specified, or indicating that they might be specified in a future document.

Minor nit in Appendix B:

  Generally, this information is most useful to send before sending any
  part of a response that might initiate a new connection; for example,
  "Link" headers [RFC5988] in a response HEADERS, or links in the
  response body.

Presumably, this should reference [RFC8288].

[Ballot comment]
I don't object to publishing this document, but I do have an honest question. Is OCSP sufficiently robust and stable that you're expecting OCSP checks to work as a security mitigation?

I remember some concerns about that in the SIP community, probably three years ago, and thought I should ask before the document is approved.

[Ballot comment]

  The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to
  indicate what origin(s) [RFC6454] the server would like the client to
The citation here is to the frame format. I think you could make this clearer and also point the user to that section for the conventions,



  The ORIGIN frame type is 0xc (decimal 12), and contains zero to many
  Origin-Entry.
Nit: "zero or more" is conventional



      serialization of an origin ([RFC6454], Section 6.2) that the
      sender believes this connection is or could be authoritative for.
What are the semantics of a zero-length origin entry? It seems like an odd thing to allow.



  Note that for a connection to be considered authoritative for a given
  origin, the client is still required to obtain a certificate that
  passes suitable checks; see [RFC7540] Section 9.1.1 for more
"Obtain" seems confusing here. Perhaps "the server is still required to authenticate using"



  viable connection to an origin open at any time.  When this occurs,
  clients SHOULD not emit new requests on any connection whose Origin
  Set is a proper subset of another connection's Origin Set, and SHOULD
Nit: SHOULD NOT

[Ballot comment]
Need to chase minor changes based on AD review: some small changes were promised by editors.

IDNits reports:

** Downref: Normative reference to an Informational RFC: RFC 2818

RFC 2818 is already in the DownRef registry.

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

The IANA Services Operator has completed its review of draft-ietf-httpbis-origin-frame-04. 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. However, there is a problem with the way this action is currently described in the document.

In the HTTP/2 Frame Type registry on the Hypertext Transfer Protocol version 2 (HTTP/2) Parameters registry page located at

https://www.iana.org/assignments/http2-parameters/

a single new Frame Type will be registered as follows:

Code: [ TBD-at-registration ]
Frame Type: ORIGIN
Reference: [ RFC-to-be ]

The problem is that the authors have stated that the value for this assignment is 0xc, but we can't reserve values or guarantee that that value will be assigned. If another document requesting 0xc or the next two available values were to be approved for publication first, we would have to assign value 0xc to that document.

Either this document should note that 0xc is a suggested value, or the chairs (with WG and AD approval) should submit a request for the early allocation of 0xc, as described in Section 3 of RFC 7120. An early allocation lasts for one year and can be renewed for one additional year. Further renewals would require IESG approval.

If this message does not accurately describe the registry actions requested by the document, please contact us.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-11-30):

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, draft-ietf-httpbis-origin-frame@ietf.org, mcmanus@ducksong.com, ietf-http-wg@w3.org, alexey.melnikov@isode.com, Patrick McManus
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The ORIGIN HTTP/2 Frame) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'The ORIGIN HTTP/2 Frame'
  as Proposed Standard

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-11-30. 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 specifies the ORIGIN frame for HTTP/2, to indicate what
  origins are available on a given connection.

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/origin-frame.




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

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


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

# Shepherd Writeup for The ORIGIN HTTP/2 Frame

## 1. Summary

Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.

This document creates an [HTTP/2](https://tools.ietf.org/html/rfc7540)
extension for finer grained control of connection management than is
provided by the base HTTP/2 specification. In this context that
specifically means the set of origin names that may be served on one
connection. The document provides for changing that set to be both
smaller or larger than the default.

## 2. Review and Consensus

Participation in the document's review and discussion was unusually
broad based with members of the community from many roles taking part
(browsers, servers, CDNs, security engineers, etc..). There is broad
agreement that the functionality provides benefits to HTTP latency,
efficiency, and administrative flexibility.

Two key aspects of the draft, the ability to remove origin names from
the default set and the syntax to manage the set, underwent several
iterations based on the working group's feedback and arrived at a
strong consensus.

The aspects of this document dealing with the relationship of HTTPS
connection management and DNS were the most controversial and required
the most change to reach consensus. This mechanism addresses
experience with RFC 7540 which shows the existing DNS based mechanism
is administratively onerous and error prone. The change also has
benefits for performance and confidentiality. On the other hand, the
change increases the importance of proper certificate security because
key compromise can now be exploited without being an on-path attacker.

The final position of the draft is that an Origin extension relaxes
the requirements for name resolution (but never certificate
verification) if a client concludes the new risks are mitigated by
alternative signals that boost confidence in the certificate. The
Security Considerations deals with the topic at some length. This
position reached rough consensus.

There are statements of intent to implement from browser, servers,
and CDNs. There is an existing browser implementation.

## 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

The IANA Considerations are clear and there are no downward references.