IRC log of webappsec on 2015-10-28

Timestamps are in UTC.

23:36:26 [RRSAgent]
RRSAgent has joined #webappsec
23:36:26 [RRSAgent]
logging to
23:36:36 [wseltzer]
rrsagent, this meeting spans midnight
23:36:44 [wseltzer]
trackbot, start meeting
23:36:46 [trackbot]
RRSAgent, make logs world
23:36:48 [trackbot]
Zakim, this will be WASWG
23:36:49 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
23:36:49 [trackbot]
Meeting: Web Application Security Working Group Teleconference
23:36:50 [trackbot]
Date: 28 October 2015
23:37:48 [wseltzer]
Meeting: Web Application Security Working Group F2F, Day 1 (TPAC)
23:40:56 [wseltzer]
23:41:16 [wseltzer]
wseltzer has changed the topic to: TPAC Meetings, Oct 28, 29.
23:42:15 [colin]
colin has joined #webappsec
23:46:39 [bhill2]
bhill2 has joined #webappsec
23:50:42 [SIN_]
SIN_ has joined #webappsec
23:51:50 [kiyoung]
kiyoung has joined #webappsec
23:52:48 [francois]
francois has joined #webappsec
23:53:14 [bhill2]
bhill2 has joined #webappsec
23:57:09 [twhalen]
twhalen has joined #webappsec
23:59:08 [cscho]
cscho has joined #webappsec
00:00:26 [ygkim]
ygkim has joined #webappsec
00:03:24 [bhill2]
Meeting: WebAppSec F2F, TPAC 2015, 29-Oct-2015
00:03:30 [bhill2]
Chairs: bhill, dveditz
00:03:35 [deiu]
deiu has joined #webappsec
00:03:38 [bhill2]
00:03:43 [deiu]
present+ deiu
00:03:49 [Min]
Min has joined #webappsec
00:04:18 [keiji]
keiji has joined #webappsec
00:04:23 [francois]
present+ francois
00:04:36 [Kepeng]
Kepeng has joined #webappsec
00:04:37 [wseltzer]
present+ wseltzer
00:04:37 [ccho4]
ccho4 has joined #webappsec
00:04:43 [bhill2]
present+ bhill
00:04:48 [keiji]
present+ keiji
00:04:53 [dveditz]
present+ dveditz
00:04:58 [twhalen]
present+ twhalen
00:05:02 [Kepeng]
present+ Kepeng
00:05:04 [rbarnes]
rbarnes has joined #webappsec
00:05:05 [Mek]
present+ mek
00:05:08 [rbarnes]
00:05:14 [colin]
00:05:20 [Kazue]
Kazue has joined #webappsec
00:05:35 [kodonog]
kodonog has joined #webappsec
00:05:56 [wseltzer]
present+ rbarnes, colin
00:08:54 [cscho]
present+ cscho4
00:09:10 [jyasskin]
jyasskin has joined #webappsec
00:09:14 [dveditz]
00:09:15 [bhill2]
agenda link:
00:09:17 [jyasskin]
present+ jyasskin
00:09:59 [JeffH]
JeffH has joined #webappsec
00:10:58 [dveditz]
scribe: JeffH
00:11:02 [mkwst]
present+ mkwst
00:11:05 [bhill2]
TOPIC: minutes approval
00:11:08 [cscho]
present+ cscho
00:11:32 [bhill2]
00:11:40 [bhill2]
minutes unanimously approved
00:12:23 [JeffH]
present+ JeffH
00:12:50 [JeffH]
WebAppSec WG Update preso by bhill2
00:12:57 [npdoty]
npdoty has joined #webappsec
00:13:13 [npdoty]
rrsagent, pointer?
00:13:13 [RRSAgent]
00:13:32 [npdoty]
present+ npdoty
00:13:43 [JeffH]
00:14:12 [jungkees]
00:14:27 [jungkees]
Can we add it to the secure context agenda?
00:15:15 [JeffH]
link to preso?
00:15:28 [wseltzer]
00:15:33 [wseltzer]
^Brad's slides
00:16:15 [JeffH]
00:16:49 [JeffH]
on Broad Themes slide #3
00:20:07 [JeffH]
S #6 subresource integrity SRI
00:20:22 [JeffH]
s 7: Referrer Policy -- fpwd
00:20:42 [JeffH]
s 9: upgrade insecure requests
00:20:55 [JeffH]
s 10: UI Security
00:22:13 [JeffH]
s 11: Cred mgmt
00:22:41 [Kepeng]
00:22:43 [JeffH]
bhill2: questions?
00:24:10 [JeffH]
?: asks about diff btwn "creds mgmt" spec and the work in "creds CG"
00:24:54 [JeffH]
bhill2: the latter is about "creds" like driver licenses, not username/pswds which is what creds mgmt spec is about
00:25:56 [kodonog]
present +kodonog
00:25:59 [JeffH]
mikwest: creds mgmt api is extensible and we are working to take into account the creds CG's use cases
00:27:21 [npdoty] (world-readable link, per bhill)
00:28:34 [npdoty]
q+ to ask about clear-site-data or private browsing
00:29:34 [JeffH]
mkwst: have secveral specs trying to give websites better functionality to ease migtation to https, eg upgrade insecure requests
00:29:39 [bhill2]
ack Kepeng
00:29:42 [bhill2]
ack npdoty
00:29:42 [Zakim]
npdoty, you wanted to ask about clear-site-data or private browsing
00:29:59 [JeffH]
npdoty: curious about clear-site-data
00:30:12 [bhill2]
00:30:41 [JeffH]
mkwst: there is a spec, have someone impl'g this qtr, will have impl early nxt yr. spec has been stable.
00:30:53 [deiu]
q+ to ask about error codes (API) when mixed content load errors are triggered
00:31:26 [JeffH]
mkwst: some discussion re private browsing mode -- eg webapp policy to only be loaded in incognito mode -- need to restart that discussion
00:31:33 [sangrae]
sangrae has joined #webappsec
00:32:24 [JeffH]
?: wrt private browsing mode aka icognito, went to women's shelter for use case, they didn't think would make sense to require all users of their webapp to use incognito mode
00:33:19 [JeffH]
?: they are thinking that having some sort of way for user to "clear all website data" for given site/webapp is better way to go -- mkwst: please chat with Tara et al
00:33:37 [Kepeng]
00:34:08 [bhill2]
ack deiu
00:34:08 [Zakim]
deiu, you wanted to ask about error codes (API) when mixed content load errors are triggered
00:34:11 [JeffH]
bhill2: webapp is authoritative for its data, but users' browsing history the user is authoratative for it, so would require some sort of user interaction
00:35:09 [npdoty]
s/?: wrt/francois: wrt/
00:35:17 [JeffH]
andre: is there any kind of api or way to get to the error when a mixed content req fails -- i as dvlpr don't get the info easily, but especially annoying for users, and no
00:35:39 [JeffH]
easy way for the webapp devlpr to display meaning ful into to user
00:36:02 [kiyoung]
kiyoung has joined #webappsec
00:36:38 [yoav]
yoav has joined #webappsec
00:37:04 [JeffH]
mkwst: there's ways to do that now eg leveraging CSP, TimBL was asking last night about a diff status code that comes back on XHR -- but there's limits such as if it is a redirect can't give the webapp access to the target of the redirct -- doing some thing like a status code or firing a mixedcontent event, pls file bug on the spec and make suggestions
00:37:38 [JeffH]
dveditz: folks often don't have onError on everything...
00:37:58 [JeffH]
mkwst: there's a variety of ways to give dvlprs the info they desire/need
00:38:21 [JeffH]
rbarnes: leery of giving folks "timing" apis for priv concerns
00:38:46 [JeffH]
mkwst: if u have specific concerns pls talk to web perf folks (they ahve timing apis...)
00:39:15 [JeffH]
rbarnes: just want to make sure that if we add anything we do it carefully
00:39:22 [npdoty]
I think francois's point was that a more valuable mechanism would be clearing recent history for all sites (so as to remove the search engine results page before you clicked on the particular site, for example) as opposed to private browsing mode for that whole origin, so it would be more like a prompt for browser ui for clearing local history
00:39:41 [wonsuk]
wonsuk has joined #webappsec
00:39:51 [keiji]
00:40:21 [JeffH]
bhill2: look at what info you get from CSP "default-src: https" -- think about the developer senario cuz it is diff w/XHR.
00:40:39 [bhill2]
ack Kepeng
00:40:52 [JeffH]
dveditz: hmm might be other ways to do it...mkwest: pls file bug
00:41:11 [bhill2]
ack keiji
00:41:14 [deiu]
00:41:53 [JeffH]
keiji: saw something about fido mentioned -- new web authn wg proposed -- what rel will have with cred mgmt api ?
00:42:52 [JeffH]
dveditz: cred mgmt api here is extensible and hopefully the web authn wg can use it as basis for its work
00:44:17 [JeffH]
mkwest: we want to think about creds sourced by say oauth, and perhaps that gives the creds CG what they need because they are somewhat similar
00:45:01 [JeffH]
bihill2: we can discuss this later today
00:45:11 [bhill2]
TOPIC: Subresource Integrity
00:45:35 [JeffH]
?: pretty much ready to go to CR, have some minor issues to address
00:46:00 [JeffH]
need to do a bit more work on test harness
00:46:08 [JeffH]
bhill2: we can go to CR with what we have
00:46:36 [JeffH]
dveditz: issues are spread across 2 diff repos, we need to move issues?
00:46:50 [JeffH]
?: pref would be to move issues
00:47:38 [dveditz]
00:47:47 [JeffH]
dveditz: issues of note
00:47:49 [dveditz]
00:48:04 [dveditz]
00:48:15 [dveditz]
00:48:25 [JeffH]
?: #486 - planning to do that one, but is in a diff spec so not blocking us
00:49:29 [JeffH]
francois: #363: needs more discussion -- bhill had good response to consider
00:50:28 [JeffH]
bhill2: devdatta has been asking questions about this also -- do we need to add explainer text for the current specs SRI and CSP?
00:50:51 [npdoty]
00:50:55 [JeffH]
bhill2: goals and thread models explained well in each sep spec -- not sure is worth it
00:51:46 [bhill2]
ack npdoty
00:52:00 [JeffH]
mkwst: would be useful to ahve a general explainer doc on how to use the suite of webappsec specs to construct a secure site -- -take this in consideration in CSP3 -- don't want to add to CSP2 which is almost done
00:52:18 [ccho4]
ccho4 has joined #webappsec
00:52:32 [keiji]
keiji has joined #webappsec
00:52:35 [JeffH]
ndoty: would be valuable to do overall explanation -- might be place to do some of this
00:52:44 [npdoty]
00:53:29 [npdoty]
npdoty: +1 to the goal, doesn't and shouldn't be in the specification which has a very different audience
00:53:50 [JeffH]
bhill2: better dvlpr doc would be a good thing, but getting folks signed up to do this work difficult, but thinks we can close this #363 in terms of its relation to SRI and CSP2
00:54:14 [JeffH]
bhill2: <does some changes to issues #363 to reflect this>
00:55:11 [bblfish]
bblfish has joined #webappsec
00:55:21 [JeffH]
dveditz: the other issue is secretarial -- so will send the transition message for SRI next week
00:56:12 [dveditz]
TOPIC: CSP 2 to REC status
00:56:23 [JeffH]
bhill2: have an impl rpt for CSP2
00:56:28 [npdoty]
00:56:33 [JeffH]
00:56:47 [JeffH]
see above
00:57:30 [cscho]
cscho has joined #webappsec
00:57:48 [JeffH]
bhill2: have 3 or 4 hundred tests for CSP2 but not everything is covered yet, so could use help in writing test cases
00:58:14 [JeffH]
see report linked above to see ones that need to be added
00:59:30 [JeffH]
overall status on CSP2 tests in chrome and FF -- see rpt above -- both browsers have CSP2 aspects still to implement
01:00:09 [JeffH]
bhill2: would prefer to go to Prop Rec having solid impls and test suite coverage
01:00:19 [JeffH]
francois: we will try to do that with SRI also
01:00:25 [cscho]
rrsagent, generate minutes
01:00:25 [RRSAgent]
I have made the request to generate cscho
01:02:00 [JeffH]
bhil2: to go to rec need all normative refs at same matiurity level -- there's ways to finess this -- but really want to have assurance of solid normative text when going to PR thus need test suite and impls to be solid
01:02:26 [ivan__]
ivan__ has joined #webappsec
01:02:37 [bhill2]
01:02:52 [JeffH]
BREAK TIME till 1030h local time
01:03:02 [wonsuk]
wonsuk has joined #webappsec
01:08:03 [wonsuk]
wonsuk has joined #webappsec
01:09:29 [npdoty]
npdoty has joined #webappsec
01:12:54 [keiji]
keiji has joined #webappsec
01:18:29 [keiji]
keiji has joined #webappsec
01:23:35 [gao]
gao has joined #webappsec
01:24:31 [yoav]
yoav has joined #webappsec
01:28:49 [yoav]
yoav has joined #webappsec
01:28:55 [SIN_]
SIN_ has joined #webappsec
01:29:38 [barryleiba]
barryleiba has joined #webappsec
01:30:47 [npdoty]
npdoty has joined #webappsec
01:31:10 [SIN]
SIN has joined #webappsec
01:33:00 [rbarnes]
rbarnes has joined #webappsec
01:33:53 [kiyoung]
kiyoung has joined #webappsec
01:34:05 [dveditz]
scribe: dveditz
01:34:15 [yoav]
Present+ yoav
01:34:18 [kodonog]
kodonog has joined #webappsec
01:34:25 [dveditz]
TOPIC: Secure Contexts
01:35:08 [dveditz]
bhill2: our calls have moved from "covering recent topics" to a rotation featuring a group of specs each meeting, rotating through the many specs we have over several weeks
01:35:35 [barryleiba]
present+ Barry Leiba
01:35:37 [dveditz]
mkwst: "Secure Contexts" is pretty close to done, a couple of topics worth discussing
01:35:43 [jungkees]
present+ Jungkee_Song
01:35:48 [bhill2]
01:36:13 [dveditz]
... a "Secure Context" needs to be delivered securely, e.g. over TLS (with some exceptions such as local file:///, loopbacks etc are considered secure)
01:36:35 [dveditz]
... diagrams showing how different contexts work with each other
01:37:37 [dveditz]
... we saw some "abuse" where inner secure frames fed data back to insecure frames
01:38:09 [dveditz]
... Example 2 (in spec): is a TLS popup from an insecure page a secure context?
01:38:25 [annevk]
annevk has joined #webappsec
01:38:33 [dveditz]
... yes, seems only tangentially related. we see this in the case of navigations for example.
01:38:44 [Kepeng]
Kepeng has joined #webappsec
01:39:01 [dveditz]
... would be strange to consider a secure page as not a secure context because it came from an insecure page.
01:39:18 [dveditz]
... however, there's a chance for leakage
01:39:41 [dveditz]
... also one could have a handle ( opener) and can postMessage() each other
01:39:52 [Melinda]
Melinda has joined #webappsec
01:40:04 [kazue]
kazue has joined #webappsec
01:40:20 [dveditz]
... there can be complicated situations. Talked a little with Travis from microsoft. he's concerned with this use-case
01:40:32 [ygkim]
ygkim has joined #webappsec
01:40:37 [dveditz]
... we might want to consider a popup as a tainted context
01:41:10 [dveditz]
rbarnes: we might want to do what we do with workers, just break the connection. Don't let the insecure context have a handle to the secure one
01:41:59 [dveditz]
mkwst: we have a referrer relation. the page can say "rel=noreferrer" and if we do that there's no leakage. We can consider it secure in that case
01:42:39 [dveditz]
... I've opened an issue with annevk to create a rel=noopener because sometimes you _do_ want the referrer and really were just using it for the noopener side-effect
01:43:11 [dveditz]
annevk: That's what makes it auxiliary, and if you break that then it's no longer an auxiliary context. No tainting
01:43:26 [dveditz]
... are we limiting broadcast channel?
01:43:41 [dveditz]
mkwst: there's still a variety of side-channels (message events, etc)
01:44:23 [dveditz]
... trying to make it more difficult to do the kind of shim Netflix has done. I don't think they would use a popup in this way
01:44:45 [dveditz]
... what Travis didn't like was that this would be difficult to implement in edge
01:45:19 [dveditz]
... he would like it so that if two things are same origin they have to have the same security context
01:45:57 [annevk]
Present+ annevk
01:46:14 [jyasskin]
q+ jyasskin document.domain?
01:46:25 [dveditz]
... we remove window.opener. can null out window returned from can still get a handle by naming it and then to the same name. once you have a reference there's a variety of ways to communicate
01:46:51 [dveditz]
... I don't think Chrome has iplemented broadcastMessage() like Firefox, but even without that there are storage change events and others
01:47:12 [bhill2]
01:47:17 [dveditz]
yoav: why would localStorage be hard? couldn't they pass the data by stuffing the answers in localStorage?
01:47:25 [npdoty]
what is the threat that we're trying to prevent against? a network attacker modifies an HTTP page, and opens an HTTPS page, and the HTTPS page collaborates with the network attacker?
01:47:36 [dveditz]
rbarnes: because they'd have to do so from a popup and we think they wouldn't want the annoyance of a popup
01:47:41 [bhill2]
ack jyasskin
01:47:44 [bhill2]
01:47:48 [bhill2]
ack document.domain?
01:47:48 [npdoty]
q- document.domain?
01:48:01 [dveditz]
jyasskin: do you want to bring up the document.domain question? Do you want to block access from a secure context?
01:48:27 [dveditz]
mkwst: yeah, I'd be happy to do that. we already restrict a number of things from secure contexts in chrome
01:49:11 [npdoty]
q+ to understand the threat of the network attacker
01:49:11 [dveditz]
annevk: but secure contexts are not opt in, how would you do that without breaking old sites?
01:49:35 [bhill2]
01:49:50 [dveditz]
mkwst: I'd do it the other way, touching document.domain turns off the secure context, possibly breaking access to objects the context already has references to
01:50:29 [dveditz]
annevk: or if you do something that requires a secure context (e.g register a service worker) then it turns off document.domain
01:51:17 [dveditz]
mkwst: question came up wrt service workers, should things that are not usable securely be invisible, or should they throw?
01:51:22 [bhill2]
ack npdoty
01:51:22 [Zakim]
npdoty, you wanted to understand the threat of the network attacker
01:51:32 [annevk]
01:51:40 [dveditz]
npdoty: I'm trying to understand the threat model here in the embedded iframe
01:53:10 [dveditz]
... if something is delivered over http with a link to https, that's a secure context. It may not be the one intended by the original author, but it's still secure
01:53:34 [dveditz]
... users can't see the origin of a frame, but they can in the case of a popup
01:53:35 [bhill2]
ack bhill
01:54:02 [dveditz]
bhill2: I see the threat model here as asking for permission, if the user sees one thing in the urlbar and the iframe is a different origin
01:54:25 [dveditz]
... everywhere else the context is authoritative for its origin, it's allowed to leak data if it wants to
01:55:27 [npdoty]
npdoty has joined #webappsec
01:55:59 [dveditz]
rbarnes: if we say feature X is only available to secure contexts then an attacker can frame a secure page and use postMessage to get access to that feature
01:56:26 [dveditz]
npdoty: are you worried that the framed site is collaborating with the attacker? you can always collaborate
01:56:44 [dveditz]
mkwst: it may not be intentional collaboration, it's just a feature that was found and used in that way
01:57:15 [dveditz]
bhill2: we're still not enforcing confinement here. we're stopping an obvious and convenient bypass but there are still other ways available
01:57:24 [dveditz]
mkwst: I agree, it's not complete isolation
01:58:12 [dveditz]
... I don't think it's necessary. It would be wonderful to do that and I'd like to but not sure we can. this seems reasonable to not break things on the web too much while giving developers tools to do their jobs
01:58:30 [dveditz]
... popups get in the user's face, less likely that it would be abused.
01:58:44 [dveditz]
... what owuld you like to see in the doc (or anywhere) to make that a reasonable claim to make
01:58:54 [npdoty]
I think the unintentional collaboration point is important; if we think it's likely to create a danger where a site will typically make it easy for network attackers to access, that makes sense
01:58:59 [npdoty]
+1 "attractive nuisance"
01:59:04 [dveditz]
bhill2: sounds like there's not a particular threat model, we're closing down an attractive nuisance
01:59:21 [dveditz]
mkwst: we're closing down a practical way to abuse this we've seen in the wild
02:00:00 [bhill2]
02:00:09 [dveditz]
jyasskin: if someone can find an iframe that can do what they need then they've won, while with a popup they can't
02:00:25 [dveditz]
... but if the popup is invisible then they still win
02:00:53 [dveditz]
mkwst: chrome has put a lot of work into stopping popunders and other invisible popups. We dont think there should be invisible popups
02:01:00 [dveditz]
... and if there are any it's a bug
02:01:37 [dveditz]
... forcing https is less a concern than making sure particular APIs are not available to things that were delivered insecurely
02:02:17 [dveditz]
bhill2: we should touch on this again in the context of COWL tomorrow
02:02:40 [dveditz]
... can we define this as a kind of restriction? keep this in mind for tomorrow
02:03:10 [dveditz]
mkwst: doc has a section on threat modesl and risks. look it through and see if you can make it better
02:03:32 [dveditz]
npdoty: while we're on that note... should we consider other threat models or say explicitly we're not considering one.
02:04:14 [dveditz]
... part of whta we're doing with a network attacker model is that if users are ask for a permission they can be reasonably sure which origin is requesting it.
02:04:26 [cscho]
rrsagent, generate minutes
02:04:26 [RRSAgent]
I have made the request to generate cscho
02:04:47 [dveditz]
... but there hasn't been a lot of adoption of CSP, so it's either the obvious origin or it's someone who found an XSS bug in that origin
02:05:07 [dveditz]
rbarnes: or any 3rd party legitimately included by the origin
02:05:36 [dveditz]
bhill2: if you have a correct application this helps prevent exploitation; if you have an incorrect application well....
02:06:19 [dveditz]
npdoty: discussed this week -- the presence of a CSP that denies inline script is indicator of secure context.
02:06:30 [dveditz]
mkwst: but an attacker can inject that CSP after doing its attack
02:07:04 [dveditz]
npdoty: it might be valuable to include a clause saying there are other kinds of attacks and that this is not a complete silver bullet
02:07:46 [dveditz]
bhill2: we can't make the claim "this app cannot be exploited"
02:08:02 [pauljeong__]
pauljeong__ has joined #webappsec
02:08:06 [dveditz]
... not sure it provides much to make the opposite assertion
02:08:37 [SIN]
SIN has joined #webappsec
02:09:02 [bhill2]
dveditz: if we assume invisible / popunder windows are impossible, should we specify somewhere that this should not happen?
02:09:33 [bhill2]
mkwst: joachim is working on this and I would love for him to better specify this, e.g. how user gestures are tracked and consumed in chrome
02:09:45 [bhill2]
... would be good to document, but practically speaking we haven't had time, there are many and it is difficult
02:09:55 [bhill2]
... send joachim an email and ask
02:10:07 [mkwst]
02:10:20 [bhill2]
dveditz: would that be something that would be in this group or in HTML?
02:10:41 [bhill2]
mkwst: there is some term in html that has a couple of points but is fairly sparsely defined. expanding on it to be useful for this would be some work
02:10:48 [bhill2]
02:11:36 [dveditz]
mkwst: there's a couple more things that I've worked with annevk on, such as what flags to add to fetch and so on
02:11:49 [JeffH]
02:11:59 [dveditz]
... issue number 5: boris seemed to agree (in a long comment) "but you need a lot of tests"
02:12:26 [dveditz]
... we need to figure out how to advance the spec even though it concerns things that are not in the version o HTML defined by the w3c
02:13:12 [dveditz]
... I asked web-apps and they pointed at an HTML 5.1 doc that contains a bunch of things, I'm not convinced that's any more stable and I'd prefer continuing to reference the WHATWG specification.
02:13:30 [wseltzer]
02:14:12 [dveditz]
wseltzer: I should speak up on the normative reference policy -- it is something we'll ahve to address in the w3c generally
02:14:53 [dveditz]
... as more things are produced referencing more outside things. we are not saying everything has to be done in w3c so lets find a way to describe when
02:15:21 [dveditz]
... things developed elsewhere are sufficiently stable and develped sufficiently openly to serve as a reference.
02:15:32 [wseltzer]
02:15:40 [dveditz]
... maybe we can chase down some directors while we're here
02:16:06 [dveditz]
mkwst: there are some things still open at this point but they are details. the general structure and outline seems complete
02:16:36 [dveditz]
... the TAG was happy with it last time they looked, @@ was happy with it. matter of weeks not months to wrap it up
02:17:25 [dveditz]
mkwst: dveditz filed a bug on the relation between mixed content and secure contexts
02:17:40 [virginie]
virginie has joined #webappsec
02:18:00 [bhill2]
TOPIC: Mixed Content
02:18:01 [bhill2]
02:18:07 [dveditz]
... mixed content defines how content can be loaded into a page delivered over TLS
02:18:25 [dveditz]
... secure context defines when content can be loaded into a secure context
02:18:59 [dveditz]
... MIX used to talk about "potential secure origins" -- I've changed it to URLs and authenticated
02:19:55 [dveditz]
... in MIX we can tell by the URL form itself. "unauthenticated" response is something we can tell based ont he actual response (deprecated security, or none)
02:20:36 [dveditz]
... a question to dveditz: have you had a chance to review the changes to the document
02:21:06 [bhill2]
dveditz: have not had a chance to do more than skim what you said but it seems you made the distinction so the terms are no longer confusingly similar
02:21:20 [bhill2]
... I raised this in behalf of others at mozilla, have to make sure this addresses their concerns as well
02:21:41 [bhill2]
mkwst: the reason there is a distinction is that the secure context spec is not only concerned with TLS but also accepts things like file, localhost,, etc.
02:21:43 [dveditz]
mkwst: the reason there's a distinction is that secure context is concerned with not only TLS but things like file:// or loopback
02:22:12 [dveditz]
... and we need to define the behaviors for those that are different from those for mixed content blocking
02:22:33 [dveditz]
... other than that I think the mixed content is done. maybe we have to go back to CR because I changed the definition
02:22:54 [dveditz]
... I don't think they are substantive changes, but mayne someone else will. can we slip this by the director?
02:23:22 [dveditz]
... the other issue is whether we want some kind of error reporting based on mixed content (raised in the session yesterday)
02:24:10 [dveditz]
... now that annevk is here: TBL and others said it would be nice to know when failures were due to mixed content blocking as opposed to other kinds of network errors. what's your opinion on that?
02:24:16 [dveditz]
annevk: is it actually a good idea?
02:24:51 [dveditz]
mkwst: I think it's reasonable to give developers some idea when things are broken because of something they're doing wrong so they can fix it
02:25:35 [dveditz]
annevk: historically we avoid saying much when we block things for security reasons. so mixed content in an iframe -- would we show a different error page?
02:26:16 [dveditz]
mkwst: if it's stuff outside your context then no, but if it's stuff loaded in your own context and it fails it would help to know about it
02:26:25 [dveditz]
mkwst: xhr, fetch, javascript
02:26:43 [dveditz]
annevk: I think we've gotten by without this for a long time
02:27:17 [dveditz]
mkwst: in the recent past we've gotten more strict about mixed content blocking (like xhr). we'd like more people to migrate and giving them better errors might help
02:27:30 [dveditz]
annevk: I'm still not convinced
02:27:57 [dveditz]
mkwst: things that redirect are a problematic case -- you can't just tell by inspecting your own origin
02:28:13 [dveditz]
annevk: if it's just tim I'm still not convinced. it's added complexity.
02:28:38 [dveditz]
bhill2: what does this give us that csp errors don't? are we going to respond right there, or is it for debugging later?
02:28:52 [dveditz]
... if it's debugging then reporting seems good enough
02:29:00 [dveditz]
annevk: does CSP report on this?
02:29:15 [dveditz]
mkwst: if you set up your CSP to block mixed content then yes
02:30:00 [dveditz]
... tim's concern was associated with doing an xhr, having it fail, and wanting to do something else whether it's an offline failure vs mixed content.
02:30:16 [dveditz]
rbarnes: I'm baffled, what would you do differently?
02:30:36 [dveditz]
mkwst: I'm giving you all the information I know about the use case
02:30:39 [rbarnes]
pleased for my bafflement to be immortalized in the minutes
02:30:44 [dveditz]
wseltzer: maybe it's a jog for the TAG
02:30:52 [rbarnes]
02:30:53 [dveditz]
mnot: I have to be somewhere....
02:31:19 [dveditz]
annevk: if it's just the offline thing you can check
02:31:41 [dveditz]
bhill2: we can have a rule, we have to have two independent requests for a feature
02:31:48 [annevk]
02:32:05 [dveditz]
mkwst: if we can show other ways to do it I think that's sufficient
02:32:43 [dveditz]
wseltzer: in all seriousness it could be helpful for the TAG to describe how things could be done securely using new features the director might not know about
02:33:05 [dveditz]
npdoty: if we had better docs on then _any_ developer could find out
02:34:45 [dveditz]
mkwst: brief context Yan broke the internet, you can do timing attacks using CSP and HSTS.
02:35:19 [npdoty]
I hadn't realized the Firefox behavior was intentional, that's good to know
02:35:26 [bhill2]
02:35:26 [annevk]
(FWIW, CORS preflights are cached too)
02:35:32 [dveditz]
rbarnes: new topic "hsts priming", priming the state like cache priming.
02:36:31 [dveditz]
... because browsers learn about HSTS through headers behavior depends on whether a browser had already visited that domain or not
02:37:13 [dveditz]
... proposal: if you have a non-https request that would be blocked by mixed content, but which HSTS would fix, then do a lookup (innocuous) to see if the site has HSTS.
02:37:33 [dveditz]
... either the site doesn't and the request gets blocked anyway, or it does and you can safely upgrade it
02:38:47 [dveditz]
yoav: is the mixed content request going out, or blocking the response coming back in?
02:39:03 [dveditz]
... if it's images you still send the insecure request and then degrade the state
02:39:41 [annevk]
mkwst: how does mixed content deal with redirects? Is an <img> fetched as http: that redirects to https: still mixed content?
02:39:55 [mkwst]
annevk: Yes.
02:40:25 [mkwst]
annevk: Because the redirect is non-confidential, and can't guarantee integrity.
02:40:32 [annevk]
mkwst: and https: to http: still renders?
02:41:34 [mkwst]
annevk: images render. they simply flag the page as being insecure.
02:41:47 [mkwst]
annevk: in both cases you describe, the result would be mixed content.
02:42:08 [dveditz]
rbarnes: you can cache "no HSTS" for a shorter time, such as the lifetime of the document
02:42:42 [dveditz]
... we do need to change the order of fetch because mixed content blocking happens before the HSTS upgrade happens
02:43:30 [dveditz]
mkwst: is this worth doing? what I heard from you was that this affects 1% of all potentially blocked mixed content in Firefox.
02:43:45 [dveditz]
... at what level is it worth doing the work
02:44:07 [SIN]
SIN has joined #webappsec
02:44:13 [dveditz]
mnot: not sure that's the right metric. if this helps people switch to https then it's a good thing
02:44:59 [npdoty]
I think mnot is saying that it could be a larger percentage, when you consider sites that haven't upgraded to https *because* they saw mixed content failures, but would
02:45:54 [dveditz]
rbarnes: the stuff that would be fixed is 0.02% of request, so it's small, but for future sites converting this would help
02:46:29 [bhill2]
dveditz: there are two issues: changing the order of rewriting/blocking would help a lot of people
02:46:44 [bhill2]
mkwst: but we need to do this priming to be able to do this or we have non-deterministic behavior
02:47:00 [dveditz]
mkwst: we need to do priming before switching order to remove indeterminism.
02:47:10 [bhill2]
... and developers will have visited all of the sites they depend on so things will appear to work, but will be broken for users on first visit
02:47:24 [dveditz]
... devs will have visited all the sites, so the page will work for them. users will have a broken site because they will have blocked content
02:48:03 [dveditz]
bhill2: where would this live, a modification to fetch?
02:48:21 [dveditz]
annevk: we could do it that way. we have a secrion on preflights, we could have a section on this
02:49:13 [dveditz]
JeffH: I would expect the priming to be added to the IETF rfc XXXX because if you do this that spec is no longer stand-alone
02:50:24 [bblfish]
bblfish has joined #webappsec
02:50:30 [dveditz]
mkwst: as far as I know no browser implements 12.4 "Disallow Mixed Security Context Loads" in the hsts spec
02:51:35 [dveditz]
... fetch spec doesn't define how pinning is going to work
02:51:57 [dveditz]
rbarnes: the hsts spec defines how you get the hsts information, store it, and use it
02:53:34 [dveditz]
annevk: what mkwst means is that there is an upgrade step but there's nothing in fetch that says "handle the response to see if there's hsts"
02:53:53 [dveditz]
yoav: would be nice if priming could be async
02:54:03 [dveditz]
annevk/rbarnes: you have to block the request
02:54:18 [dveditz]
yoav: I want to be able to send these priming requests ahead of time
02:54:28 [dveditz]
mkwst: part of the preload phase
02:55:09 [dveditz]
JeffH: I should chat with you guys. I'm still concerned
02:55:32 [dveditz]
annevk: not mentioned here, but in the html spec there's a bit about the websocket requests and hsts
02:55:54 [dveditz]
JeffH: we have folklore locked up in our brain. we need to document this because we're not all here forever
02:55:57 [wseltzer]
s/concerned/concerned about references that should appear in IETF HSTS/
02:56:08 [bhill2]
02:56:10 [dveditz]
... a lot of times there are missing linkages
02:57:12 [wseltzer]
rrsagent, please stay
02:57:21 [dveditz]
bhill2: adjourning for lunch, resuming at 1:15
03:08:00 [barryleiba]
barryleiba has joined #webappsec
03:31:42 [virginie]
virginie has left #webappsec
03:53:59 [yoav]
yoav has joined #webappsec
03:54:17 [barryleiba]
barryleiba has joined #webappsec
03:55:31 [rbarnes]
rbarnes has joined #webappsec
03:56:25 [barryleiba]
rrsagent, make minutes
03:56:25 [RRSAgent]
I have made the request to generate barryleiba
04:06:50 [kiyoung]
kiyoung has joined #webappsec
04:06:51 [jyasskin]
jyasskin has joined #webappsec
04:10:16 [keiji]
keiji has joined #webappsec
04:13:23 [ccho4]
ccho4 has joined #webappsec
04:18:24 [rbarnes]
rbarnes has joined #webappsec
04:19:02 [npdoty]
npdoty has joined #webappsec
04:19:58 [ccho4]
ccho4 has joined #webappsec
04:20:19 [bhill2]
scribenick: bhill2
04:20:40 [Melinda]
Melinda has joined #webappsec
04:20:44 [bhill2]
04:20:59 [bhill2]
... some potentially interesting questions, if anyone is interested, here to answer questions
04:21:38 [hax]
hax has joined #webappsec
04:21:40 [bhill2]
francois: is access to bt restricted to secure origins?
04:21:43 [bhill2]
jyasskin: yes
04:21:49 [bhill2]
dveditz: does this also apply to USB
04:22:03 [bhill2]
jyasskin: these are similar apis, a bit different based on how devices are attached
04:22:05 [ivan_]
ivan_ has joined #webappsec
04:22:07 [SIN]
SIN has joined #webappsec
04:22:39 [bhill2]
... for nfc and usb, new protocols proposed that expose origin to remote device but block all existing devices, but bluetooth accepts as-is
04:23:02 [sangrae]
sangrae has joined #webappsec
04:23:06 [bhill2]
... bluetooth also has a blacklist of dangerous services, which is currently keyboards and mice and FIDO devices
04:23:11 [bhill2]
mkwst: based on what?
04:23:20 [bhill2]
jyasskin: based on the id of the service
04:24:23 [bhill2]
... no service worker access yet, can only talk when an active tab, for nfc is "frontmost" tab, which is not well defined in html spec yet
04:24:25 [hax]
hax has joined #webappsec
04:24:50 [bhill2]
rbarnes: general concern here is overlap between this and other apis for granting access to hardware, e.g. getUserMedia and geolocation
04:25:15 [bhill2]
jyasskin: only doing GATT subset for now, cameras and most audio doesn't work over this yet
04:25:51 [bhill2]
... is likely that people will start doing audio over GATT, just not yet. Geolocation is totally a thing. We want that to be easier user experience than general bluetooth chooser.
04:26:23 [bhill2]
... hopefully users interpret "pair" to mean "give full control of", so the user will be aware of e.g. location functionality in a device being implicitly granted
04:27:02 [bhill2]
... how do we get the list of ids/services in the registry, but there is an incentive to lie about devices not listed by their authoritative creator
04:27:29 [npdoty]
npdoty has joined #webappsec
04:27:54 [bhill2]
... this is by device class but for non-standard services is more per-device; most device makers invent their own id, but anyone can use them
04:27:54 [npdoty]
yeah, it might be nice if we could detect when a bluetooth permission were actually a capability that matched another permission, like geolocation
04:28:12 [ygkim]
ygkim has joined #webappsec
04:28:17 [bhill2]
04:28:46 [dveditz]
bhill2: can bluetooth do things like usb where you plugin in a device and later it changes what it can do?
04:28:51 [dveditz]
jyasskin: yes, they can
04:29:05 [npdoty]
so that our privacy model is based on capabilities, rather than particular mechanisms
04:29:22 [bhill2]
jyasskin: have to trust that device doesn't change the services it exposes or claimed device class after attaching
04:29:32 [bhill2]
... treating that as OS level bugs that the web platform can't do anything about
04:30:19 [bhill2]
... two ways to trigger prompt: user gesture to show for nearby devices
04:30:53 [kura_]
kura_ has joined #webappsec
04:31:10 [bhill2]
... 2nd way is related to physical web effort; a thing can broadcast a URL and any nearby browser can see that
04:31:27 [bhill2]
so could a malicious device advertise itself, connect, then change itself to a keyboard?
04:31:33 [bhill2]
jyasskin: going to file a bug about that
04:31:51 [bhill2]
dveditz: can a web page learn what devices you have without user knowing?
04:32:09 [bhill2]
jyasskin: no, only those you've paired, can't differentiate between not there and not allowed
04:32:24 [bhill2]
... pretty sure model is same for nfc / usb
04:32:53 [bhill2]
... some push for telling document what state the permission prompt was in when cancelled - either empty or denied
04:33:02 [bhill2]
... is there a preference in this group to not do that?
04:33:41 [npdoty]
what's the site use case that wants it?
04:33:51 [bhill2]
dveditz: I would lean that way unless there's a good reason to do otherwise; it's just fingerprinting info without a compelling use case
04:34:21 [bhill2]
jyasskin: come up from dev rel person, but no compelling use case yet. would be nice to respond to failures, but user has seen dialog so they know what they did
04:35:00 [colin]
colin has joined #webappsec
04:35:08 [bhill2]
dveditz: could offer to "order one if you don't have one yet" if no devices present
04:35:28 [mnot]
mnot has joined #webappsec
04:35:36 [bhill2]
annevk: how problematic is it for device to not know origin
04:35:50 [bhill2]
jyasskin: very for some devices, e.g. FIDO, which is why it's blacklisted
04:36:04 [bhill2]
... most other devices are not concerned about restricting to particular sources
04:36:08 [pauljeong]
pauljeong has joined #webappsec
04:36:16 [hwlee]
hwlee has joined #webappsec
04:36:25 [wonsuk]
wonsuk has joined #webappsec
04:36:28 [cha_myung_hoon]
cha_myung_hoon has joined #webappsec
04:36:37 [bhill2]
... bluetooth group doesn't understand the concern / use case, but any way to do this would be a new service
04:37:44 [bhill2]
dveditz: can same device be paired with multiple origins at the same time?
04:37:46 [bhill2]
jyasskin: yes
04:37:55 [bhill2]
... blacklist is standardized across all browsers
04:38:20 [bhill2]
TOPIC: Credential Management Level 1
04:38:23 [rbarnes]
i confess that this bluetooth thing doesn't seem like a great security trade-off to me
04:39:24 [kodonog]
kodonog has joined #webappsec
04:39:35 [dveditz]
04:39:50 [bhill2]
mkwst: API is getting stable and we have feedback from credentials CG that it is generic enough to accommodate extensions for their use cases
04:40:10 [bhill2]
... I am sure there will be detailed questions that come up with more implementations
04:40:34 [bhill2]
... feedback is generally positive and developers like interacting with the password manager in an imperative fashion
04:40:46 [bhill2]
... not happy with but can live with async form submisssion
04:41:10 [bhill2]
... less happy with necessity to do multipart form submission, but that's a consequence of how fetch handles opaque formdata
04:41:38 [bhill2]
... if login systems are legacy may be hard to teach it to do multipart form submission when it only understands urlencoded form submission
04:41:54 [bhill2]
... may be able to get around by transforming to url search params
04:42:06 [bhill2]
... but chrome doesn't implement that yet, curious if there is a better mechanism
04:42:25 [bhill2]
annevk: there are other good reasons to implement that API
04:42:45 [bhill2]
mkwst: then that would be another method hanging off the credential object, have to know that they have different behaviors
04:42:56 [bhill2]
... don't want to go back to first principles and re-evaluate, but we have to do something
04:43:10 [bhill2]
annevk: it's hard to serialize form data in other formats since it contains blobs
04:43:22 [bhill2]
mkwst: if right thing is to implement the primitive that already exists
04:43:34 [bhill2]
annevk: just firefox implements url search params at this point
04:43:52 [bhill2]
mkwst: means we need to define an opaque variant of url search params
04:44:20 [bhill2]
... if a goal is layering on top of existing login systems, probably makes sense to do this and document why to pick one or the other
04:44:27 [bhill2]
... probably need to do this and file a bug for it
04:45:01 [bhill2]
mkwst: working about how we allow users to choose to always be logged in
04:45:16 [bhill2]
... experimenting but haven't landed any ui that we're totally happy with yet
04:45:25 [bhill2]
... api is done and you can play with it behind a flag
04:45:39 [bhill2]
... some outstanding questions around metadata associated with the credential, e.g. icon
04:45:57 [bhill2]
... currently a URL, anne suggested might be better as a image bitmap or blob
04:46:04 [bhill2]
... maybe a good idea, doesn't give us responsive images
04:46:34 [bhill2]
... at this point we need: more implementer feedback, more developer feedback
04:47:18 [bhill2]
annevk: what about issue 2:
04:47:31 [SIN_]
SIN_ has joined #webappsec
04:47:41 [bhill2]
mkwst: this (autocomplete) makes sense for registration cases, e.g adding address info
04:48:06 [bhill2]
... not sure it's right thing for autologin
04:48:17 [bhill2]
... autocomplete solves some things, but takes away some other good things.
04:48:37 [bhill2]
... model in current spec prevents JS from accessing the password, this makes it impossible to deny that
04:48:46 [bhill2]
annevk: can we upgrade input type=password?
04:48:56 [bhill2]
mkwst: that breaks other things
04:49:00 [colin__]
colin__ has joined #webappsec
04:49:08 [bhill2]
annevk: can we have an opt-in upgrade to a hardened model?
04:49:27 [bhill2]
mkwst: proposed a write-only attribute on form fields a while back, was no interest expressed at the time
04:49:51 [bhill2]
... if there _is_ interest, idea is to add an attribute that denies read access
04:50:04 [bhill2]
annevk: if we don't care about protecting password fields in general, doesn't make sense to do this
04:50:37 [bhill2]
... seems it would protect against other scenarios
04:51:00 [bblfish]
bblfish has joined #webappsec
04:51:04 [bhill2]
dveditz: how does making form fields opaque if xss can change the target of the form
04:51:24 [bhill2]
mkwst: wanted this to be origin-locked to prevent that, but now that we are doing fetch integration, we have to rely on developer to do the right thing
04:51:28 [bhill2]
... we could add that
04:51:32 [colin]
colin has joined #webappsec
04:51:53 [bhill2]
... seems like a layering violation for fetch to know about this spec, but maybe opaque formdata objects always must submit same-origin
04:52:35 [bhill2]
... opaque fields draft tried to taint data so that mutating form field type didn't allow an attack
04:52:58 [bhill2]
annevk: but attacker could still inject a new, non-opaque field and convince user to type into that instead
04:53:19 [bhill2]
mkwst: request autocomplete only deals with one side; allows you to get credentials out but not to store them
04:53:35 [bhill2]
dveditz: assume we would restrict autocomplete to opaque fields...
04:53:52 [bhill2]
mkwst: not clear it's valuable to go this route if only solves helps the problem
04:54:05 [bhill2]
... if we need imperative storage, why would we use a completely different api to get that data back
04:54:31 [bhill2]
... reason storage is important because password managers in browsers are huge piles of terrible heuristics to judge password fields and success
04:54:42 [bhill2]
... miss things like XHR based logins or federations based on redirects
04:55:06 [bhill2]
... imperative mechanism allows site to request help from the browser; this is the core of the value proposal from chrome password manager
04:55:42 [bhill2]
jeffh: higher level, extensible API also can be used in a more smooth and abstract fashion for plugging in stronger authentication
04:55:52 [yoav]
04:55:55 [bhill2]
mkwst: yes, hoping that things like FIDO will use this
04:56:22 [bhill2]
rbarnes: has any discussion been had about this with the fido folks?
04:57:07 [bhill2]
jeffh: we are aware of this doc
04:57:10 [bhill2]
ack yoav
04:57:41 [bhill2]
yoav: to support the importance of storing the credentials, have heard of use case where a site is interested in managing login for users where user doesn't know password
04:58:00 [JeffH]
JeffH has joined #webappsec
04:58:06 [bhill2]
... interested in sending them a link, storing some random password on the user's device and have the login work that way
04:58:29 [bhill2]
mkwst: I think storage (and sync) is a critical feature
04:58:52 [bhill2]
... most password managers have a mechanism to just create a random password
04:59:05 [bhill2]
... there is a bug, deferred, for this, we could re-open and put it in
04:59:17 [bhill2]
... but request autocomplete is probably a more reasonable way to do htis
04:59:22 [bhill2]
04:59:40 [bhill2]
... as you are probably trying to grab more than just a credential, and and do this all in one request
05:00:05 [bhill2]
mkwst: a question is whether to care about password complexity rules at the remote endpoint
05:00:29 [bhill2]
... if we need to support that, we need to specify how to define those restrictions, which I don't want to do
05:00:50 [bhill2]
yoav: how can you make sure that password made it into the manager?
05:01:02 [bhill2]
... does user have to agree?
05:01:27 [bhill2]
mkwst: yes, of course user has to agree, this is significantly more persistent than a cookie, synced across devices, not cleared
05:02:25 [bhill2]
... but user prompting is not in this spec because user agents should do what is right for their users
05:03:09 [bhill2]
... what we need are implementations by browsers and developers, and developers are more important
05:03:13 [kimwooglae]
kimwooglae has joined #webappsec
05:03:26 [bhill2]
... talked to some developers who are planning on using it once it ships
05:04:36 [bhill2]
rbarnes: no current plans to do a focused implementation effort but this is broadly a direction we are comfortable with, will send some questions re: federation cases
05:05:00 [timeless]
RRSAgent, draft minutes
05:05:00 [RRSAgent]
I have made the request to generate timeless
05:05:00 [bhill2]
jeffh: we should make federated identity folks aware of this
05:05:46 [bhill2]
mkwst: no feedback from microsoft or apple, opera is interested
05:05:52 [timeless]
s|agenda link:||
05:06:15 [timeless]
s/BREAK TIME till 1030h local time/[ BREAK TIME till 1030h local time ]
05:06:48 [timeless]
i|popunder windows are impossible|scribe: bhill2
05:07:48 [timeless]
RRSAgent, draft minutes
05:07:48 [RRSAgent]
I have made the request to generate timeless
05:08:25 [bhill2]
axel: followed removal of send(), not sure if I like the fetch integration, but easier to implement
05:08:31 [timeless]
i|worked with annevk on|scribe: dveditz
05:08:48 [bhill2]
... not really that complicated, much of what's needed is already there in firefox
05:09:09 [bhill2]
... discussion about doing some strange crypto stuff to password before sending it, where did this end?
05:09:12 [keiji]
05:09:31 [bhill2]
mkwst: currently we don't do this and don't support the use case.. don't know anyone for whom this is essential
05:09:49 [timeless]
RRSAgent, draft minutes
05:09:49 [RRSAgent]
I have made the request to generate timeless
05:10:00 [bhill2]
rbarnes: if you're going to do some processing like this you're changing from an opaque object to a thing with JS that executes in a secret context that can access the data
05:10:36 [bhill2]
... need to swap that paradigm, might make sense to change entirely
05:10:43 [bhill2]
rrsagent, set minutes world
05:10:43 [RRSAgent]
I'm logging. I don't understand 'set minutes world', bhill2. Try /msg RRSAgent help
05:10:54 [bhill2]
rrsagent, set minutes public-visible
05:10:54 [RRSAgent]
I'm logging. I don't understand 'set minutes public-visible', bhill2. Try /msg RRSAgent help
05:12:28 [bhill2]
axel: could install something trusted that can operate on the token and transform it, would fit with how tokenization in payments world works
05:12:46 [bhill2]
rrsagent, set minutes world-visible
05:12:46 [RRSAgent]
I'm logging. I don't understand 'set minutes world-visible', bhill2. Try /msg RRSAgent help
05:13:02 [timeless]
RRSAgent, make logs world
05:13:12 [timeless]
RRSAgent, draft minutes
05:13:12 [RRSAgent]
I have made the request to generate timeless
05:13:54 [JeffH]
url search params = ?
05:14:34 [bhill2]
mkwst: think the spec is already too big, and without a concrete use case that maps to one of the things the spec is trying to do
05:14:57 [bhill2]
... will be hard to find time to implement if it's not something chrome's password manager would do, so prefer not to put it in spec
05:14:59 [bhill2]
05:15:01 [rbarnes]
05:15:01 [bhill2]
ack keiji
05:15:15 [mkwst]
05:15:29 [bhill2]
keiji; is there any possibility to have public security review as a process, since this kind of feature is very attractive for attackers, xss is common
05:15:38 [bhill2]
05:16:00 [bhill2]
mkwst: would love for you to read through mitigations in the spec and see if they make sense
05:16:03 [JeffH]
mkwst: ths
05:16:05 [JeffH]
05:16:09 [bhill2]
... this should be strictly more secure than status quo
05:16:21 [bhill2]
... today password manager will just fill a form for you and you can read the data out
05:16:24 [bhill2]
... this is better than that
05:16:32 [Melinda]
Melinda has joined #webappsec
05:16:35 [timeless]
s/mkwst: ths//
05:16:38 [timeless]
05:16:58 [Hax]
Hax has joined #webappsec
05:17:01 [bhill2]
mkwst: have taken this to the TAG for review. they were supportive of the general direction and api shape
05:17:07 [bhill2]
ack rbarnes
05:17:29 [bhill2]
rbarnes: separation between origin and non-origin bound credentials?
05:17:35 [bhill2]
mkwst: you need to talk to credentials CG
05:18:03 [bhill2]
... I am skeptical about use cases but have made room for the non-skeptics' use cases if they can produce them
05:18:20 [bhill2]
... some sites will have both user/password or federated login
05:18:33 [bhill2]
... don't know how it will work to do that and other types in the future
05:18:58 [bhill2]
... what it does now is walk up the chain to find common ancestor below base "credential"
05:19:09 [bhill2]
... would like to get rid of that, not sure that I can
05:19:14 [bhill2]
rbarnes: seems like a sensible thing to do
05:19:28 [bhill2]
... one thing that was good about webcrypto is it didn't design any new cross-origin stuff
05:19:38 [bhill2]
... origin binding is a good design principle in general
05:19:42 [bhill2]
mkwst: agreed
05:21:36 [bhill2]
mkwst: chrome implementation doesn't have it and doesn't suffer for it
05:22:05 [bhill2]
rbarnes: in a level 2 would be easy to collapse the two types if non-origin bound uses never emerge
05:22:41 [bhill2]
mkwst: origin bound might be a terrible name, could maybe "password manager type"
05:22:50 [bhill2]
... picked origin bound as a not so subtle hint about what I wanted to build
05:23:25 [bhill2]
... only place it has any impact is if different kinds of credentials are picked, do something sane, could hardcode that instead
05:23:52 [bhill2]
... tradeoff between extension points with well-defined behavior vs. a more streamlined spec
05:24:04 [bhill2]
... not entirely happy but does what I want it to do, would rather not reopen the discussion
05:24:12 [timeless]
05:24:26 [bhill2]
... things I find ugly have no practical impact so don't care enough to remove them
05:25:03 [cha_myung_hoon]
cha_myung_hoon has left #webappsec
05:25:20 [timeless]
s||-">|-> Brad's WebAppSec TPAC2015 update slides
05:25:45 [bhill2]
TOPIC: Subresource Integrity Level 2 feature proposals
05:25:54 [timeless]
s|link to preso?||
05:26:08 [bhill2]
francios: first class of ideas is support for different types of resources beyond script / style
05:26:25 [bhill2]
... second class is applying it to downloads
05:26:32 [francois]
05:27:19 [bhill2]
mkwst: boris had some issues with the order of applying transfer-encoding
05:27:23 [rbarnes]
rbarnes has joined #webappsec
05:27:29 [bhill2]
yoav: only know after file is downloaded
05:27:42 [bhill2]
francois: we already have the same thing with safe browsing
05:29:58 [bhill2]
bhill2: in safe browsing the protection applies regardless of source of link, if this protection is only based on link metadata, user can just paste url into address bar and then there is no protection
05:30:17 [bhill2]
francois: there are always overrides even for safe browsing, if user is determined, can use another browser that doesn't implement
05:31:14 [bhill2]
bhill2: so maybe is about security considerations suggesting clear warning to users about why download was blocked
05:31:35 [bhill2]
annevk: what about encoding it into the link?
05:32:00 [bhill2]
dveditz: we tried a long time ago and folks didn't like the idea of messing with urls that way, but yes, you lose the integrity data when copy/pasted
05:32:43 [bhill2]
timeless: is there a scheme that just has integrity only?
05:34:17 [bhill2]
bhill2: there is this, but we decided against using it:
05:34:33 [annevk]
bhill2: so I think that RFC doesn't allow you to embed the address
05:34:54 [annevk]
bhill2: the authority field doesn't really tell you where to find it over HTTP
05:35:13 [bhill2]
annevk: there is the well-known syntax
05:35:36 [annevk]
bhill2: but that's a mapping to HTTP, that doesn't work for legacy download locations?
05:35:41 [bhill2]
francois: another type that has been discussed is images
05:35:47 [bhill2]
annevk: yes, that's a big limitation
05:35:52 [annevk]
05:35:58 [bhill2]
05:36:55 [bhill2]
francois: progressive rendering makes image integrity possibly unatttractive
05:37:08 [bhill2]
... also lots of ways to express "images"
05:37:09 [timeless]
s/on Broad Themes slide #3/[ Slide: 3 - Broad Themes ]
05:37:18 [bhill2]
... progressive rendering might be a showstopper for many people
05:37:27 [bhill2]
yoav: what about video/audio?
05:37:42 [timeless]
s/S #6 subresource integrity SRI/[ Slide: 6 - Subresource Integrity (SRI) ]
05:38:21 [timeless]
s/s 7: Referrer Policy -- fpwd/[ Slide: 7 - Referrer Policy ]
05:38:21 [bhill2]
annevk: you could use fetch api to get bytes for checking in a streaming-compatible manner
05:38:28 [francois]
05:38:43 [timeless]
s/s 9: upgrade insecure requests/[ Slide: 9 - Upgrade Insecure Requests ]
05:38:54 [bhill2]
francois: another type is CSS-loaded subresources, if stylesheet loads things, they are not protected
05:39:06 [timeless]
s/s 10: UI Security/[ Slide: 10 - User Interface Security ]
05:39:25 [timeless]
s/s 11: Cred mgmt/[ Slide: 11 - Credential Management Level 1 ]
05:39:39 [timeless]
05:39:42 [timeless]
05:39:42 [bhill2]
annevk: tab made it so arguments can be reused in CSS in a backward compatible manner, but no usages of that are defined
05:39:51 [timeless]
s/see above//
05:40:16 [bhill2]
mkwst: tab is here, we can hammer that out with him before everyone flies home
05:40:19 [mnot]
mnot has joined #webappsec
05:40:19 [timeless]
s||-">|-> Implementation Report for Content Security Policy Level 2
05:40:46 [timeless]
s/have an impl rpt for CSP2/We have an implementation report for CSP level 2/
05:41:17 [bhill2]
francois: one thing in v1 removed was iframes. a problem anne pointed out is that iframes can be navigated, need to define what that means if an integrity protected iframe is navigated somewhere else
05:41:19 [timeless]
05:41:30 [bhill2]
annevk: maybe navigation should be disabled in such a case
05:41:55 [timeless]
RRSAgent, draft minutes
05:41:55 [RRSAgent]
I have made the request to generate timeless
05:42:36 [bhill2]
mkwst: use case I was thinking of was advertising where 3rd parties are responsible for serving something, want to verify that document for which you have a hash should also have integrity information
05:42:54 [bhill2]
annevk: we don't do that for css
05:43:09 [francois]
05:43:16 [timeless]
s/Brad's WebAppSec TPAC2015 update slides (world-readable link, per bhill)/"Brad's WebAppSec TPAC2015 update slides" (world-readable link, per bhill)
05:43:36 [timeless]
s||-">|-> Brad's WebAppSec TPAC2015 update slides
05:44:12 [timeless]
s/-> -> https:/--> https:/
05:44:32 [bhill2]
mkwst: was thought of requiring integrity on all elements of a type in a document, but dropped, and wasn't yet a way to for that on embedded content
05:44:52 [timeless]
s|--> https:/|--> https:|
05:44:56 [timeless]
s||-">|-> Brad's WebAppSec TPAC2015 update slides
05:45:06 [timeless]
s|--> https:|-> https:/|
05:45:07 [francois]
05:45:11 [timeless]
RRSAgent, draft minutes
05:45:11 [RRSAgent]
I have made the request to generate timeless
05:45:38 [bhill2]
francois: next is CSP directive to require integrity
05:45:45 [timeless]
s/Brad's WebAppSec TPAC2015 update slides "Brad's WebAppSec TPAC2015 update slides"/"Brad's WebAppSec TPAC2015 update slides"/
05:45:48 [timeless]
RRSAgent, draft minutes
05:45:48 [RRSAgent]
I have made the request to generate timeless
05:47:11 [bhill2]
... proposal is to use CSP to attach to a directive to require integrity for all resources that directive applies to
05:47:27 [bhill2]
annevk: an injection could still add integrity, need to be in the header
05:48:05 [francois]
05:48:27 [bhill2]
bhill2: could work in concert with a signature-based approach that included a public key in the header to avoid bloating the policy
05:48:37 [bhill2]
francois: which is this issue....
05:48:52 [timeless]
05:50:08 [timeless]
05:53:26 [bhill2]
bhill2: there are two forms of this proposal: annotate each element with signatures (assumes page knows content in advance) vs. give a key and get a signature from the server in a header (allows dynamic content)
05:54:21 [bhill2]
bhill2: is concerned about what substantial advantage dynamically signed content from a server provides over existing https semantics
05:54:42 [bhill2]
mkwst, dveditz: could be signed offline, but client can't tell what it's doing
05:55:00 [kimwooglae]
kimwooglae has joined #webappsec
05:55:05 [wonsuk]
wonsuk has joined #webappsec
05:55:25 [bhill2]
s/mkwst, dveditz:/mkwst:/
05:55:33 [bhill2]
dveditz: +1
05:56:18 [mnot]
05:57:03 [bhill2]
bhill2: one case that has come up with in CSP is DNS, locale-specific names (e.g. which server-supplied signatures could help with
05:57:04 [francois]
05:58:23 [bhill2]
mnot: are you OK with inserting content originally delivered over http into a secure context from a sharedcache?
05:58:38 [bhill2]
dveditz: I like this idea
05:58:50 [bhill2]
mkwst: not clear what this gives you- doesn't solve leakage problems
05:59:12 [bhill2]
... no server side
05:59:49 [bhill2]
mnot: you can probe with this
06:00:02 [bhill2]
mkwst: and all our protections are origin-based, and you can pretend that a resource is coming from any origin
06:00:15 [bhill2]
... how do we know if a script is cross-origin, if I should have access to data?
06:00:26 [bhill2]
annevk: is this any worse than existing http cache issues?
06:00:47 [bhill2]
mkwst: if you are caching content and it is indexed by a hash, what is the origin and how do you know if you should have access or if it should be blocked by csp?
06:01:37 [bhill2]
q+ jyasskin
06:02:40 [bhill2]
mnot: do you adopt headers of other representation?
06:02:48 [bhill2]
dveditz: script mostly doesn't care
06:02:59 [bhill2]
bhill2: worker might be delivered with CSP policy
06:03:15 [bhill2]
mkwst: might be useful go back to concerns documented in original spec
06:03:42 [bhill2]
dveditz: if we expand to iframe, headers become much more of an issue
06:04:09 [bhill2]
mkwst: can go back in time on spec to security considerations before the features were removed, and also on mailing list
06:04:12 [bhill2]
ack jyasskin
06:05:15 [francois]
06:05:20 [francois]
is the sha3 bug
06:06:02 [timeless]
RRSAgent, draft minutes
06:06:02 [RRSAgent]
I have made the request to generate timeless
06:10:57 [kura_]
kura_ has joined #webappsec
06:19:03 [yoav]
yoav has joined #webappsec
06:22:42 [mnot]
mnot has joined #webappsec
06:33:32 [keiji]
keiji has joined #webappsec
06:43:05 [yoav]
yoav has joined #webappsec
06:46:46 [Kepeng]
Kepeng has joined #webappsec
06:47:22 [kura_]
kura_ has joined #webappsec
06:48:19 [dveditz]
TOPIC: CSP level 3
06:48:35 [dveditz]
mkwst: csp2 is basically done
06:48:57 [dveditz]
... a couple things left to land in firefox, brad has a great testsuite ... on track
06:49:16 [JeffH]
CSP lvl 3 link?
06:49:28 [dveditz]
... CSP 3 is a complete rewrite of CSP2 in terms of HTML and fetch. csp2 was a little handwavy about how things worked, I hope csp3 is clearer
06:49:57 [dveditz]
... spec section 4 Integrations: describes how fetch integrates into csp
06:50:07 [JeffH]
06:50:23 [dveditz]
... csp2 written in terms of requests -- pre service workers. csp3 written in terms of fetch to cope with service workers
06:50:38 [mnot]
mnot has joined #webappsec
06:50:50 [dveditz]
... requests go out, through CSP. service workers can muck with it, and then the response comes back through CSP
06:50:54 [bblfish]
bblfish has joined #webappsec
06:50:58 [dveditz]
... service worker can have its own CSP
06:51:10 [dveditz]
... in the future service workers can ctalk to service workers
06:51:25 [rbarnes]
rbarnes has joined #webappsec
06:51:46 [dveditz]
... Integration with fetch also does the policy parsing and puts the policy on a response object
06:51:58 [dveditz]
... this was vague in csp 2, I hope it's better explained now
06:52:22 [dveditz]
... (response has a csp list, we parse the policy, we do something useful with it)
06:52:45 [dveditz]
... 2 hooks: should request be allowed, should response be allowed (top and bottom of fetch respectively)
06:53:04 [dveditz]
... Integration with html -- all the places we have to touch to make CSP sensible.
06:53:25 [dveditz]
... such as inline scripts. I've given annevk patches for some of these, some are still outstanding
06:53:38 [dveditz]
... I hope this all makes the mechanics of csp significantly more clear than they were
06:54:00 [dveditz]
... would be great for folks interested in the details to read this through and tell me if it makes sense or not
06:54:45 [dveditz]
... number of policies that affect the document that have nothing to do with fetch (e.g baseURI) and those are described in here too
06:55:02 [dveditz]
... It's nowhere near done, but done enough to start getting feedback
06:55:08 [dveditz]
scribenick: dveditz
06:55:45 [timeless]
RRSAgent, draft minutes
06:55:45 [RRSAgent]
I have made the request to generate timeless
06:55:49 [dveditz]
... Current state is "parity with CSP 2". Two new behaviors in here, but basically nothing different just making things that were implicit explicit
06:56:15 [timeless]
i/mkwst: csp2 is basically done/scribe: dveditz
06:56:20 [dveditz]
... one change: no longer possible to lock yourself into an insecure scheme. "http:" means "http" and "https".
06:56:26 [timeless]
s/scribenick: dveditz//
06:56:34 [dveditz]
... and 'self' includes websockets (ws/wss)
06:56:51 [timeless]
RRSAgent, draft minutes
06:56:51 [RRSAgent]
I have made the request to generate timeless
06:57:26 [dveditz]
... the frame-src directive, deprecated in CSP 2, has been removed. I'm not sure that's a good idea
06:57:31 [timeless]
s||-">|-> Content Security Policy Level 3
06:57:58 [dveditz]
... One of the big changes is I'd like to throw away all the report functionality here. Seemed like a great idea, assuming violations didn't happen often
06:58:09 [dveditz]
... but that was insanely optimistic
06:58:21 [schuki]
06:58:28 [timeless]
RRSAgent, draft minutes
06:58:28 [RRSAgent]
I have made the request to generate timeless
06:58:47 [dveditz]
... we'd like to have a single place where reporting is defined for all kinds of things (CSP, backoff, cert pinning)
06:59:00 [dveditz]
... "Not Just Error Reporting" -- will have a new name eventually
06:59:20 [dveditz]
07:00:18 [dveditz]
... this should simplify CSP, just define the contents of the report and let this new spec define the mechanism
07:00:59 [timeless]
s||-">|-> ED: Clear Site Data
07:01:10 [dveditz]
... so I'd like to remove report-uri. Folks at Google have some things they'd like to see in reports so I'd like to revisit these
07:01:39 [dveditz]
... most of the things we strip from reports are actually obtainable from javascript, so people are using alternative reporting. that's showing brokenness
07:01:44 [timeless]
i|error-reporting/|-> "Not Just Error Reporting" -- will have a new name eventually
07:01:50 [dveditz]
... other than that the doc is essentially CSP2
07:02:00 [dveditz]
... some of the new things we want to do are in _new_ documents
07:02:12 [dveditz]
... For example, cookie scoping, something mnot wanted
07:02:19 [timeless]
s||-">|-> Secure Contexts
07:02:47 [dveditz]
07:03:35 [dveditz]
... I think it makes sense to define new things in new documents, a single feature set that can be defined and reasoned about and adopted stand-alone
07:03:42 [timeless]
s||-> ED: Credential Management Level 1
07:04:00 [dveditz]
... I'd like to experiment with drafting all new features this way. maybe some will move back into the monolithic doc
07:04:41 [dveditz]
... you'll see in the CSP3 TOC i've divided the features into "fetch directives", "grabbag", and reporting directives
07:04:59 [timeless]
07:05:52 [timeless]
RRSAgent, draft minutes
07:05:52 [RRSAgent]
I have made the request to generate timeless
07:06:05 [JeffH]
what was that other csp spec wrt cookie that we perused ?
07:06:25 [dveditz]
07:06:44 [timeless]
s||-">|-> "SRI: needs integration with whatwg/html" issue-486
07:06:46 [dveditz]
... not clear any of the grabbag justify a separate document, but I'd like to think about it
07:07:11 [dveditz]
... I think making the spec more modular will [improve eveyone's lives]
07:07:53 [npdoty]
npdoty has joined #webappsec
07:08:03 [dveditz]
... if we can make smaller chunks maybe people will be more likely to implement some of them even though they can't take on the whole thing.
07:08:31 [dveditz]
... small focused documents are nice, and support "checkbox oriented development"
07:08:40 [npdoty]
npdoty has left #webappsec
07:08:41 [timeless]
s||-">|-> " reconcile/cross reference CSP and SRI hash behaviors" issue-363
07:08:52 [dveditz]
... cookies is separate, csp pinning is separate,
07:08:58 [dveditz]
JeffH: where are those?
07:09:10 [dveditz]
mkwst: those are subdirectories of webappsec-csp
07:09:36 [dveditz]
timeless: is there a link section in the document to those other documents
07:09:39 [dveditz]
mkwst: not currently
07:10:10 [dveditz]
...I talked to these lovely gentlement about setting up a registry for directives at the IETF so that's in progress
07:10:20 [dveditz]
[refrencing Barry and JeffH]
07:10:38 [dveditz]
[or maybe s/JeffH/mnot]
07:11:00 [mnot]
07:11:14 [timeless]
s|[or maybe s/JeffH/mnot]||
07:11:18 [timeless]
07:11:26 [dveditz]
... that means the spec will have an IANA Considerations section, and new specs will have bits that say "register this new directive over there"
07:12:00 [dveditz]
... feedback wanted on the module concept
07:12:39 [timeless]
s||-">|-> "Content Security Policy Directive Registry" (IETF Draft, in last call)
07:12:42 [dveditz]
francois: you said "... if only people would implement nonces and hashes..." have you thought about making CSP3 into CSP1+nonces and hashes
07:13:22 [dveditz]
mkwst: maybe? I've told people those are important but I don't know that this will help?
07:13:36 [dveditz]
... these are already in CSP2 so
07:13:51 [dveditz]
JeffH: is the intent to leapfrog CSP2?
07:13:51 [timeless]
s||-">|-> "Review the stability of all referenced documents" (issue-3)
07:14:02 [dveditz]
mkwst: I'm done with csp2 now ... I'm doing this now
07:14:21 [dveditz]
bhill2: I hope CSP2 will go to rec, there's not a lot more left to do
07:14:45 [timeless]
s||-">|-> "Convert to Bikeshed" (issue-12)
07:15:17 [timeless]
RRSAgent, draft minutes
07:15:17 [RRSAgent]
I have made the request to generate timeless
07:15:25 [dveditz]
mkwst: the testsuite is important, but that's the only part I'm interested in the process of finalizing. As part of Google of course the patent protection is impt, and some people wait for recommendation before implementing so that would be good too
07:15:36 [bhill2]
07:15:55 [timeless]
07:16:06 [timeless]
07:16:21 [dveditz]
francois: if CSP3 is just CSP2 rewritten then people who implement CSP 2 can also claim CSP3?
07:16:30 [dveditz]
mkwst: there's some additional stuff in there, but sure
07:17:17 [dveditz]
... I'm fine with publishing "CSP 2 with better explanations of the mechanism and better reporting". sure
07:17:30 [timeless]
s||-">|-> "<iframe sandbox srcdoc='foo'> on a secure page should be secure" issue-5
07:18:13 [timeless]
s||-> ED: Mixed Content
07:18:13 [dveditz]
... I don't want to work on another monolith that will take 5 years to complete
07:18:40 [dveditz]
jungkees(?): during the break we talked about @@
07:18:52 [timeless]
s||-">|-> HSTS, mixed content, and priming
07:19:08 [dveditz]
mkwst: I don't see an issue off the top so maybe we didn't file one. we should do that
07:19:11 [Kepeng]
jungkees --> Kepeng Li
07:19:33 [dveditz]
s/junkees/Kepeng Li/
07:19:44 [dveditz]
s/jungkees/Kepeng Li/
07:19:50 [mkwst]
07:19:58 [timeless]
RRSAgent, draft minutes
07:19:58 [RRSAgent]
I have made the request to generate timeless
07:20:11 [dveditz]
mkwst: thread starting August 27th "CSP 401 issue"
07:20:19 [timeless]
s|s/junkees/Kepeng Li/||
07:20:31 [timeless]
07:20:57 [dveditz]
bhill2: I hve a question about policy combination. has come up in the past
07:21:07 [Melinda]
Melinda has joined #webappsec
07:21:16 [timeless]
s/Kepeng Li --> Kepeng Li//
07:21:19 [timeless]
07:21:27 [timeless]
RRSAgent, draft minutes
07:21:27 [RRSAgent]
I have made the request to generate timeless
07:21:39 [dveditz]
... in modular specs you can have
07:21:54 [timeless]
s|s/Kepeng Li --> Kepeng Li//||
07:22:00 [dveditz]
... we should require modular specs to define an intersection mechanic
07:22:12 [timeless]
s/Kepeng Li/KLi/
07:22:14 [timeless]
s/Kepeng Li/KLi/
07:22:17 [timeless]
RRSAgent, draft minutes
07:22:17 [RRSAgent]
I have made the request to generate timeless
07:22:45 [dveditz]
mkwst: whatever directive we define will set state somewhere, and would have to define that. and whenever we see a policy we call that algorithm for that directive
07:22:50 [timeless]
s/ --> /_arrow_/
07:22:52 [timeless]
RRSAgent, draft minutes
07:22:52 [RRSAgent]
I have made the request to generate timeless
07:23:17 [timeless]
s/KLi _arrow_KLi//
07:23:19 [timeless]
RRSAgent, draft minutes
07:23:19 [RRSAgent]
I have made the request to generate timeless
07:23:21 [dveditz]
... the policy per directive could be 'ignore those after the first', some way to combine them, some way to pick the strictest.
07:23:32 [dveditz]
bhill2: what's the semantics of reporting in the new spec?
07:24:01 [dveditz]
mkwst: the report applies to the policy. a violation in a policy goes to the reporting URL related to that policy
07:24:42 [dveditz]
... it would be helpful if this document defined the considerations that modular CSP specs need to define to be part of it
07:24:51 [dveditz]
... the IANA registration has some of that already
07:25:02 [bblfish]
bblfish has joined #webappsec
07:26:23 [dveditz]
mkwst: so what do you think of francois's idea of stripping out everything unimportant and publish what we can quickly?
07:27:10 [Kepeng]
07:27:14 [dveditz]
... I will take an action to strip out things from CSP 2 that isn't implemented in other browsers, keep reporting, and then other things can be left to other specs layered on top
07:27:39 [dveditz]
Kepeng: what about navigations?
07:28:24 [dveditz]
mkwst: I'm skeptical of specs that block navigations. I've written specs that do that, but we've seen that when there are ways to stop people from navigating people use that maliciously
07:28:34 [dveditz]
... I worry about things that break interactions for users
07:28:49 [dveditz]
... this would be less bad because users can just open another tab
07:29:11 [dveditz]
... we can talk about it. I'm skeptical but I'm open to use cases that would be compelling
07:29:31 [Kepeng]
07:29:35 [dveditz]
... file a bug on github, disuss it there too. all in one place, nice and focused
07:29:54 [dveditz]
Kepeng: what about this issue
07:30:02 [dveditz]
mkwst: mostly taken care of in the current draft
07:31:02 [dveditz]
... child-src used to govern opening a new window on an origin, but we removed it
07:31:25 [dveditz]
... I know doubleclick wants this, because they want to restrict where a popup add can do
07:31:40 [dveditz]
... maybe worth considering because there are uses, but it won't be in child-src
07:32:27 [dveditz]
... "csp-embedded-enforcement" -- most directives don't cascade into frames. would be dangerous in fact
07:33:31 [dveditz]
... but if there's cooperation between embeddor and embedee we could allow it. outer says "only embed this if it complies with this policy" and then we only load children that match that policy.
07:34:00 [dveditz]
... so cascades, but the potential "victim" site has to opt-in. Kind of an inverse-CORS
07:34:37 [Melinda]
Melinda has left #webappsec
07:34:48 [dveditz]
... Current definition in this doc is simple -- we send a request header and expect the response to match exactly
07:35:26 [dveditz]
... originally I tried to be clever and use a "subsumes" policy, but that was difficult to calculate. maybe simplistic will work.
07:35:43 [dveditz]
... Not currently part of the charter, but I'd like to bring it to the group.
07:35:59 [dveditz]
[general mutterings of interest]
07:36:39 [dveditz]
... I'm hopeful this will be helpful in toning down some of the bad behaviors we see in ad networks
07:37:06 [dveditz]
... any other questions or comments?
07:38:13 [bhill2]
dveditz: what are you planning to remove?
07:38:23 [bhill2]
mkwst: base-uri, plugin-types, form-action, maybe frame-ancestors
07:39:11 [dveditz]
dveditz: what are you proposing to strip from what's in CSP2 as a "core CSP3"?
07:39:32 [dveditz]
mkwst: baseuri, form action, frame-ancestors?
07:39:47 [dveditz]
... maybe not much we can throw out, now angry people haven't imeplemented it
07:40:23 [dveditz]
... I'd be happy with "CSP3 Core" that is a "better explained CSP2" with improved reporting
07:41:01 [bhill2]
07:41:59 [dveditz]
... This allows a page to programmatically add a new policy to a document. Doesn't remove anything
07:42:23 [dveditz]
... people today are creating and applyting <meta> tags on the fly. This is a less insane equivalent
07:42:58 [dveditz]
yoav: with <meta> you know that things above it won't be covered and things below will
07:43:09 [dveditz]
... and now it will be racy
07:43:23 [dveditz]
bhill2: but people are effectively already doing this
07:43:42 [dveditz]
07:44:07 [dveditz]
yoav: as long as it's totally clear that there is a race if you do this
07:45:24 [dveditz]
07:45:53 [dveditz]
mkwst: idea of pinning is to apply CSP to an origin, even to documents that don't have a CSP
07:46:24 [dveditz]
... Google has been caught by this, for instance on error pages because they're generated by a separate system
07:46:52 [dveditz]
... there are a number of models we could use. pinning, manifests, policy-uri
07:47:13 [dveditz]
... we could revisit because there's better systems for reducing latency
07:47:24 [dveditz]
... they kind of solve different problems
07:47:50 [dveditz]
... pinning could specify a "default" -- applied everywhere and pages can layer on top.
07:48:24 [dveditz]
... or pinning could be a fallback, only applied to pages that don't have a CSP
07:48:35 [dveditz]
bhill2: I want this, but only the fallback form
07:48:44 [dveditz]
mkwst: Google would want fallback, too
07:49:49 [dveditz]
... youtube wants to move to a single monolith page, but doesn't want to define a single CSP that would cover all possible resources it might want to load
07:50:00 [dveditz]
... could we have mutable policies
07:50:20 [dveditz]
rbarnes: the danger is "surprise", if something changes out from under a dev
07:50:50 [dveditz]
bhill2: I want the fallback to be very restrictive. if you didn't specify a policy you're in jail, and you can get out by specifying a policy
07:51:24 [dveditz]
rbarnes: I worry people will approach this like CSS, adding just one thing
07:51:43 [dveditz]
timeless: having things break right away is good -- then people can fix it
07:52:08 [dveditz]
mnot: this is an origin-wide policy, right? couldn't have a different one for different parts of a site
07:52:11 [dveditz]
mkwst: correct
07:52:27 [dveditz]
mnot: the thing I'm thinking about would layer on top of this
07:52:47 [dveditz]
... somewhat orthogonal to what you're doing here
07:53:30 [dveditz]
rbarnes: I would be inclined to simplify. rather than have both just do the one brad likes (fallback)
07:53:44 [dveditz]
mkwst: at some point I'll get time to go back and rework this
07:53:58 [dveditz]
... if anyone would like to do any of this I would be happy
07:54:34 [dveditz]
... if there's new stuff it would be good for them to live in other docs so we can all progress at a different pace without holding each other up
07:54:41 [dveditz]
bhill2: anything else?
07:55:11 [dveditz]
annevk: we didn't cover during "Secure Contexts" is the IDL. should it hide, throw?
07:55:26 [bhill2]
TOPIC: Secure Contexts IDL
07:55:30 [dveditz]
mkwst: currently it throws/rejects. I like that model but I'm open to being convinced I'm wrong
07:55:51 [dveditz]
[heycam webidl issue 65]
07:56:21 [yoav]
yoav has joined #webappsec
07:56:45 [wseltzer]
07:56:52 [dveditz]
mkwst: defines a secure attribute that are applied to methods
07:57:12 [dveditz]
... and either rejects promises or throws for non-promises if they're used in a non-secure context
07:57:44 [dveditz]
rbarnes: I have trouble believe that's a well-defined definition
07:57:57 [dveditz]
mkwst: lookat the patch, hooks in right after the security check
07:58:49 [dveditz]
... right after we check that you have access to the object at all we check the context. I think rejecting/throwing is better than hiding the method
07:59:12 [dveditz]
... pretending the document doesn't support this when it does
07:59:30 [dveditz]
annevk: especially with the document.domain thing nuking secure contexts
08:00:47 [dveditz]
rbarnes: martin makes two argumentsd in the thread. [??]
08:01:11 [dveditz]
mkwst: I think it's an aesthetic question. do you fall into a feature-detection regime or an error situation
08:02:28 [dveditz]
annevk: two options for dealing with document.domain -- either we're a secure context and trying document.domain will throw
08:02:55 [dveditz]
... or setting it destroys the secure context
08:03:56 [timeless]
scribe: timeless
08:04:05 [timeless]
dveditz: if there's a TLS page, we define a secure-context
08:04:10 [timeless]
... how do you know if it's not one
08:04:19 [timeless]
mkwst: their proposal is that they're mutually exclusive
08:04:29 [timeless]
... do one thing, you're secure context, do the other, you're stopped
08:04:39 [timeless]
dveditz: what if you're secure context, then you ...
08:04:46 [timeless]
... oh, you're a potentially secure context
08:05:03 [timeless]
... then if you do something, you become secure context or not secure context
08:05:09 [timeless]
mkwst: can't know until you're observed
08:05:23 [timeless]
... as soon as you do one or the other
08:05:27 [timeless]
bhill2: you're a particle or a wave
08:05:36 [timeless]
dveditz: i wouldn't object if the outcome is document.domain goes away
08:05:41 [timeless]
mkwst: i hadn't thought about killing document.domain
08:05:45 [timeless]
dveditz: we'd need to measure
08:05:52 [timeless]
mkwst: i think it's too prevalent to kill
08:06:02 [timeless]
... but tying it to these features would reduce risk
08:06:09 [timeless]
... if you use document.domain you have risk
08:06:18 [timeless]
... it's totally in line w/ the rest of secure context to reduce risk
08:06:22 [timeless]
... i think it's totally worth it
08:06:27 [timeless]
yoav: any counters/usage data?
08:06:29 [timeless]
mkwst: maybe
08:06:33 [timeless]
bhill2: how does being a secure context
08:06:38 [timeless]
... an https origined thing
08:06:43 [timeless]
... that is not a secure context
08:06:55 [timeless]
... affect your ability to reach into the dom of a same-origin secure context?
08:07:04 [mkwst]
~4.8% of websites:
08:07:10 [timeless]
..., domain lower to
08:07:18 [timeless]
... can i reach into the iframe?
08:07:29 [timeless]
mkwst: only if the iframe also set document.domain to
08:07:37 [timeless]
... and we'd stop facebook because they'd want geolocation
08:07:42 [timeless]
... document.domain has to be set on both sides
08:07:57 [timeless]
dveditz: we explicitly require that because of the Princeton attack in 2001
08:08:03 [timeless]
annevk: port is set to magic value
08:08:17 [timeless]
dveditz: that's why people scratch their heads at document.domain=document.domain
08:08:29 [timeless]
mkwst: let's say 4.8% of secure websites
08:08:37 [bblfish]
bblfish has joined #webappsec
08:08:39 [timeless]
dveditz: is it secure? perhaps document.domain is a marker of old web site
08:08:44 [timeless]
mkwst: we can find out in 3 months
08:08:59 [timeless]
mkwst: we kill at 0.03%
08:09:06 [timeless]
annevk: it won't be that low
08:09:19 [timeless]
mkwst: setting document.domain, being secure context, and secure context mattering, is relatively low
08:09:24 [timeless]
dveditz: makes it more complicated
08:09:27 [timeless]
annevk: not really
08:09:40 [timeless]
dveditz: if we could say "you are an ssl page, document.domain throws"
08:09:49 [timeless]
annevk: usage won't be that low, we can't do that
08:10:04 [timeless]
... we can set a flag, and document.domain sets a flag, secure context sets a flag
08:10:17 [timeless]
annevk: idl annotation will have this
08:10:19 [timeless]
... automatic
08:10:24 [timeless]
timeless: and there's testing which should verify it
08:10:28 [timeless]
mkwst: let's explore this idea
08:10:34 [timeless]
... and firefox and chrome add metrics for this
08:10:41 [timeless]
... document.domain set inside https page
08:11:05 [timeless]
... lower 0.03% then we kill it
08:11:25 [timeless]
rbarnes: +1
08:11:39 [timeless]
mkwst: adding metric in chrome will be easy, but take some time to get data
08:11:43 [timeless]
... if we can kill it, great
08:12:06 [timeless]
topic: NextTopic
08:12:18 [timeless]
bhill2: SomethingHandling for more secure redirects
08:12:22 [timeless]
... Containers for Mozilla
08:12:31 [timeless]
... folks might not be here yet
08:12:40 [timeless]
ZZZ: referer policy?
08:12:48 [timeless]
... I'd like to know where we're at
08:12:57 [timeless]
... are we trying to finish off the spec, go w/ what we have now
08:13:03 [timeless]
... or an opportunity to see two more policies
08:13:13 [timeless]
mkwst: my name is on the spec, i want to take my name on the spec
08:13:20 [timeless]
... yohanan said he wanted to finish it
08:13:29 [timeless]
... if you feel strongly about adding features, talk to him
08:13:32 [bhill2]
08:13:51 [timeless]
08:13:59 [timeless]
mkwst: we talked about Timing Attacks
08:14:06 [timeless]
... if people have feedback...
08:14:21 [timeless]
s/Timing Attacks/Referrer Policy
08:14:35 [timeless]
rbarnes: we discussed Timing Attacks, because mkwst fixed it
08:14:39 [timeless]
mkwst: i only fixed one
08:14:44 [timeless]
... there's a paper at the bottom
08:14:58 [timeless]
... it wasn't a timing attack, now it's a timing attack
08:15:05 [timeless]
... if you have ideas of how to fix it, let's implement it
08:15:15 [timeless]
RRSAgent, draft minutes
08:15:15 [RRSAgent]
I have made the request to generate timeless
08:15:26 [timeless]
yoav: skimming timing attack thing
08:15:35 [timeless]
... they're downloading resources, estimating sizes based on download time
08:15:46 [timeless]
... they only have to do because no one has implemented Transfer-Body-Size
08:15:49 [timeless]
... which would give them that
08:15:55 [timeless]
... or they could XHR the images and measure
08:15:59 [timeless]
annevk: that won't be exposed
08:16:10 [timeless]
mkwst: only if the endpoint opts in via cors
08:16:31 [timeless]
annevk: read up on same-origin policy
08:16:46 [timeless]
bhill2: they load resource, try to feed it to <audio> or <video>
08:16:53 [timeless]
... IE/FF fail immediately
08:17:00 [timeless]
... the time it takes to fail gives out size
08:17:10 [timeless]
... similarly scripts, AppCache
08:17:20 [timeless]
... for ServiceWorkers, you can load an opaque thing cross-origin
08:18:15 [timeless]
yoav: goal is to determine size of object
08:18:20 [timeless]
annevk: not for no cors
08:18:29 [timeless]
yoav: not for third party unless they allow origin
08:18:33 [timeless]
annevk: yes, but this is about that
08:19:52 [timeless]
bhill2: they could make the object uncompressible if they wanted to
08:20:50 [mnot]
mnot has joined #webappsec
08:23:15 [annevk]
yoav: I recommend reading through
08:24:57 [timeless]
[ Adjourned until tomorrow ]
08:25:21 [wseltzer]
rrsagent, make minutes
08:25:21 [RRSAgent]
I have made the request to generate wseltzer
08:38:26 [rbarnes]
rbarnes has joined #webappsec
08:46:20 [barryleiba]
barryleiba has joined #webappsec
08:59:17 [wonsuk]
wonsuk has joined #webappsec
09:13:05 [barryleiba]
barryleiba has joined #webappsec
09:13:38 [wonsuk]
wonsuk has joined #webappsec
09:38:09 [Zakim]
Zakim has left #webappsec
09:39:59 [barryleiba]
barryleiba has joined #webappsec
09:59:30 [jyasskin]
jyasskin has joined #webappsec
10:05:56 [bhill2]
bhill2 has joined #webappsec
10:36:02 [jyasskin]
jyasskin has joined #webappsec
12:35:18 [rbarnes]
rbarnes has joined #webappsec
13:00:12 [rbarnes]
rbarnes has joined #webappsec
13:19:08 [yoav]
yoav has joined #webappsec
13:20:09 [kimwooglae]
kimwooglae has joined #webappsec
13:21:16 [barryleiba]
barryleiba has joined #webappsec
13:22:35 [yoav]
yoav has joined #webappsec
13:24:02 [rbarnes]
rbarnes has joined #webappsec
13:34:30 [rbarnes]
rbarnes has joined #webappsec
13:42:02 [bhill2]
bhill2 has joined #webappsec
14:03:23 [jyasskin]
jyasskin has joined #webappsec
14:17:40 [kimwooglae]
kimwooglae has joined #webappsec
14:55:40 [wseltzer]
rrsagent, bye
14:55:40 [RRSAgent]
I see no action items