<trackbot> Date: 06 May 2013

trackbot, start meeting

<trackbot> Meeting: Web Cryptography Working Group Teleconference

<trackbot> Date: 06 May 2013

<sangrae> I am on the bridge. [IPcaller] is sangrae

<karen_od> I am on the bridge but will be listening only - not in a position to speak easily (Karen O'Donoghue)

<israelh> israelh is on the phone

<israelh> from Microsoft

<karen_od> karen o'donoghue is on the phone

<sangrae> +[IPcaller]

<scribe> scribe: hhalpin

scribenick hhalpin

intro

virginie: go over webcrypto topics first, then use-cases, then future stuff and review

<jyates> Zakim aagg is jyates

<israelh> I would like to discuss Web Crypto Spec Feedback on Dictionaries as return type properties

virginie: AOB?

Futures

<virginie> minutes of previous F2F meeting

<virginie> http://www.w3.org/2013/04/23-crypto-minutes.html

<virginie> http://www.w3.org/2013/04/24-crypto-minutes.html

PROPOSED: http://www.w3.org/2013/04/23-crypto-minutes.html

and http://www.w3.org/2013/04/24-crypto-minutes.html are the official meeting minutes of the f2f

<virginie> minutes agreed

<MichaelH> I wasn't on the attendee list

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

https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html

rsleevi: the work on futures is ongoing
... one of thing I'm focussing on is not just WebIDL but also getting algorithms properly specified
... 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
... so I haven't pushed an update out yet
... since I want the normative sections strong
... that is holding up other dates

virginie: are you going to produce another version?

rsleevi: as I've changed the spec, we can always visit

notes this is why the spec is in a repo, thus we can revert any changes if we want them

I'd be against forking the spec into a Futures and non-Futures version.

rsleevi: each commit is atomic
... it currently has a few bugs and is incomplete
... I am trying to resolve these in a way that is consistent with futures

<MichaelH> Is Futures and Streaming atomic together?

rsleevi: then we'd have to revist some of these other issues

MichaelH: Is streaming and Futures two different features?

rsleevi: yes, they are different and we have no plan to include streaming righ tnow
... streaming would be a broader change

MichaelH: We were going to wait for Futures and Streaming

rsleevi: no
... to be clear, we are going to release an edit with Futures with an updated processing model to makes sure its consistent
... 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)

israelh: we've been looking through is defined as a dictionary
... but there's problems with WebID returning a dictionary type
... so we suggested that we want a getAlgorithm method

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0006.html

israelh: that one of the things we were looking at and trying to reconcile

rsleevi: why doesn't WebIDL allow this is a bit of a mess
... the interface object effectively duplicates a dictionary
... the only distinction is idiomatic

israelh: one thing ryan mentioned so just wanted to make sure you get back to us to close this

michaelh: when we are we finished this

rsleevi: I'll confirm TAG and/or WebApps is best place

