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

Hi Adam,

> On 10 Jan 2018, at 12:34 pm, Adam Roach <adam@nostrum.com> wrote:
> 
> 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.

Not specifically. 

> Is the omission of wildcard-style origins intentional?

Yes, this was discussed a fair amount.

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

The common case for a wildcard cert is to support all of the origins covered by the wildcard. This is already supported by NOT using ORIGIN.

The other case is supporting *most* of the certs, but leaving some out. That would require us to have a way to say "NOT these origins", and that was judged too complex.


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

We don't generally document why we don't do things; that would make our RFCs much longer and more difficult to use. Making statements about the future doesn't seem like a great idea either.


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

Will be fixed in -05.

Thanks!


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 10 January 2018 03:01:40 UTC