Adam Roach's No Objection on draft-ietf-httpbis-origin-frame-04: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-origin-frame-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/



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

Received on Wednesday, 10 January 2018 01:35:08 UTC