<scribe> ACTION: rsleevi to get review of dictionary/WebIDL problem from TAG and/or WebApps [recorded in http://www.w3.org/2013/05/06-crypto-minutes.html#action01]

<trackbot> Created ACTION-98 - Get review of dictionary/WebIDL problem from TAG and/or WebApps [on Ryan Sleevi - due 2013-05-13].

virginie: ArrayBufferView

<rsleevi> ACTION: rsleevi to get review of ArrayBuffer/ArrayBufferView problem from TAG and/or WebApps [recorded in http://www.w3.org/2013/05/06-crypto-minutes.html#action02]

<trackbot> Created ACTION-99 - Get review of ArrayBuffer/ArrayBufferView problem from TAG and/or WebApps [on Ryan Sleevi - due 2013-05-13].

israelh: let's separate the threads

virginie: wrap/unwrap?

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
... rsleevi's position is that there should be no distinction, I think there are very valuable cases where key material is hidden from JS

rsleevi: to clarify, its not that there's no value between UA and JS
... but we haven't figured out the threats
... or the value
... what guarnatees are we trying to provide and which ones can we reliably provide in web security model
... currently based on origin, CORS exists to mitigate this
... markw put this as a concern of access to key material
... and in what model can the key material be outside the security boundary
... in non-pre-provisioned case, what's the assumptions?
... we need to separate open web from vendor specific solutions

virginie: how does this relate to extractable attribute?
... can we not guarantee that or is that now out of scope?

rsleevi: extractability is related to this
... its very related to structured clone
... what is the guarnatees that extractable provides
... as its clonable, if there is XSS into origin A, you can post that key to origin B
... under what places can we figure out if the extractable fits in the overall API

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
... if you wanted to access key material, you'd wrap it so JS didn't have that access
... to key material

vgb: this discussion confuses me, there are some things the UA can do that JS can't do
... for example, getRandomValue, the UA must do it to be secure but of course JS can't do it securely
... thus we have accepted this UA/JS disctinction in principle for security boundaries
... even if we can't enforce as it could be polyfilled
... with key wrap/unwrap there is an actual difference in severity of attack
... so maybe it makes sense as a hardening measure

markw: how does this relate to XSS?
... one thing to move key object from one site to another
... that's why you can with XSS do a very restricted oracle
... but if you can obtain the keymaterial from UA and into JS, then you can do all sorts of attacks obviously
... it seems to be me pretty obvious then we need to maintain this in UA, so we need "extractable" and "key wrap and unrap"

<Zakim> rsleevi, you wanted to respond to MichaelH

rsleevi: this goes back to where we define security boundary
... 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
... is it sufficient or not?
... can we do this, depends on use-cases and security model.
...
... so if the whole question is where the security boundary
... signed JS, CORS, pinning
... we are trying to make Web Platform holistically secure
... restrict the running of code to known good subset
... we want a solution that works for all of your APIs
... s we need to describe security model
... is the JS within the security boundary or not
... the entire web so far says yes
... if you have a known good subset, then you can't perform these attacks, otherwise you can't.
... maybe this is an issue for webappsec
... should not deal with this on a per-app basis
... its like geolocation tracking on a same origin basis

markw: this seems to go back to extractability
... and so we'd have to revisit this all

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'

<rsleevi> @MichaelH: I am not really sure I understand your point.

MichaelH: if I generate the key, vs. import and wrap end-to-end
... is there some way to state there is a way to only use a key that is in a UA and not JS?

<rsleevi> @MichaelH: We've said for a long time that this API provides no guarantees or statements about where a key "lives"

MichaelH: now whether that will be implemented is still up for grabs

<rsleevi> There is no function for saying "I want this key to only live in a UA"

<rsleevi> and that is intentional

<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

<rsleevi> @MarkW: You have no guarantees that the key was generated within the UA

<rsleevi> @Virginie: This was never an issue about reversing our discussion about wrap/unwrap in the next draft

well we can't ask for a review until we get an editors draft

<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

<rsleevi> @Virginie: eg: this whole discussion *must* be included in security considerations, which is "What are the guarantees we're trying to provide, and can we actually provide them"

<markw> @rsleevi: when I use generateKey with extractable = false, the key material is not available to the Javascript, that is all

Just put on an editors draft and then discuss with WebAppSec

happy to set-up a joint call but we need to get them the most up to date draft to review

<markw> @rsleevi: so perhaps when we say "UA" we really mean "not JS"

<rsleevi> @MarkW: Assuming no 'malicious' code is running at that time, sure ;) But the remote endpoint has no guarantees

<markw> @rsleevi: I'm taking the TOFU model as a given through all of this

<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

<jimsch_> +1

<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.

I am happy to email Mike and Richard.

<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"

<karen_od> I believe that is swapped from the earlier email...

<virginie> +1

<vgb> +1

<nvdbleek> I would like to be there, but have a conflicting meeting

<virginie> who will show up on key discovery ?

OK, let's just send out an email

its easy to book more time

<karen_od> it is in Virginie's email to the list

<nvdbleek> i will attend in 3 weeks, the key discovery

So, next week is key agreement and (maybe) high-level

with the following being key discovery, correct?

<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

<rsleevi> yes

<markw> sure

<jimsch_> Any progress on F2F in July?

week following IETF meeting

Frauhofer institute is OK in principle

<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.

Next Monday: Key Agreement

<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.

Monday 13: key agreement

Monday 20: key discovery

Monday, high-level depending on response to mail to list

meeting adjourned

trackbot, end meeting

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/correct/strong/
Succeeded: s/rsleevi's/rsleevi's position is that there should be no distinction/
Succeeded: s/that/that key/
Succeeded: s/basis/same origin basis/
Succeeded: s/security discussions/security considerations/
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin
Default Present: [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, ddahl, +1.512.257.aaff, rsleevi, +1.857.928.aagg, Gregg_Vanderheiden, mitchz, vgb
Present: [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 ddahl +1.512.257.aaff rsleevi +1.857.928.aagg Gregg_Vanderheiden mitchz vgb
Found Date: 06 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/06-crypto-minutes.html
People with action items: rsleevi