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
<sangrae> +[IPcaller]
<scribe> scribe: hhalpin
scribenick 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: AOB?
<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[End of scribe.perl diagnostic output]