<trackbot> Date: 19 August 2013

<kodonog> ?

<markw> scribenick markw_

<wseltzer> scribenick: markw

<scribe> scribenick: markw_

<markw> virginie: topics:

<markw> ... extractability

<markw> virginie: where are we with respect to publication ?

<markw> ... arun, mark ?

<markw> arun: been on vacation, sorry for the delay, will take care of it soon

<markw> ... believe all feedback taken into account and there is time during pubrules round to take into account any other points

<markw> virginie: agreed to go to next public working draft based on existing editors draft. We should publish what we have.

<markw> mark: in same situation as arun.

<arunranga> +1 ok by me

<markw> s/arus/arun/

last minutes discussion

<virginie> http://www.w3.org/2013/08/05-crypto-minutes.html

<markw> jimsch: minutes mention a registry

<markw> ... do you need an IANA registry or entries in one of the JOSE registries

<markw> rsleevie: entries in one of the JOSE registries, but getting that set up is dependent on JOSE drafts

<markw> jimsch: should be minutes of the last meeting be updated to reflect this ?

<markw> virginie: only if there is actually mistakes in the minutes, ok to minute it in this meeting

<rsleevi> Note that either way, the 'extractability' aspect is gated upon the publication of JOSE. Getting it into JOSE makes it easier to experiment early, but arguably both are valid approaches, PRESUMING that the attribute(s) are welcomed by the JOSE IANA registry

<markw> wseltzer: ok to use this meeting's minutes if it is just a clarification

<jimsch> Just a note in these minutes is acceptable to me

wrap/unwrap/import/export

<markw> virginie: we are blocked on the extractability item

<markw> ... also we don't have a proposal for the import/export sections

<markw> ... ryan - do you have an update

<markw> rsleevi: markw and I have an ongoing discussion on the extractability

<markw> ... trying to work through the appropriate security guarantees and theats

<markw> virginie: I don't understand how the discussion on security models in this context influences our specification

<markw> ... will it have a direct impact on the technical solution or only on security considerations ?

<markw> rsleevi: key question is what guaratees can a script author expect from the UA

<markw> ... concerns on our side that attempt to provide guarantees inconsistent with the web security model

<markw> virginie: today we have one attribute, extractablity. Is one of the outcomes that we remove extractability vs accept what has been proposed ?

<markw> rsleevi: specification is current "caller specifies", where it assume non-hostile JS at the time of unwrap

<markw> ... IIUC mark's concern is unwrapping in the presence of hostile JS

<markw> ... mark's propsosed using extractability attribute which works with JOSE and not with other formats

<markw> ... also discussion of explicit or implicit "viralness" where in unwrapped keys obtain attributes from the unwrapping key

<markw> ... boils down to fundamental questions on the security model - when is the script considered hostile

<markw> ... before the unwrap, after etc.

<wseltzer> markw: I made a few slides

<markw> https://docs.google.com/presentation/d/1S2t3ZS_LNXneaslaTPe8eULfYDAwnNVwlmJCnLcxcg0/edit?usp=sharing

