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

On 1/10/18 2:28 PM, Mark Nottingham wrote:
>
>> On 11 Jan 2018, at 3:04 am, Adam Roach <adam@nostrum.com> wrote:
>>
>> On 1/9/18 9:01 PM, Mark Nottingham wrote:
>>> 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.
>> 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.
> We didn't discuss the particular mitigation that you suggest; that doesn't mean we didn't discuss the risk overall, along with several other potential mitigations (as outlined in the document, along with some others on the cutting room floor).
>
> What's the nature of the additional treatment you'd like to see? Please note this has been discussed pretty extensively in the WG, and the current text represents a consensus that I believe takes your point of view into account (i.e., I don't see any new argument here).
>
> Later, you say:
>
>> I've always viewed DNS + TLS as kind of a belt-and-suspenders kind of thing, where one needs to mount two (usually unrelated) exploits to successfully hijack an origin. I'm uncomfortable with backing down from that, but this might just be due to a misperception on my part: is CT deployed broadly enough that it provides a viable backstop against such attacks? (On a quick glance, I believe that zero of the ten defects I cited in my earlier message would have been thwarted by OCSP).
> I think I agree if you mean OCSP-as-deployed, but note that the suggested mitigation in the document is to positively require they have a recent OCSP response that shows the certificate was not revoked, which is different than what's currently done by most browsers. Or CT (as discussed).

I find Patrick's answer here compelling. I think the big problem I had 
here was the hand-wavy nature of the Security Considerations (the 
repeated use of "ought to" seems like deliberately steering around 
normative behavior). The apparent state of CT deployment makes this much 
better, so I'm happy to let it drop.

As an aside, I suspect that the references to "Remote Authentication 
Dial In User Service (RADIUS) Protocol Extensions" are not intended? My 
best guess is that these were supposed to point at RFC6962 rather than 
RFC6929.

>>>> 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.
>> 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?
> Yes.
>
>
>>> 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 processing <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/> right now, and the introduction includes significant discussion of design rationale, including in particular why certain things were not done.
> I'm not disputing that in some circumstances it makes sense to define architecture or otherwise illuminate decisions. However, it's a judgement call as to what's appropriate to document in these cases, and in my judgement (as an editor of this document), this doesn't need explaining; it follows from the design. If we explained everything that people didn't understand on a first reading of the document, it would quickly become unreadable.
>
> That said, I would agree with an argument that we should explicitly say that they aren't supported, so as not to confuse.

Yes, please do that. It would also (in my opinion) be worthwhile 
mentioning that using ORIGIN is incompatible with the use of wildcard 
certs to indicate authority over wildcarded origins; but, if you don't 
want to, I'm not going to press the point.

/a

Received on Wednesday, 10 January 2018 20:53:08 UTC