Pervasive Monitoring and Secure Origins breakout session

29 Oct 2014

See also: IRC log




<scribe> scribenick:rigo

<scribe> Scribe:rigo

npdoty: proposed session, because all meetings discussed secure origins
... but no detailed presentation, goal is discussion
... citing RFC 7258 PM is an attack

<wseltzer> http://tools.ietf.org/html/rfc7258

npdoty: now question about what W3C could do

<wseltzer> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0222.html Chris Palmer, Proposal: Prefer secure origins for powerful new web platform features

npdoty: for some APIs should only be accessed through secure means
... discussion was in EME, Media, geolocation
... might use authenticated origin instead of s
... secure. Loaded with TLS
... also for mixed content specs
... 2 options for making use of this: block some APIs. Another is that permissions can not be persisted

<wseltzer> not persisted unless authenticated/secured origin

npdoty: but could also warnings, dialogs, browsing mode...
... goal for this session is to gather options and to discuss pros and cons

RW: also suggesting DANE in the Browser

christine: what are the risks of not doing anything

npdoty: suggestion thingss not loaded over TLS are insecure. Man-in-the-middle injection of javascript
... some attacker may insert scripts that accesses sensors (e.g. camera)

wseltzer: risk of man in the middle is a major concerns

BH: if we want https, we should all new features https only

??: yes, powerful APIs may lead to more https

npdoty: push back, if only goal is carrot or stick, this is not the most efficient way to do it
... need to select then

DanDruta: TLS as a hammer is not the best way to accommodate, Need transparency to server and user. There are use cases that are important.
... important to distinguish between malicious and necessary

HaraldAlvestrand: not sure approval of user is ever necessary
... we should not call it an end-to-end connection

<bhill2_> Also relevant from IETF discussion: https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-00

markw: we see ISPs modify responses and they break the service
... only first 90 bit were correct. Pretty bad experience. From that POV encryption is an advantage

<ddorwin1> On intermediaries injecting changes: http://arstechnica.com/security/2014/10/verizon-wireless-injects-identifiers-link-its-users-to-web-requests/

markw: putting it into W3C specs is not the best solution. Not just a switch, experimented. Show that 50% decrease in efficiency. Can't be done overnight. Need perhaps some hardware solution
... agree with objectives, not manipulating packets, but no short term solution

DanOB: create a system where you grant permission to certain people to manipulate data, not black/white

ddorwin perhaps also select computer where I do my online banking on

DanO: reasonable to make exceptions for TLS.
... maybe will affect mixed content pages
... not necessarily the exceptions that we imagine now

ddorwin1: .. missed ...

<keiji> This could be an example of possible risk on this issue. > FBI impersonated newspaper to finger school bomb threat suspect http://www.theregister.co.uk/2014/10/28/fbi_snoopware_ruse_newspaper_outrage/

markw: can do short term thing, hardware much longer

bhill2_: correlation handles. There is a role of middleboxes, but some of them lack trust. We have no choice but put user in control for end-to-end solution
... paper from mobile carriers about SSL impact on their networks had several categories: money, ad-injection... => middleboxes don't get it
... as W3C we have to talk to public policy. Perhaps some legal framework would allow reasonable middleboxes

npdoty: secure origin would perhaps allow that
... also hearing about transition process

<wseltzer> http://www.4gamericas.org/UserFiles/file/White%20Papers/SPDY_Impact_on_MBB_Ecosystem_and_VAS_June2014.pdf

npdoty: moving to warning before we turn off

<bhill2_> 4GAmericas paper on why they do middleboxes: http://www.4gamericas.org/documents/SPDY_Impact_on_MBB_Ecosystem_and_VAS_June2014.pdf

DanAV: where there is adequate protection beyond pages. Discussion about media stream transfer, offers possibility to have streams not accessible to javascript. In this case, no secure origin necessary

<hta> s/DanAv/hta

markw: specifically for media content is subresource integrity to fix that
... hashes are provided from https and the rest in clear would solve some of middleboxes, but would not solve privacy issues
... https does not solve that, pretty easy to obfuscate request and content, but still reversible
... traffic analysis of adaptively streamed video leads to fingerprint that can be used to ID what stream is being transmitted

