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

On 1/9/18 9:01 PM, Mark Nottingham wrote:
> Hi Adam,
>> On 10 Jan 2018, at 12:34 pm, Adam Roach <> 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.

Given that Mistakes Do Happen[1][2][3][4][5][6][7][8][9][10], it seems 
it probably should have been. I believe the document needs a bit more 
treatment of this issue before it moves forward.

>> 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://*" 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.

So it ends up being an either/or proposition, then? That is, if I've 
claimed authority for a set of origins using a wildcarded cert, then I 
can't use the ORIGIN frame without blowing that away, right?

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

I agree that the complication involved in introducing a mechanism like 
this is not warranted by its utility.

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

On the contrary, when a question is obvious but its answer is not, RFCs 
will frequently include rationale. For example -- we're in the middle of 
right now, and the introduction includes significant discussion of 
design rationale, including in particular why certain things were not done.



Received on Wednesday, 10 January 2018 16:08:09 UTC