- From: Adam Roach <adam@nostrum.com>
- Date: Wed, 10 Jan 2018 11:47:08 -0600
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>
- Cc: httpbis-chairs@ietf.org, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-origin-frame@ietf.org, ietf-http-wg@w3.org
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