<wseltzer> [markw reads from slides at https://docs.google.com/presentation/d/1S2t3ZS_LNXneaslaTPe8eULfYDAwnNVwlmJCnLcxcg0/ ]

<markw> arunranga: teh way I understand the proposal is that the UA must respect the extractable attribute and this is how hostile scripts are prevented from accessing the key

<markw> ... makes sense if you don't want to use HTTPS

<markw> ... aren't there other parts of the API where this problem exists too ?

<rsleevi> Actually, I'll minute that - Arun's summation reflects our concerns/objections

<markw> ... arunranga: have bee trying to catch up and this presentation clarifies things

<markw> ... mark wants the extractability attribute to be respected to lend more security than encrypting the key in transport

<Zakim> arunranga, you wanted to ask about other areas of Crypto API that are jeopardized if the script environment can't be trusted

<markw> markw: other aspects of the API don't similarly read on the importance of the location of the key (UA or JS)

<markw> ... the slides are intended to demonstrate that if extractability is useful at all then its also useful to have it maintained over unwrap as proposed

<markw> selfissued: [point about X.5096 that the scribe missed due to scribe interrupt]

<markw> rsleevi: [responded to selfissued, also during scribe interrupt]

<markw> rsleevi: extractability is when you go from known good environment and there is a possibility of hostile environment at later point in time

<markw> ... at the time your perform the operation you are going from a known good environment

<markw> ... current specification has the same semantics whatever operation you are doing

<markw> ... arun's question about whether there are other API calls that are risky in a hostile environment ?

<markw> ... pkcs paper circulated earlier shows some ways of extracting keying material using other operations

<markw> ... current approach reflects current web security principles of using HTTPS to reduce the chance of hostile JS

<markw> ... in which case the value of what mark proposed disappears

<jimsch> ack

<markw> jimsch: there are some other places where we have a model where we d similar things. e.g. signature operation and the key is not extractable then you restrict the set of hash operations

<arunranga> jimsch, that's a good comparison

<markw> virginie: we are having this discussion because there is a business value on the extractability for Netflix

<markw> ... on the other hand we have brower makers who don't want to take this on

<markw> ... situation is blocked

<markw> ... either we find a consensus or we remove the feature from the specification

<markw> ... questions for the Editor: if we remove extractable attribute, is that a big change ?

<markw> rsleevi: removing extractability would be a mistake - would be a significant and fundamental design change

<arunranga> +1 to keeping extractability. More thinking needed to determine its applicability to wrap/unwrap (at least on my part)

<MichaelH> +1

<jimsch> +1

<markw> +1

<rsleevi> +1 to what Arun said exactly

<ddahl> +1

<wseltzer> +1

<kodonog> +1

<markw> virginie; staw poll: who would like to keep extractability ?

<nvdbleek> +1

<karen> +1

<selfissued> +1

<selfissued> Keep extractability

<israelh> +1

<jimsch> +1

<rsleevi> -1

<selfissued> +1

<markw> virginie: another straw poll; who is interested in maintaining extractability across wrap/unwrap - should we spend more time on that

<markw> +1

<nvdbleek> +1

<israelh> +1 on what mark has been proposing

<MichaelH> +1

<markw> israelh: we have already supported the concept mark is proposing in our implementation

<markw> virginie: [scribe missed the question]

<jimsch> isrealh, how are you propogating the bit?

<virginie> is Microsoft happy with the implementations of wrap/unwrap and extractability

<markw> isrealh: our concern now is supporting the live Netflix beta site - seems to be working

<markw> virginie: good to hear that one implemtor is happy with mark's proposal

<rsleevi> Note that our concern is not that it cannot be implemented, simply that it cannot be reliably secured nor is it consistent with our web security position (HTTP vs HTTPS, SOP, hostile script)

<markw> virginie: we will continue to discuss this, but we have ryan on one side who is unhappy with the implications for the security model and we have at least two people interested in this

<jimsch> markw: does not see this is a big concern to the web security model like ryan

<jimsch> ... want to have a guarentee to a key in the future after it was imported

<rsleevi> To be clear, the point of disagreement with Mark's slides is at what point in time the executing Javascript is compromised

<rsleevi> It provides the same "going forward" protection

<rsleevi> The question is whether it provides protection *when* compromised

<markw> @rsleevi: look at the length of the grey arrows on slides 4 and five and imagine the timescale is the same - it's not the same guarantee

<markw> virginie: ryan, do you have something to propose on import/export ?

<markw> rsleevi: waiting for resolution of how these should behave, specifically as related to extractability

<markw> @rsleevi: the point of extractability is that it introduces the possibility that you can have compromised Javascript without compromised keys. Without extractability compromised js => compromised keys

<markw> jimsch: JOSE currently shooting to enter last call around next IETF meeting in November

<markw> ... have conf calls scheduled between now and then to work through the remaining issues

<markw> virginie: any other topics ?

<rsleevi> @markw: Again on the point in time discussion. compromised Javascript = all operations performed during compromise are suspect. That would include wrap/unwrap, as much as encrypt/decrypt/etc.

<markw> all: <silence>

<markw> virginie: have blogged about progress on WebCrypto and there were many hits/links

<markw> wseltzer: thanks - if you want to link to blog post from W3C site we can arrange that

<markw> virginie: thank you. Not sure how much progress we made. Next meeting in two weeks.

<markw> ... meeting adjourned

<markw> trackbot, make minutes

<trackbot> Sorry, markw, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<wseltzer> trackbot, end teleconf

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/arus/arun./
FAILED: s/arus/arun/
Succeeded: s/???/jimsch/
Found ScribeNick: markw
Found ScribeNick: markw_
WARNING: No scribe lines found matching ScribeNick pattern: <markw_> ...
Inferring Scribes: markw, markw_

WARNING: 1 scribe lines found (out of 286 total lines.)
Are you sure you specified a correct ScribeNick?

Scribes: markw, markw_
ScribeNicks: markw, markw_
Default Present: Virginie_Galindo, kodonog, Wendy, +1.857.928.aaaa, Joanne, jimsch, nvdbleek, selfissued, +1.857.445.aabb, Karen, MichaelH, ddahl, +1.415.294.aacc, rsleevi, markw_, arunranga, ericroman, [Microsoft], israelh, [GVoice], eroman
Present: Virginie_Galindo kodonog Wendy +1.857.928.aaaa Joanne jimsch nvdbleek selfissued +1.857.445.aabb Karen MichaelH ddahl +1.415.294.aacc rsleevi markw_ arunranga ericroman [Microsoft] israelh [GVoice] eroman
Found Date: 19 Aug 2013
Guessing minutes URL: http://www.w3.org/2013/08/19-crypto-minutes.html
People with action items: