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

Please also see Jouni Korhonen's OpsDir review for nits and similar.

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

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.

   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

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.