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

On 1/10/18 11:24 AM, Stephen Farrell wrote:
> Hiya,
>
> On 10/01/18 16:04, Adam Roach 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.
>>
> Just want to check a thing - if one added some DNS check, am
> I right that any privacy benefit of the ORIGIN frame might
> then be lost? If so, maybe this is more of a trade-off? If
> not, then maybe I'm just as confused as usual;-)

I didn't see this mechanism billed as a privacy enhancement. If that's 
part of the impetus, it's certainly worth mentioning in the Introduction 
and/or Security Considerations section. But, in actuality, I would 
prefer that it not: if DNS privacy is desired, then a more comprehensive 
solution (such as those coming out of DPRIVE) is more appropriate than a 
partial solution that exposes some (but not all) origin names to a 
presumed hostile DNS server.

But even if the draft is reconstrued to also be a privacy-related 
mechanism, the trade-off you hint at above needs to be discussed.

In thinking through the privacy implications you bring up, I noticed 
another potentially problematic aspect of ORIGIN that probably needs 
treatment in the Security Considerations section. With the ongoing work 
to hide SNI from third-party observers [1], OPTIONS may divulge more 
information to such a third party than would otherwise be easily 
obtainable: if I see you connect to an IP address, I can connect to the 
same destination and wait for OPTIONS frames to indicate to me all of 
the potential hosts you could be actually looking for.

/a

____
[1] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 (yes, I 
know *you* are aware of this -- I'm citing it for other people who may 
not be).

Received on Wednesday, 10 January 2018 17:48:16 UTC