See also: IRC log
<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
<scribe> scribe: hhalpin
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> minutes of previous F2F meeting
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
rsleevi: the work on futures is
... 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
... 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
... 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
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].
<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
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
... 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,
... 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
... 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
... 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
<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"
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
<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...
<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
<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
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[End of scribe.perl diagnostic output]