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
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
handshake
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
[adjourned]