npdoty: valid to consider threat model. Integrity is the most prominent.
... question of confidentiality have to be addressed differently

bhill2_: cut that feature from subresource integrity yesterday in WebAppSec, no hope for consensus in near term
... initial release only over https. Currently people are not ready to do subresource over http
... it is not validating the content, but also other ways where traffic is screwed by middleboxes
... you don't get confidentiality if you load a resource from a public location

markw: subresource only protects content, not headers

npdoty: will we get guarantees for the user?

markw: you suffer from the same issue, convey things with green padlock to user, but still leaking information

bhill2_: if you take https and you don't show the lock, they don't want to go into that
... encourages users to accept less

markw: represent the content in an https iframe. Horrible solution
... use secure techo as much as they can without representing to the user

<bhill2_> (notes correction: Subresource Integrity is still alive, just only for https resources)

DanOB: momentum to switch to secure comm is significant

<bhill2_> (intent of current SRI draft is to protect against compromised servers, not middleboxes)

DanOB: Yahoo was last remaining player to not encrypt email, was down to hardware prob
... but suffered huge amount of pressure to switch to TLS. So no carrot, but just huge expectation to go into that direction

ddorwin1: what we should aim at, Should be clearly setting expectations
... timelines etc

markw: think about real world problems, not only writing it into specs
... engaging with the real providers.

<scribe> scribenick: wseltzer

npdoty: also a problem for very small providers, e.g. students
... do local connections count as secure origins?

bhill2_: file is generally assumed to be trustworthy

hta: classic challenge in debugging and testing

npdoty: we have a sense of the challenge; timelines, goals, migration

DannyO'Brien: other issues, may or may not be in scope

scribe: integrity of binaries
... reliably reproducible builds

npdoty: also, verifying integrity or consistency of websites

DOB: applicaitons using tor to provide additional features on top of web

rigo: at STRINT, we talked about the CA problem
... DNSSEC+DANE as an alternative
... UI, what should DANE look like in the browser

npdoty: TOFU?

rigo: piggyback web sec on DNSSEC

bhill2: it's not the UI that's the problem, but lots of broken middleboxes that don't allow clients to receive DNSSEC info
... potential latency issues
... accordig to browsers
... agl had experimental DANE support in chrome and ripped it out because it was too slow

<scribe> scribenick: rigo

markw: getting people together and discuss could go hand in hand with changes to specifications

ND: what about small players. Have some time difficult with Students.

Sometimes load file locally.

bhill: still debating where to cross from public to private. Local still

counts as private. Unclear where we should allow to cross the line.

bhill: file is its own animal. (gives examples) file uploaded is

different from file downloaded

Alvestrand: debugging and testing is also difficult. Does not work for

testing. Send over network is no longer local.

DanOB: Out of scope for W3C. Integrity of binaries

ND: integrity of web site according to past visits

DanOB: Things like Tor turn into platform. Intersting to have

application that use Tor and not only to browse. Web is a platform

already, should extend to web-like interactions. Wider sets of tools

that underly web communications.

Bhill: Problem with middleboxes messing with DNSSEC, also problems for


wseltzer: how can we help with setting goals, timelines for deployment of https in the future; convene operators for that discussion?

gmandyam: Geolocation chair,: secure origin will have impact on many existing implementations. Start with an open call so peopele can give feedback
... if response in favor, evangelism to dev-community, sunrise period, look for all of that on geo-list

npdoty: may be good to ask other WGs to make that kind of process for trahsition

StHak: missed due to network issues

<wseltzer> markw: coordination challenge -- if a feature is available in some browsers but not others, people will blame the browser, not the insecurity

markw: migrate brand new features do not have compatibility issues

<wseltzer> ... so need timelines coordinated among implementers

<wseltzer> gmandyam: anyone advocating secure origins needs to propose implementations, sunset schedule

ddorwin1: new APIs have chance to have that integrated

<wseltzer> ddorwin1: for new features, specs should give preview of the coming challenges

npdoty: end of time, will post minutes to the wiki

further discussion on public-web-security mailing-list


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2014-11-07 22:40:30 $