19:57:39 <RRSAgent> RRSAgent has joined #crypto
19:57:39 <RRSAgent> logging to http://www.w3.org/2013/05/06-crypto-irc
19:57:41 <trackbot> RRSAgent, make logs public
19:57:41 <Zakim> Zakim has joined #crypto
19:57:43 <trackbot> Zakim, this will be SEC_WebCryp
19:57:43 <Zakim> ok, trackbot, I see SEC_WebCryp()4:00PM already started
19:57:44 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:57:44 <trackbot> Date: 06 May 2013
19:57:53 <hhalpin> trackbot, start meeting
19:57:56 <trackbot> RRSAgent, make logs public
19:57:58 <trackbot> Zakim, this will be SEC_WebCryp
19:57:58 <Zakim> ok, trackbot, I see SEC_WebCryp()4:00PM already started
19:57:59 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:57:59 <trackbot> Date: 06 May 2013
19:58:04 <Zakim> + +1.408.540.aaaa
19:58:05 <hhalpin> Zakim, what's the code?
19:58:05 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
19:58:21 <markw> Zakim, aaaa is Netflix
19:58:21 <Zakim> +Netflix; got it
19:58:31 <markw> Zakim, Netflix has markw
19:58:31 <Zakim> +markw; got it
19:58:37 <Zakim> + +1.540.809.aabb
19:59:04 <karen_od> karen_od has joined #crypto
19:59:29 <nvdbleek> nvdbleek has joined #crypto
19:59:30 <Zakim> + +1.415.294.aacc
19:59:41 <arunranga> Zakim, aacc is Arun Ranganathan
19:59:41 <Zakim> I don't understand 'aacc is Arun Ranganathan', arunranga
19:59:45 <nvdbleek> zakim, code?
19:59:45 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
19:59:53 <arunranga> Zakim, aacc is arunranga
19:59:53 <Zakim> +arunranga; got it
19:59:56 <Zakim> +[IPcaller.a]
20:00:02 <hhalpin> Zakim, [IPcaller.a] is hhalpin
20:00:02 <Zakim> +hhalpin; got it
20:00:53 <Zakim> + +1.512.257.aadd
20:01:14 <Zakim> +[Microsoft]
20:01:34 <virginie> zakim, who is on the bridge ?
20:01:34 <Zakim> I don't understand your question, virginie.
20:01:42 <hhalpin> Zakim, who's on the phone?
20:01:42 <Zakim> On the phone I see [IPcaller], Netflix, +1.540.809.aabb, arunranga, hhalpin, +1.512.257.aadd, [Microsoft]
20:01:44 <Zakim> Netflix has markw
20:01:53 <israelh> israelh has joined #crypto
20:02:03 <Zakim> + +1.650.214.aaee
20:02:15 <sangrae> I am on the bridge. [IPcaller] is sangrae
20:02:35 <Zakim> +ddahl
20:02:51 <karen_od> I am on the bridge but will be listening only - not in a position to speak easily (Karen O'Donoghue)
20:02:53 <Zakim> + +1.512.257.aaff
20:02:56 <rsleevi> rsleevi has joined #crypto
20:02:57 <virginie> Zakim, who's on the phone?
20:02:58 <Zakim> On the phone I see [IPcaller], Netflix, +1.540.809.aabb, arunranga, hhalpin, +1.512.257.aadd, [Microsoft], +1.650.214.aaee, ddahl, +1.512.257.aaff
20:02:58 <Zakim> Netflix has markw
20:03:29 <virginie> Zakim, who's on the phone?
20:03:30 <Zakim> On the phone I see [IPcaller], Netflix, +1.540.809.aabb, arunranga, hhalpin, +1.512.257.aadd, [Microsoft], Google, ddahl, +1.512.257.aaff
20:03:30 <Zakim> Google has rsleevi
20:03:30 <Zakim> Netflix has markw
20:03:38 <israelh> israelh is on the phone
20:03:45 <Zakim> +??P12
20:03:45 <israelh> from Microsoft
20:03:46 <karen_od> karen o'donoghue is on the phone
20:03:46 <Zakim> + +1.857.928.aagg
20:03:51 <MichaelH> MichaelH has joined #CRYPTO
20:03:57 <hhalpin> Zakim, pick a scribe
20:03:57 <Zakim> Not knowing who is chairing or who scribed recently, I propose hhalpin
20:04:03 <sangrae> +[IPcaller]
20:04:05 <hhalpin> chair: virginie
20:04:09 <hhalpin> scribe: hhalpin
20:04:13 <hhalpin> scribenick hhalpin
20:04:15 <mitchz> mitchz has joined #crypto
20:04:32 <hhalpin> topic: intro
20:04:56 <hhalpin> virginie: go over webcrypto topics first, then use-cases, then future stuff and review
20:05:07 <jyates> Zakim aagg is jyates
20:05:23 <Zakim> +Gregg_Vanderheiden
20:05:43 <israelh> I would like to discuss  Web Crypto Spec Feedback on Dictionaries as return type  properties
20:05:45 <hhalpin> ... AOB?
20:06:02 <hhalpin> topic: Futures
20:06:38 <jimsch> jimsch has joined #crypto
20:06:45 <virginie> minutes of previous F2F meeting
20:06:47 <virginie> http://www.w3.org/2013/04/23-crypto-minutes.html
20:06:54 <virginie> http://www.w3.org/2013/04/24-crypto-minutes.html
20:07:01 <hhalpin> PROPOSED:  http://www.w3.org/2013/04/23-crypto-minutes.html
20:07:17 <hhalpin> and http://www.w3.org/2013/04/24-crypto-minutes.html are the official meeting minutes of the f2f
20:07:17 <markw> Zakim, Netflix has markw, mitchz
20:07:18 <Zakim> markw was already listed in Netflix, markw
20:07:19 <Zakim> +mitchz; got it
20:07:23 <virginie> minutes agreed
20:07:37 <MichaelH> I wasn't on the attendee list
20:08:03 <hhalpin> RESOLUTION  http://www.w3.org/2013/04/23-crypto-minutes.html and p://www.w3.org/2013/04/24-crypto-minutes.html are approved, and that MichaelH must be added to attendee list
20:09:36 <hhalpin> https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html
20:09:48 <hhalpin> rsleevi: the work on futures is ongoing
20:10:04 <hhalpin> ... one of thing I'm focussing on is not just WebIDL but also getting algorithms properly specified
20:10:26 <hhalpin> ... I'm working on trying to resolve those in a way that is consistent to Futures and would also allow streaming semantics if we wanted that
20:10:32 <hhalpin> ... so I haven't pushed an update out yet
20:10:41 <hhalpin> ... since I want the normative sections correct
20:10:50 <hhalpin> s/correct/strong
20:11:12 <hhalpin> rsleevi: that is holding up other dates
20:12:06 <hhalpin> virginie: are you going to produce another version?
20:12:34 <hhalpin> rsleevi: as I've changed the spec, we can always visit
20:12:51 <hhalpin> notes this is why the spec is in a repo, thus we can revert any changes if we want them
20:13:11 <hhalpin> I'd be against forking the spec into a Futures and non-Futures version.
20:13:20 <hhalpin> rsleevi: each commit is atomic
20:14:00 <hhalpin> ... it currently has a few bugs and is incomplete
20:14:07 <hhalpin> ... I am trying to resolve these in a way that is consistent with futures
20:14:12 <MichaelH> Is Futures and Streaming atomic together?
20:14:17 <hhalpin> ... then we'd have to revist some of these other issues
20:14:43 <MichaelH> q+
20:15:23 <hhalpin> MichaelH: Is streaming and Futures two different features?
20:15:31 <hhalpin> rsleevi: yes, they are different and we have no plan to include streaming righ tnow
20:16:38 <hhalpin> ... streaming would be a broader change
20:16:54 <hhalpin> MichaelH: We were going to wait for Futures and Streaming
20:16:59 <hhalpin> rsleevi: no
20:17:53 <hhalpin> ... to be clear, we are going to release an edit with Futures with an updated processing model to makes sure its consistent
20:18:29 <hhalpin> ... that being said, the processing model for v1 *could* accomodate streaming, but whether or not we decide to incorproate streaming in v.2 (v.next)
20:19:55 <hhalpin> israelh: we've been looking through is defined as a dictionary
20:20:07 <hhalpin> ... but there's problems with WebID returning a dictionary type
20:20:16 <vgb> vgb has joined #crypto
20:20:22 <Zakim> +[Microsoft.a]
20:20:32 <vgb> zakim, [microsoft.a] is me
20:20:32 <Zakim> +vgb; got it
20:20:33 <hhalpin> ... so we suggested that we want a getAlgorithm method
20:20:50 <virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0006.html
20:20:52 <virginie> q?
20:20:56 <hhalpin> ... that one of the things we were looking at and trying to reconcile
20:20:58 <hhalpin> q- MichaelH
20:22:04 <hhalpin> rsleevi: why doesn't WebIDL allow this is a bit of a mess
20:22:25 <hhalpin> ... the interface object effectively duplicates a dictionary
20:22:34 <hhalpin> ... the only distinction is idiomatic
20:22:42 <jimsch_> jimsch_ has joined #crypto
20:23:03 <MichaelH> q+
20:24:20 <hhalpin> israelh: one thing ryan mentioned so just wanted to make sure you get back to us to close this
20:24:47 <hhalpin> michaelh: when we are we finished this
20:24:58 <hhalpin> rsleevi: I'll confirm TAG and/or WebApps is best place
20:25:21 <hhalpin> ACTION: rsleevi to get review of dictionary/WebIDL problem from TAG and/or WebApps
20:25:21 <trackbot> Created ACTION-98 - Get review of dictionary/WebIDL problem from TAG and/or WebApps [on Ryan Sleevi - due 2013-05-13].
20:25:43 <hhalpin> virginie: ArrayBufferView
20:25:53 <rsleevi> ACTION: rsleevi to get review of ArrayBuffer/ArrayBufferView problem from TAG and/or WebApps
20:25:53 <trackbot> Created ACTION-99 - Get review of ArrayBuffer/ArrayBufferView problem from TAG and/or WebApps [on Ryan Sleevi - due 2013-05-13].
20:25:54 <hhalpin> israelh: let's separate the threads
20:27:22 <markw> q+
20:27:24 <rsleevi> q+
20:27:32 <hhalpin> q- MichaelH
20:27:40 <hhalpin> virginie: wrap/unwrap?
20:28:41 <hhalpin> markw: we should figure out the wrap and unwrap, in the absence of pre-provisioned keys, should there be any distinction between UA and JS implemetnatin
20:28:57 <hhalpin> ... rsleevi's, I think there are very valuable cases where key material is hidden from JS
20:29:17 <hhalpin> s/rsleevi's/rsleevi's position is that there should be no distinction
20:29:18 <MichaelH> q+
20:29:22 <hhalpin> q- markw
20:29:43 <hhalpin> rsleevi: to clarify, its not that there's no value between UA and JS
20:29:48 <hhalpin> ... but we haven't figured out the threats
20:29:51 <hhalpin> ... or the value
20:30:03 <hhalpin> ... what guarnatees are we trying to provide and which ones can we reliably provide in web security model
20:30:39 <hhalpin> ... currently based on origin, CORS exists to mitigate this
20:30:51 <hhalpin> ... markw put this as a concern of access to key material
20:30:56 <vgb> q+
20:31:07 <hhalpin> ... and in what model can the key material be outside the security boundary
20:31:17 <hhalpin> ... in non-pre-provisioned case, what's the assumptions?
20:31:35 <hhalpin> ... we need to separate open web from vendor specific solutions
20:32:20 <hhalpin> virginie: how does this relate to extractable attribute?
20:32:27 <hhalpin> ... can we not guarantee that or is that now out of scope?
20:32:38 <hhalpin> rsleevi: extractability is related to this
20:32:43 <hhalpin> ... its very related to structured clone
20:32:52 <hhalpin> ... what is the guarnatees that extractable provides
20:33:08 <hhalpin> ... as its clonable, if there is XSS into origin A, you can post that to origin B
20:33:09 <markw> q+
20:33:14 <hhalpin> s/that/that key
20:33:43 <hhalpin> ... under what places can we figure out if the extractable fits in the overall API
20:34:42 <hhalpin> MichaelH: I thought JS had access to KeyObject but not key material, but key material could be anywhere, including material - i.e. it could sign, decrypt, unwrap
20:35:01 <hhalpin> ... if you wanted to access key material, you'd wrap it so JS didn't have that access
20:35:07 <hhalpin> ... to key material
20:35:44 <hhalpin> vgb: this discussion confuses me, there are some things the UA can do that JS can't do
20:36:01 <hhalpin> ... for example, getRandomValue, the UA must do it to be secure but of course JS can't do it securely
20:36:21 <hhalpin> ... thus we have accepted this UA/JS disctinction in principle for security boundaries
20:36:31 <hhalpin> ... even if we can't enforce as it could be polyfilled
20:37:29 <hhalpin> ... with key wrap/unwrap there is an actual difference in severity of attack
20:37:37 <hhalpin> ... so maybe it makes sense as a hardening measure
20:37:49 <hhalpin> markw: how does this relate to XSS?
20:37:58 <hhalpin> ... one thing to move key object from one site to another
20:38:11 <hhalpin> ... that's why you can with XSS do a very restricted oracle
20:38:30 <hhalpin> ... but if you can obtain the keymaterial from UA and into JS, then you can do all sorts of attacks obviously
20:39:22 <hhalpin> ... it seems to be me pretty obvious then we need to maintain this in UA, so we need "extractable" and "key wrap and unrap"
20:39:22 <virginie> q?
20:39:30 <Zakim> rsleevi, you wanted to respond to MichaelH
20:39:59 <hhalpin> rsleevi: this goes back to where we define security boundary
20:40:28 <markw> q+
20:40:34 <hhalpin> ... if JS is within the boundary, so we could extract the key, then over TLS send the key to a remote endpoint, you have a trust boundary and its protected via TLS
20:40:35 <MichaelH> q+
20:40:38 <hhalpin> ... is it sufficient or not?
20:40:41 <virginie> Zakim, close the queue
20:40:41 <Zakim> ok, virginie, the speaker queue is closed
20:40:48 <hhalpin> ... can we do this, depends on use-cases and security model.
20:41:33 <hhalpin> ...
20:41:46 <hhalpin> ... so if the whole question is where the security boundary
20:41:51 <hhalpin> ... signed JS, CORS, pinning
20:41:58 <hhalpin> ... we are trying to make Web Platform holistically secure
20:42:08 <hhalpin> ... restrict the running of code to known good subset
20:42:17 <hhalpin> ... we want a solution that works for all of your APIs
20:42:25 <hhalpin> ... s we need to describe security model
20:42:42 <hhalpin> ... is the JS within the security boundary or not
20:42:52 <hhalpin> ... the entire web so far says yes
20:43:11 <hhalpin> ... if you have a known good subset, then you can't perform these attacks, otherwise you can't.
20:43:19 <hhalpin> ... maybe this is an issue for webappsec
20:43:47 <hhalpin> ... should not deal with this on a per-app basis
20:44:08 <hhalpin> ... its like geolocation tracking on a basis
20:44:16 <hhalpin> s/basis/same origin basis
20:44:40 <virginie> q?
20:45:16 <hhalpin> markw: this seems to go back to extractability
20:45:20 <hhalpin> ... and so we'd have to revisit this all
20:45:23 <hhalpin> q+
20:46:03 <hhalpin> I suggest that closing this issue is just an action for a review of next editors draft by WebAppSec, including "wrap/unwrap" as at risk and keeping 'extractability'
20:47:10 <rsleevi> @MichaelH: I am not really sure I understand your point.
20:47:11 <hhalpin> MichaelH: if I generate the key, vs. import and wrap end-to-end
20:47:24 <hhalpin> ... is there some way to state there is a way to only use a key that is in a UA and not JS?
20:47:35 <rsleevi> @MichaelH: We've said for a long time that this API provides no guarantees or statements about where a key "lives"
20:47:50 <hhalpin> ... now whether that will be implemented is still up for grabs
20:47:55 <rsleevi> There is no function for saying "I want this key to only live in a UA"
20:47:58 <rsleevi> and that is intentional
20:48:10 <markw> @MichaelH: if the Key object has extractable = false (and was either generated by the UA or delivered in wrapped form) then it means you can't use export or wrap on that key and so the secret keying material is not visible to Javascript
20:48:33 <rsleevi> @MarkW: You have no guarantees that the key was generated within the UA
20:49:16 <rsleevi> @Virginie: This was never an issue about reversing our discussion about wrap/unwrap in the next draft
20:49:19 <virginie> Zakim, open the queue
20:49:19 <Zakim> ok, virginie, the speaker queue is open
20:49:25 <hhalpin> well we can't ask for a review until we get an editors draft
20:49:35 <rsleevi> @Virginie: It was seeking a clarification about what the security guarantees we can actually have and provide - because those absolutely *must* be specified in our API for wrap/unwrap to make any sense
20:50:00 <rsleevi> @Virginie: eg: this whole discussion *must* be included in security discussions, which is "What are the guarantees we're trying to provide, and can we actually provide them"
20:50:13 <rsleevi> s/security discussions/security considerations/
20:50:21 <markw> @rsleevi: when I use generateKey with extractable = false, the key material is not available to the Javascript, that is all
20:50:23 <hhalpin> Just put on an editors draft and then discuss with WebAppSec
20:50:37 <hhalpin> happy to set-up a joint call but we need to get them the most up to date draft to review
20:50:48 <virginie> q?
20:50:56 <markw> @rsleevi: so perhaps when we say "UA" we really mean "not JS"
20:50:57 <rsleevi> @MarkW: Assuming no 'malicious' code is running at that time, sure ;) But the remote endpoint has no guarantees
20:51:34 <markw> @rsleevi: I'm taking the TOFU model as a given through all of this
20:51:55 <virginie> q?
20:53:35 <markw> @rsleevi: but more specifically, when someone calls the UA's implementation of generateKey (not a polyfill) with extractable = false, that key material is not available to the Javascript, assuming a WebCrypto-compliant UA implementation - this is by way of defining the API requirements
20:54:40 <jimsch_> +1
20:54:50 <rsleevi> @markw: In a world with no attackers, sure. I don't buy into any argument that hinges on TOFU - you have to trust, but verify. This API provides no guarantees (intentionally) for the 'verify' - that's a broader issue for the web platform.
20:55:11 <hhalpin> I am happy to email Mike and Richard.
20:55:13 <rsleevi> @markw: And that's my point. *this* API provides no guarantees that you're actually talking to the API. That guarantee must come from "elsewhere"
20:55:24 <karen_od> I believe that is swapped from the earlier email...
20:55:40 <virginie> +1
20:55:42 <vgb> +1
20:55:47 <nvdbleek> I would like to be there, but have a conflicting meeting
20:55:49 <virginie> who will show up on key discovery ?
20:56:44 <hhalpin> OK, let's just send out an email
20:56:48 <hhalpin> its easy to book more time
20:56:50 <karen_od> it is in Virginie's email to the list
20:56:57 <nvdbleek> i will attend in 3 weeks, the key discovery
20:57:30 <hhalpin> So, next week is key agreement and (maybe) high-level
20:57:37 <hhalpin> with the following being key discovery, correct?
20:58:03 <markw> @rsleevi: There are two different things to consider: what are the requirements on compliant implementations of this API and what guarantees do you have that you are talking to a compliant implementation
20:58:06 <rsleevi> yes
20:58:09 <markw> sure
20:58:19 <jimsch_> Any progress on F2F in July?
20:58:46 <hhalpin> week following IETF meeting
20:58:55 <hhalpin> Frauhofer institute is OK in principle
20:59:11 <markw> @rsleevi: we can work on the requirements. As to the guarantees, I agree that this API provides no guarantees. Pre-provisioned keys can provide a guarantee. Also, other things outside this API may provide guarantees, or assurances of some kind that are less than a guarantee but more than nothing.
20:59:58 <hhalpin> Next Monday: Key Agreement
20:59:59 <markw> @rsleevi: so it makes sense to provide functions which rely for their security value on talking to a real compliant implementation, even without pre-provisioned keys.
21:00:14 <hhalpin> Monday 13: key agreement
21:00:22 <hhalpin> Monday 20: key discovery
21:00:37 <hhalpin> Monday, high-level depending on response to mail to list
21:00:40 <Zakim> -Google
21:00:42 <Zakim> -??P12
21:00:43 <Zakim> - +1.857.928.aagg
21:00:43 <hhalpin> meeting adjourned
21:00:44 <Zakim> - +1.512.257.aadd
21:00:44 <Zakim> -Gregg_Vanderheiden
21:00:45 <Zakim> - +1.540.809.aabb
21:00:46 <Zakim> -[Microsoft]
21:00:47 <Zakim> -vgb
21:00:49 <hhalpin> trackbot, end meeting
21:00:49 <trackbot> Zakim, list attendees
21:00:49 <Zakim> As of this point the attendees have been [IPcaller], +1.408.540.aaaa, markw, +1.540.809.aabb, +1.415.294.aacc, arunranga, hhalpin, +1.512.257.aadd, [Microsoft], +1.650.214.aaee,
21:00:53 <Zakim> ... ddahl, +1.512.257.aaff, rsleevi, +1.857.928.aagg, Gregg_Vanderheiden, mitchz, vgb
21:00:53 <Zakim> -Netflix
21:00:55 <Zakim> -[IPcaller]
21:00:57 <trackbot> RRSAgent, please draft minutes
21:00:57 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/06-crypto-minutes.html trackbot
21:00:58 <trackbot> RRSAgent, bye
21:00:58 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2013/05/06-crypto-actions.rdf :
21:00:58 <RRSAgent> ACTION: rsleevi to get review of dictionary/WebIDL problem from TAG and/or WebApps [1]
21:00:58 <RRSAgent>   recorded in http://www.w3.org/2013/05/06-crypto-irc#T20-25-21
21:00:58 <RRSAgent> ACTION: rsleevi to get review of ArrayBuffer/ArrayBufferView problem from TAG and/or WebApps [2]
21:00:58 <RRSAgent>   recorded in http://www.w3.org/2013/05/06-crypto-irc#T20-25-53