Web Cryptography Working Group Teleconference -- 02 Nov 2012

<trackbot> Date: 02 November 2012

<rsleevi> angeda+ Korean use case demo

<rbarnes> bonjour!

Agenda bashing and review

<rsleevi> scribe: Ryan_Sleevi

<rsleevi> scribenick: rsleevi

Reviewing http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012

High level API

virginie: Lots of different views on what "high level" means, depending on peoples' backgrounds
... need to come to a common definition/understanding of what a high level API means

ddahl: Demo'd an API called DOMCrypt at TPAC last year
... wanted to put well-designed crypto in the hands of people who don't know crypto
... talking to Brendan Eich, mentioned "You're handing people a gun, a footgun"
... high level, low level, both still fairly dangerous
... even a low level API tends to be an API wrapped in an API wrapped in an API wrapped in an API
... question as to whether the original API was low level or high-level

[ ddahl presenting an IDL ]

ddahl: always wanted something high level
... looking over feedback from community, lots of people asking "Where is the new crypto? The webby crypto? The API for web developers"
... the low-level API is not necessarily that, very difficult to approach if not versed in crypto
... lots of time going back and forth with rsleevi on outlets like hacker news engaging community
... discussions with other Mozilla people, "no reason you cant do both" - a high level and low level
... take something that just has a few methods, use JOSE for all inputs and outputs
... hopefully end up with something that's pretty easy to use
... very little choices for developers
... will not suffice for most use cases in this group
... but will give developers of new applications good crypto
... no concerns for legacy/backwards compatibility
... entirely domain bound (same origin policy)
... methods such as "encryptAndSign" or "verifyAndDecrypt"
... keys are mostly pairs, identified by an id
... mostly event driven

[ demo-ing example JS for this API ]

ddahl: The whole concept is to make it as idiot proof as possible
... sort of an introductory concept
... want to investigate looking at perhaps two tracks

virginie: Is it too early for technical details and discussion?
... WG needs to decide if it wants to engage/work on this
... question is whether WG feels it will detract from work on low-level API
... do we need to re-design proposal, now that we have a proposal, based on use cases?
... want to get comments in that sense

mountie: when we look at the documents in the WG, we can see the secondary features
... and high level API is in secondary
... some interest in high-level APIs, but some interest in other secondary features
... wasn't sure the distinction between secondary features and if they were part of the high level API
... current JS mechanism is not ideal for non-unicode encoding (eg: shift-jis)
... how will encrypt work and concerns about page encodings

selfissued: To the extent of a high level, we should make sure not to go create new formats
... if we do something at the high level, we should look at produce and consuming JOSE data formats

ddahl: Sort of thought JOSE was assumed here

selfissued: Would be important to state it in the proposal

ddahl: The work going on in JOSE paves the way for this

selfissued: Curious why all APIs use public keys, but not symmetric keys

ddahl: Not designed yet

rsleevi: Existing platform APIs tend to be just two APIs (protect and unprotect)
... mentioned OS X Keychain APIs, windows DPAPI
... wanting to understand the design rationale for this API (encryptAndSign/decryptAndVerify) as opposed to something called just "box" and "unbox"

ddahl: Not a full proposal yet. Possibly still not high-level enough. Considered "box" and "unbox"

hhalpin: clarification: high-level and low-level API are different than the primary/secondary features
... That is, high-level API does not necessarily mean secondary features
... concerned that we're still not down with the low-level API that covers all the primary features
... spending 3-4 months discussing high-level API, that's 3-4 months less spent discussing low-level API
... on a scheduling level, there's 2-3 important questions
... Do we have enough time?
... Do we have agreement on a draft?
... Do we have agreement on what a high-level API should be?
... If we do have time, and we should do it, do we do it as one draft put out in time for our next heartbeat publication, or do we do it after we've published a new low-level API
... Do you (ddahl) feel confident enough that you can put it into a draft quickly

ddahl: Not quite happy with the API as being proposed. Other APIs we can crib from (mention Nacl's box/unbox).
... Think we can come up with something quickly, using JOSE for formats
... as far opinions about scheduling, switching contexts, etc, would want more opinions from WG
... personally holding out for a high-level API
... trying to integrate and address feedback/criticism from public

drogers: I think there is an argument for the API
... discussing recent papers/security research that came out in the past few weeks regarding crypto being hard
... that APIs are technically correct, but combined in misimplemented ways
... then when trying to fix the implementation, people make it worse
... Can we as a WG make things easier/safer - default safe even

<wseltzer> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

drogersuk: Convinced me we need to do something easier for people

mountie: thinks we need three tracks
... low level for primary features, low level for secondary features, high level
... concerned that secondary features have more priority than high level API
... can one single high-level API cover multiple operations that would be safe?
... normally designing web applications/services has some sort of sequence of operations
... one single high level API can remove some common mistakes
... but need secondary features

selfissued: the value of a draft high-level API using JOSE formats is currently JOSE formats are malleable
... to the extent that developing an API and using them, discovering that there is a difficulty or mismatch, we can course correct work in JOSE and this WG
... if we make a mistake in either group (JOSE, here), we can fix them if we do it sooner than later
... that said, make it a separate work item from the low level spec
... completely distinct from the low-level API
... with possibly a different set of editors

rbarnes: chiming in, +1 to the davids (drogersuk, ddahl) and mike (selfissued)
... good that it can remove a lot of rope from the API
... question about choosing a lot of defaults for people
... is there a way to take concepts of smoothing out some of the bumps that can make the low-level API easier to use, like the high-level API seems to be

virginie: What were the actual use cases that you think the current high-level API can address?
... what is the story for this API?

ddahl: solves the sort of chat/messaging use case
... solves document storage in the cloud
... not trusting the server
... local storage/encryption

<hhalpin> Should do a straw-poll just to see how many people "want to add this work-package?"

ddahl: personally would use it for conceptual ideas like "never use email", replacing it with a completely webby toolkit

virginie: How does key exchange work in this API if key exchange is out of scope
... people want "one click crypto", where negotiation is part of the API

ddahl: keyex is out of scope, but other APIs may be possible

rsleevi: this API doesn't really work if you don't trust the server (eg: doc ex)
... So what's the security properties here

ddahl: it does somewhat, like if you put encrypted data on a server, and that server is seized, the data is still sitting on the server in an unopenable state
... Chief use case is messaging
... Messaging has won the web. email is dying. This can fit in with that

hhalpin: Given that there's a lot of prior work with high-level APIs, it should be possible to create a spreadsheet comparing other high-level APIs
... eg: keyczar, sjcl, nacl
... real question is given the amount of work needed on the low level API, does this WG want to take on the low-level API
... originally during the WG, we did a survey from the community re: high-level vs low-level API, WG said low-level API
... PROPOSAL: straw-poll in the WG as to whether we should adopt this in the WG

ddahl: Traditionally in DOM APIs, we start off with something low-level, then abstract it higher (eg: DOM -> jQuery)
... it feels to me that now that we've experimented with some of the low-level API, it might be a quicker win to get something to market by doing something very high level

<hhalpin> Note that I would like the straw poll!

rbarnes: Back to use cases/stories, the upside of having all the prior art is that we can choose what variety of things we want to support
... think it should be possible to support a variety of use cases with a high level API
... thinks losing configuration/key management operations may not be a bad thing
... thinks its an 80/20% problem, and 80% of problems can be addressed by the high-level

<hhalpin> \me the real question is what is the crypto API for the 99% :)

rbarnes: seems like there is energy in the room to work on the high level

cjkula: not sure if high-level wrappers (ala jquery) can provide the same assurances that implementing in the browser

opoto: If the entire high-level API can be implemented in JS using the low-level API, why should we standardize the high-level API?
... looking at DOM vs jQuery - there have been many high-level APIs adopted in the market (besides jQuery) depending on the use case
... built on the common DOM/low-level API
... maybe this will be the case for crypto to - there will be several high-level APIs based on different domains/use cases
... should this WG impose just one?
... not convinced about imposing a single high-level API

mountie: David's proposal is different that what I expected
... many Korean users expected high-level API to touch on secondary features
... for these types of high-level APIs, there are so many other developers, let other teams (like jQuery team) develop them
... and we can propose low-level APIs, like secondary features

markw: It would be a good thing if people implemented JOSE libraries implemented atop low-level API
... good if there were multiple of those, perhaps as student projects
... help work out JOSE issues, help prove out the low level API
... but it might be too early to jump into standardizing a JOSE library
... JOSE library may not be that complex to implement in JS
... wouldn't want this group to be distracted from getting the low level API to work
... want to make sure you really have users and implementors really driving for that work
... which there is for the low-level API

tlr: Confused by this discussion
... considering this charter discusses where the high-level API sits
... discussion here rehashes the chartering discussions
... need to decide if the WG can't meet the chartered goal, and perhaps have a chartering discussion
... a bit uncomfortable with where this discussion is going w/r/t charter

selfissued: response to markw's comments
... I think there's value in prototyping an API that uses JOSE
... proves out JOSE, proves out the low-level API
... sympathetic to mark's comments regarding whether it's time to standardize
... can easily publish a draft leaving open a timeframe as to when it actually becomes a standard
... building an end-to-end implementation is one of the more valuable things we can do

markw: Agree that it's good to implement, but not within this group
... people can implement and bring their feedback to the group
... but don't start standardizing yet

virginie: many opinions within the group
... Who is interested in this work?
... How will it be worked on? Seems consensus for secondary doc
... seems like no one is opposing this work
... various questions to work out if this group decides to work on a high level API

<hhalpin> PROPOSAL: Should the Working Group engage with a higher-level API as demonstrated by ddahl?

<ddahl> +1

<hhalpin> +1

<selfissued> +1

<drogersuk> +1

<cjkula> +1

<wseltzer> [Charter: The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications. "]

<sangrae> +1

<mountie> -1

<opoto> +1

<rbarnes> +1

<wseltzer> +1

<wtc> +1

http://www.w3.org/2011/11/webcryptography-charter.html

<hhalpin> PROPOSAL: Who would volunteer to work on the higher-level API as a deliverable?

<ddahl> +1

<rbarnes> +1

<selfissued> +1

virginie: Sounds like this can be done separate from the main WG, perhaps on a different dedicated call
... would really like it to be clear what the use cases and operations that this high-level will help

<hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group contigent on the activity level of those in the WG who volunteer for this task

<hhalpin> Any objections?

drogersuk: Doesn't a high-level API go against our charter?

[ laughter ]

<drogersuk> @rsleevi that's not what I said

hhalpin: Discussing the history of proposal as it stands vs low-level API during chartering

<drogersuk> the proposal as it stands goes against the charter

<hhalpin> To be more clear, I don't want this proposal to be interpreted as the "high-level" API taking priority for the entire WG over the lower-level API

virginie: If you say a high level API shouldn't disturb a low-level API, you can't force that. It's contribution driven. If ddahl focuses on a high-level API, that can affect the low-level API

<hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group that does not stop the low-level API

tlr: concerned about this WG working on two docs - market confusion, confusion within the group, confusion about the charter

<hhalpin> We could say "PROPOSAL: The Web Crytpo WG adds a high-level API as a Rec-track deliverable to the working group, and the WG does not stop work on its a current Rec-track API"

markw: Netflix's position was always that what the charter calls for is what the WG is working on now (the LG)
... So whether it's called high level or low level, it needs to support the cases in the charter

drogersuk: Concern is not high-level vs low-level, but is it usable?

rbarnes: I'm not convinced at this point that there's actually separate documents, but the proposal implies it

virginie: Even if we've triggered some negative remarks with our low-level API, there are still people very interested in the low level API, so we should not abandon this work

<hhalpin> I was not answering the question of whether its one Rec-track document or two quite yet until we get the drafts further along.

virginie: Important to have it done as two separate efforts, so that we don't have a dependency between the two. We may merge them later

rbarnes: In agreement that this is mostly a usability concern

<hhalpin> virginie, perhaps re-open queue

<virginie> yeap

rbarnes: Proposes simplifying the low-level API

[ 10 minute break ]

virginie: in terms of priority, main priority stays low-level API
... virginie and tlr to work on messaging and ensuring its consistent
... high level API is worked on by a separate group in parallel

cjkula: It didn't seem to me that we didn't say we were never doing a high level API
... just that we had to focus on the low-level primitives we needed in order to enable a high level API

virginie: We never made a decision to close discussion on high-level API

selfissued: Actually, we just closed that issue

hhalpin: When we started with DOMCrypt, it became clear in a few calls that most of the use cases would not be satisfied with DOMCrypt
... put out several proposals on IRC, didn't really get closure on

<virginie> http://www.w3.org/2012/webcrypto/track/issues/7

ISSUE-7?

<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/7

<virginie> issue 7 is related to do we work or not on high level api

hhalpin: regarding usability, there are sort of two different APIs going on within the cryptographic space

rbarnes: The distinction for me is APIs that deal on octets and APIs that deal on data structures
... there seems to be a bright line and we need to decide where we sit
... on one hand, getting the octet based API is key, but it needs to be simple
... current API is octets and not simple

<hhalpin> PROPOSAL: The Web Crypto WG adds a higher-level API as a Rec-track deliverable to the working group but does not stop the WG work on the current API

rbarnes: david's proposal is simple and not octets
... we perhaps need something different

tlr: What I hear is there are a set of use cases that correspond to a set of use cases that are on the low level API
... things like OpenPGP, thinks those are distinctly not in the charter
... hears use cases like what rbarnes said, I want to box something, ship it up to a web app, send it to another server, unbox it, not have to worry about it
... so what is the correct understanding of the high-level API?

pal: What are the implications of adding something to Rec-Track in the context of the existing work?

<hhalpin> its really a matter of exposing parameters as well, not just operating on octets.

pal: Does it make that work contingent upon this work?

virginie: no

ddahl: When we talk about high-level/low-level, I think we need to still have more discussion on what the distinction between them
... What I'm thinking of when we talk high-level, I'm thinking only consumes JOSE, or higher, and has little configuration
... Has only two to four methods

virginie: The task of the contributors will be to explain the differences clearly

hhalpin: There were some use cases that we thought we could with high level
... but after looking at the use cases we had, it was clear they could only be accomplished with something lower level
... it seemed that most of the use cases were actually motivated by exposing configuration options and details
... it sounds plausible when you first think about it, that a high level API can solve all the problems
... but it actually wasn't the case
... high level API hides the configuration details, which intuitively seems good, but its not clear yet what use cases it identifies

tlr: It's important that everyone in the group has a shared mental model for this work

rsleevi: We need to have an understanding as to what *is* a high level API
... would like those who want to work on a high level API to actually put a proposal forward to make it clear what they think a high level API is

ddahl: I never intended DOMCrypt to address all the use cases. Just those use cases related to messaging

<hhalpin> PROPOSAL: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API

<hhalpin> Any objections?

<ddahl> +1

<mountie> +1

<sangrae> +1

<wtc> +1

<selfissued> +1

<JonathanJ1> +1

<cjkula> +1

<hhalpin> +1

<opoto> +1

<hhalpin> You can abstain explicitly Markw

<hhalpin> RESOLUTION: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API

<hhalpin> ACTION: ddahl (and others) to bring back functions and a draft WebIDL for the higher-level API [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action01]

<trackbot> Created ACTION-62 - (and others) to bring back functions and a draft WebIDL for the higher-level API [on David Dahl - due 2012-11-09].

<hhalpin> ACTION: virginie and tlr to handle any concerns from public and communications about WG's work [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action02]

<trackbot> Created ACTION-63 - And tlr to handle any concerns from public and communications about WG's work [on Virginie GALINDO - due 2012-11-09].

<wseltzer> [break]

<wtc> scribenick wtc

<wtc> Zakim: scribenick: wtc

<wtc> markw: the discussion of ISSUE-25 will start at 11:30

<wtc> virginie: I suggest we discuss the security framework during the 20 minutes before 11:30.

<wtc> ... we have been discussing the security assets that are coming together with our API.

security framework

<wtc> ... Security Framework: building a common understanding on what the Web Crypto API brings to the web security

<wtc> virginie: received questions about the actual value of our API after the FPWD was published.

<wtc> ... (goes over the slides of the presentation)

<wtc> ... security features of the API is left to UA know how. Crypto capabilities rely on OS capabilities.

<wtc> ... Web app quality evaluation is left to the user. The actual security of the API is left to implementers know how.

<wtc> ... such as: *integrity of the API, *local storage protection (TPM, secure elements, etc.), *WebApp identification/execution

<wtc> ... The value of our deliverable is: * standardizing the functional behavior of crypto operations, * help developers use the crypto operations correctly, * include the features of secure elements in the API (an controversial issue).

<wtc> virginie: I pose two questions to the working group:

<wtc> ... 1. why not writing down this value propositon? 2. can we make it better?

<wtc> virginie: any questions?

<drogersuk> http://w3cmemes.tumblr.com/image/34766205708

<wtc> hhalpin: we should have stated up front this is an API that adds new capacity to web apps but doesn't changes the security aspects.

<wtc> ... it might be useful to add a few brief sentences to clclarify that. We seem to have done that.

<wtc> hhalpin: this should be in the first paragraph or even the abstract, not in section 5.

<hhalpin> Well, what I was suggesting to be exact was that we have a *very* brief mention of these in the intro and status parts of the API, and then point people to the Security Considerations in Section 5.

<wtc> rbarnes: I agree we should have a forward reference of the security considerations at the beginning of the API spec.

<wtc> scribenick: wtc

markw: would be useful to enumerate the security models relevant to this API.
... there are models that have different levels of trust for the user agent and the JavaScript code.

<rsleevi> ISSUE-21?

<trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/21

mountie: for ISSUE-21: content-security policy
... Tobie of Facebook talked about the protection of JavaScript code yesterday.
... It is our role to suggest a solution for the integrity of JS code.

hhalpin: a question for tlr: we need one or two sentences at the beginning.
... Is there a document from the WebAppSec group that we can point to?

tlr: I think it's useful to describe the security models and how our API behaves in the security models.

drogersuk: the security and threat models, we have to decide which are in scope.
... the dependency on the work of the WebAppSec WG -- should we iterate...

<hhalpin> To be clear, I was suggesting that we work on this document *with* WebAppSec WG if they already have a document they are working on. The other option is for us to try to work on that document by ourselves.

virginie: if we have an internal document describing the security models we have in mind, with someone editing it, then we can have a liaison with the WebAppSec WG.

drogersuk: 1. we have to make it clear we have a direct dependency on the security and threat models.
... 2. We need to say "security and threat" model, not just security model.

virginie: who would like to lead that? drogersuk?

drogersuk: I'd be happy to help. I won't be able to commit until January.

virginie: can you come up with a description of the security and threat model for this WG, that would be helpful.

tlr: WebAppSec doesn't usually work on crypto issues.

drogersuk: how do you think the liaison between our WG and WebAppSec WG would work?

rbarnes: the easiest thing to do would be draft up some text and take it to the WebAppSec WG.

hhadlpin: most of the reviewers were looking for security considerations for "users".

rsleevi: there are no real differences in security considerations for this API and, say, full screen mode.

<virginie> Security considerations in the spec http://www.w3.org/2012/webcrypto/track/actions/55 and http://www.w3.org/2012/webcrypto/track/actions/52

<virginie> some actions that may answer harry expectation from the spec

rsleevi: my view as an implenter is there is no fundamental difference between this API and storing keys in the local storage.
... there is nothing special.

<pal> time check

rsleevi: if you need constant-time crypto operations, then this can best be provided by our API. This is why the security considerations focus on developers.

drogersuk: when people hear crypto, people expect security.

virginie: next topic is ISSUE-25: Global Unique ID for pre-provisionned symetric keys

<rsleevi> ISSUE-25?

<trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/25

<hhalpin> ACTION: drogersuk to draft security and threat model for WebCrypto API given considerations of Web Application Security Model [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action03]

<trackbot> Sorry, couldn't find drogersuk. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

virginie: ACTION-17 is associated.

Global Unique Identifiers

virginie: markw provided a proposal on Oct. 29.

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html

markw: we had an action item to propose global unique IDs for pre-provision keys.
... if you need to use a pre-provisioned key, you need an identifier on the server side to look up the symmetric key.
... we want a common way for TV manufacturers for pre-provisioned symmetric keys.
... we are interested in origin-specific pre-provisioned keys.
... if user agents need pre-provisions keys for different origins, those should be different keys.
... I suggested deleting the text about suggeting deriving keys from a master key.
... the main part of the proposal is the designate a property, "uid" for pre-provisioned symmetric keys.
... rsleevi suggested we should specify the properties of the "uid" property.
... the proposal s http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html

ddahl: is this property optional?

markw: yes, it has to be optional.
... depends on the aplications whether they want to provide it.

ddahl: I have seen specs with optional items like this that caused problems.

rsleevi: my concern has been this optional attrbute will never be implementable in desktop browsers (as opposed to TVs or devices).
... I wonder how much of this has to be specified, and how much of this should be left to the video streaming industry and the device vendors.

pal: what does an "optional" unique identifier mean?

rsleevi: there are ways to uniquely identify a symmetric key.
... my concern is as an implementer, if I read the spec, I don't know if I need to implement it.

markw: the spec is http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html

virginie: do you see any means to make it better?

<markw> http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html

markw: correction: the proposal is http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html
... this clarifies what the identifier would look like.
... some text characterizing the global unique identifier.

<markw> The second email is extended text to be added to the first

hhalpin: there are two options we have. It's clear not all implementers are going to implement "uid". The issue is where to put it in the spec.
... option 1: in the spec, but mark as optional. option 2: not specified in the spec.

markw: putting in the spec will save some messy code that needs to be written by developers (if different vendors use different properties).

rsleevi: putting it in the spec won't resolve the ambiguity to the implementors.
... I don't know how consistent this will be.
... I don't know if we have enough people with the right background to know if this is the right global unique identifier to standardize.

pal: assigning a unique identifier to a key is not an exceptional thing.
... if the semantics of the id is the id shall be unique, then it's up to the provider of the id to make sure it is global. I don't see the downside of specifying an optional uid attribute.

hhalpin: what we need to decide is whether to put this in "extra attributes" or as an (optional) first-class attribute.
... is there any other member of the WG, besides Netflix, who would like to use "uid"?

markw: I just need to standardize the attribute's name and semantics. It is fine to us for it to be in the "extra attributes".

<hhalpin> so just to clarify, its part of "extra" in 10.2

<hhalpin> thus, it should be clear to implementers that its optional, but we need some more text around "extra"

markw: we (Netflix) would be implementing the user side of it...
... the Web Crypto API will be on our list of web/HTML technologies for device manufacturers.

virginie: speaking as Gemalto, I see some value of this feature.
... speaking as the chair, I see there is a "market" probem, but not a technical problem.

<markw> I suggest we ask the Web & TV Interest group for opinions on whether the proposal meets the requirements they have raised earlier in the week

virginie: The market problem: markw should make it clear it's the market, not just Netflix, that is interested in it.

pal: it's clear there is interested in this feature.
... I am interested in understanding whether there are technical challenges for implementing global unique identifiers.

rsleevi: we have several members of the WG who have participated in the WG since the beginning, and the features they want are not yet in the current API spec.
... the technical challenge is "you know it when you see it"...
... in addition, pre-provisioned keys have different security attributes than "browser-mediated" keys.
... there are some user tracking issues with the global unique identifiers. These have to be considered.
... we should focus on features that improve the security of the current state of "JS crypto" on the web...

markw: if we have to drop features, we should drop features that don't have a proposal.

drogersuk: the tracking aspect...
... maybe we need to think about it more and rewrite it.

pal: thank you (rsleevi) for pointing out the issues.
... if there is interest in a global id, it will help interoperabilty...

hhalpin: we should write a proposal.
... it's clear the focus is on a uid attribute, minus the certificate aspect.
... as long as it's clearly labeled as "extra", it should not confuse implementers. This is one proposal.
... the other proposal is to continue discussion until the proposal is worked out ...

rsleevi: I am concerned about how fast we can find consensus on a minimum set of features.

drogersuk: we can't let this descend into the debate of PCs vs. other devices.

selfissued: since markw has done the work of writing up a concrete proposal for their use case, it would be good for the working group to consider his proposal...if it meets the editors' requirements...

<hhalpin> PROPOSAL: Accept Netflix's proposal for a uid under "extra" minus the certificate aspect, as long as the technical details are worked out to the editor's satisfaction

<npdoty> scribenick: npdoty

virginie: we are here just to provide an API
... slide with members of the WG, 53 participants
... 10 to 20 people on a weekly conference call
... 11 invited experts too
... deliverables: Web Crypto API, currently in FPWD
... wiki list of use cases, which maybe will move to an actual specification
... have started to discuss security
... a "high level api", an abstraction
... Use Cases for Web Crypto
... client confirming the integrity of data, p2p communication, protected storage (local or remote)
... just a wiki page at the moment, clear among the WG but want to formalize
... Web Crypto API
... great job by the editors, Ryan and David
... generate, import, export, encrypt, decrypt, sign, verify, digest, rng
... recommended set of algorithms, but not mandatory
... 30 issues at the moment

<odinho_> i/scribenick: npdoty/Topic: Joint meeting, Crypto and WebAppSec

virginie: would like reviews from WebAppSec
... possible collaboration with WebAppSec
... received some comments that this is a dangerous API because it requires expertise, because JS is not secure, because.....
... decide explicitly the value of this API, write down which security problems we are responsible for and what we are not
... the "API value proposition"
... could collaborate because you know the state of the art of web security
... links! [help the scribe by dropping them in please]

<sgodard> slide links please ?

bhill2: can introduce the scope of webappsec work....

<virginie> Our main page http://www.w3.org/2012/webcrypto/

<virginie> Our wiki http://www.w3.org/2012/webcrypto/wiki/Main_Page

bhill2: three deliverables that may have some to little relevance for what crypto is doing

<virginie> Our mailing list http://lists.w3.org/Archives/Public/public-webcrypto/

bhill2: least to most relevant:
... 1) clickjacking vulnerabilities and secure mashups across origins, embedding iframes and other content
... confusing user interface, breaking the visual integrity of a page when it's embedded
... nothing cryptographic in the response, more about heuristics and comparing visual images
... richer than today's X-Frame-Options header
... a policy model with a feedback channel, more fine-grained, to enable integrated mashup applications currently considered unsafe
... 2) content security policy, about to go to CR next week
... reducing the attack surface of applications to injection vulnerabilities, like XSS
... voluntarily declare a more-restrictive least privilege environment, limit which origins are allowed for embedding images, scripts
... be able to white-list the origin of external content
... in 1.1 of CSP, discussing only inline script blocks that match to a hash or similar; may be comparable to signed applications
... start with the assumption that the DOM environment is untrusted, so would probably want cryptographic enforcement to be done in the user agent rather than in the DOM itself

ekr: +1

bhill2: so I'm not sure those elements would be consumers of a DOM-based crypto API
... but if you were producing formats for cryptographic signatures over a block of JavaScript, that could be a reference or joint work with webappsec
... what's the format of the thing you're going to sign?
... 3) cross-origin resource sharing (CORS)
... xhr between domains in a more secure fashion
... allow for permission-relaxing by a resource declaring that it can be accessed more permissively across different origins
... developers may be interested in applying different security services for resources that were fetched from a cross-origin request
... always recommend in security considerations that you do some verification of the content that is retrieved
... for data that wasn't confidential but needed to have integrity
... an area where developers would be most interested in using the two groups' work in concert
... what's the canonical format for signatures of content?
... going to be re-chartering soon, contemplating deliverables around link fingerprinting/hashing -- an attribute of an HTML tag/URI including a hash/fingerprint of a resource
... could include large javascript libraries or other blobs and verify that they haven't changed
... I want to load this analytics javascript from a 3rd-party site, but want to make sure it's a particular version that I've code reviewed
... don't want my site to be compromised when the 3rd-party host has been compromised
... regarding performance, can more effectively use CDNs and other types of caching
... just in the strawman idea phase for a possible charter
... overlap with this group in delivering signed objects

odinho_: XHR is a common use of CORS, btw. img feth for use in canvas, eventsource, track element/video, fonts etc are other uses as well :)

bhill2: csp going to CR next week; CORS is hoping to go to PR once we have test suites to prove that interoperable implementations are ready
... hoping to go to Rec in the next 4 to 6 months
... clickjacking to go to Rec in the next 12 to 18 months, depending on implementations
... csp will probably be at fpwd later this month, maybe Feb 2014 for Rec
... rechartering, not sure whether the new deliverable (link fingerprinting) will spark controversy
... ~3 month process
... expect that would be a one year time frame, to Rec around Feb 2014

@@: any approach if the user environment is compromised?

<rsleevi> s/@@/mountie/

bhill2: minimize the impact of injection vulnerabilities by setting a strong least-privilege policy
... prevent some of the cases where reflected vulnerabilities will turn into active content
... everything is only best effort, resource owners won't know how much the user agent has implemented
... just prevent the execution of content
... a defense in depth measure to reduce attack surface and privileges of resource, so that the damage is limited when compromises happen

virginie: you have a long section in your spec to limit your own liabilities?

bhill2: yes. I think it's not our group's purpose to tell the Web platform what it should/should not do
... security can't just be on the server side any more, our group was chartered with the idea that applications are full-fledged and need security capabilities on the user agent side
... in fact, the UA is the only place where some of these defenses can be built
... we are working on the same assumption that the web app is a first-class citizen

@@@: we all assume that the features will be there and that developers will screw them up <laughter>

hhalpin: when we asked for public feedback, we got feedback on the nature of our algorithms, but also got less helpful feedback via twitter

<rsleevi> s/@@@/Ryan_Ware/

<ware> s/@@@/ware/

<bhill2> http://www.w3.org/2001/tag/2011/02/security-web.html

hhalpin: still trying to clarify our high-level view of what our purpose is, drogersuk volunteered to edit
... might be interesting joint work between our two groups (since CSP also has specific limited scope)
... 2) link-fingerprinting is similar to a request from tobie about storing resources in local storage to prevent constant reloading over the network
... 3) both want feedback from the crypto community, the security community and from the web app developer community
... how can we get an adequate level of review that we're not sure that we have that you have received?

bhill2: document from the TAG, presented by larry masinter, as an input document
... what are the security properties of the Web and what is the history of the model
... might have more bandwidth available to pick up these non-normative and definitional documents
... maybe something I should include in our rechartering discussions
... room for joint work with web crypto
... architecture documents that don't exist, like documenting what is CSRF
... would be nice to have a real, peer-reviewed explanation rather than just pointing to (in the academic fashion) the first instance, which might just be a short blog post

[scribe not following this response]

bhill2: the hard part is canonicalizing the boundaries of signing

mike: JOSE specifically takes the position that no canonicalization will occur, just base64 everything including white space, so you can sign or encrypt anything without canonicalization

<DanD> +q

<hhalpin> I believe bhill2 said that "Yes, there are a lot of use-cases for integrity checks on content, but the problem is not API-level but on the level of the boundaries of said object in its context in the DOM"

bhill2: not sure that works for everything that looks like an HTTP resource
... might care about more than just the body of the resource, including headers that affect the security properties

mike: if you're signing a structured thing you still have to solve the problem

bhill2: while I'm an advocate of "don't canonicalize, just sign the byte stream", I don't know if that will work here

mountie: which vendor is working as an implementer? @@@@

bhill2: lots of implementations of CORS even in niche mobile browsers; CSP has both a Chrome and Firefox implementation; partial implementation of sandbox features by IE
... Opera is a member, complete implementation of CORS, not sure about the other features
... user interface safety built in a firefox plugin, and willingness to build in

rsleevi: opportunities for more overlap; within our current spec we're not addressing the "key" security concerns
... things that you cannot consistently implement in a JS environment
... but key security is critical in understanding the security model
... using origin-based security for keys -- good because it's a consistent model
... but potentially grants an entire origin the possibility to execute operations with keys
... could use a path-based model like in cookies, or expiration

<tlr> relevant: http://w2spconf.com/2008/papers/s2p1.pdf

<hhalpin> Perhaps we should list our WebAppSec related issues

rsleevi: a similar concern (to CSRF) is going to exist with keys which are used to authenticate a particular request
... if an app can perform a key operation, it might have the same technical effect as sending a particular cookie through

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/21 Requiring Content-Security-Policy

bhill2: we are chartered to do joint work with the ietf websec working group

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/26

<hhalpin> Should key generation be allowed to specify multi-origin shared access

bhill2: justifying why CORS isn't making it worse, and writing up a non-normative document explaining why would be helpful
... purview of the ietf websec group, with which you might want to have more formal liaisons
... certainly willing to provide security reviews

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/33: arify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario

bhill2: finer-grained origins probably a bad bad idea
... header that specifies which resources shouldn't be given access to the crypto (resources that are user-generated or somesuch)
... send an email to our group's list documenting those use cases
... something we're willing to consider

drogersuk: volunteered to build the threat/security model
... based on the general feedback, developers see this inherent link between crypto and security
... we have a direct dependency on the security model of the Web
... should clearly map that out for some of our detractors to be able to answer them quickly
... understand our level of robustness
... can make a meaningful statement about what threat models we're protecting against
... protecting media content vs. protecting dissidents in hostile countries, vastly different use cases

DanD: <shepazu/villager joke>
... Web security for dummies documentation could be in the WebPlatform docs

<tlr> very good point

DanD: currently have just a stub, but we could have a lot of hierarchical documentation there

<drogersuk> +1 to Dan's points

DanD: that's where you could document the threats

npd: +1, and we've talked about that as a place for documenting privacy practices for Web developers as well

shepazu: like a11y, like i18n, should be documented across
... happy to work with anybody to help make that a reality

hhalpin: would be good to get an opinion on these currently open issues so we can close them

issue-21?

<trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/21

hhalpin: different opinions on these, is this orthogonal? is this something we need to guide implementers on?

issue-26?

<trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/26

issue-33?

<trackbot> ISSUE-33 -- Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/33

hhalpin: should we have some multi-origin key generation?
... need to decide that at some point in the next year; could use feedback on

<hhalpin> opinion on these issues in IRC would be great even

virginie: can collaborate on our api security value
... use cases on signing of javascript
... review respective specs

<hhalpin> since the first is clearly related to how to do security considerations in general, even though it calls out CSP in particular

virginie: come to each other's groups regularly

<hhalpin> the second two are of course similar to issues brought up by CORS

virginie: ask for feedback on specific issues
... at least we now know each other

<mountie> http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u

WebCrypto API & Korea

<wseltzer> ScribeNick: wseltzer

mountie: showing http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u
... credit card processing as common in Korea, using certificate previously issued to browser
... [screenshots: certificate, plug-in, user selects bank, enters info]
... [UI for national certificate-related plugins; user enters password]
... activeX plugin for Korean national government tax website; visit site, requests to install plugin
... user clicks yes, next login attempt, another plugin requests to install
... loading time about 3min30
... [video showing website: http://www.hometax.go.kr/]

selfissued: accepting an activeX control

mountie: another provider's plugin
... now, no more plugins required, users enter ID and password
... user gets requested to reboot os, then finally successfully logs in
... showing digital certificate stored in the user's environment; issued based on face-to-face verification at bank branch
... stored in smart card or @@
... users are educated to "yes" on all plugins, became a national security hole
... IE about 65%, so only 65% of users can make payments using this binary plugin

selfissued: plugins don't work in other browsers?

mountie: mostly, no
... plus, metroUI doesn't allow any plugins
... regulations force the use of binary plugins . EFTA, Consumer Protection Act, Privacy...

[slide: technical requirements by regulations]

mountie: slide shows how requirements currently met by ActiveX could be implemented in JS with WebCrypto
... requirements: identify and authenticate; encrypt transmission; non-repudiation; protect user environment
... on-screen keyboard=mouse-based visual keyboard
... to defeat screen-scrapers, one of the requirements randomizes keys
... [slide: special interests]
... SEED, Korean standard alternative to AES; Certificates

ekr: threat model? who does the certificate validate?
... why do we need validation on the client-side?
... only the browser chrome can check validity, not the JS provided by the site you want to check.

rsleevi: or plugins, SysAPI-level, but not JS

mountie: we want to minimize requests to users to verify

<rsleevi> correction: point was to use SysApps - but not exposed/implemented in content JS

ekr: suggest an additional scoping restriction, to origin *and* national PKI
... if the security property you need is to have browser enforce that signatures in this system are only those from national PKI; JS validating server cert just can't work unless you're in sysapps-installed-apps mode

<ekr> What I would suggest is simply a signature mode which includes trusted attributes over the origin of the JS.

<tlr> ekr, q+?

<ekr> yeah, I guess so. q+

dme

s/dme//

mountie: government is planning to revise regs
... current regs have two tracks: binary plugins and web applications audited by government committee
... second route instigated by iPhone
... 2010 regs changed to allow non-plugin electronic transactions

ddahl: what's being typed in?

mountie: usually a password

ddahl: probably encoded in Korean-language codepage
... also, all these URLs are http. Is there lots of fraud?

mountie: hacking and keylogging is a problem

ekr: it would be useful to describe the threat model and implied security demands, rather than starting from the end of the tentacle as the system is currently designed

<hhalpin> We can check digital signatures with pre-provisioned keys I think.

wseltzer: let's try to understand the problem and its security requirements off-line

rsleevi: we want to help; we don't want to help by implementing insecure "solutions"
... it would be bad if we just tried to implement what exists in CryptoAPI; let's try to find the solution broader than WebCrypto

<tlr> ScribeNick: tlr

mountie: @@

rsleevi: as implementer, something we care a lot about. Would like good solution on technical merits.
... not sure if there's an action item -- there is engagement to be ha
... would like to be sure we can implement or deploy
... maybe an action item to take
... don't think the way things are done today aren't good technically

mountie: don't expect every browser vendor to implement it
... work on alternatives
... if vendors are ever to implement, then that would be beneficial

<hhalpin> its a prezi, so I believe mountie could add the URI to IRC once he has a sec

virginie: still important to understand use case better, then we can understand solution better
... recommended minimum set of algorithms -- not sure that was part of list?
... has to be discussed further

<hhalpin> SEED was not part of the list, I think SEED is in Firefox, but is it in Webkit?

virginie: think it's feasible to at least describe the algorithms you would need
... certificate management is a borderline feature
... signed javascript?

mountie: webappsec?
... want to find out how to allow multi-origin access
... can discuss more

virginie: discussed with Brad Hill about signed JavaScript

<hhalpin> So SEED support is not currently an outstanding issue for at least desktop, but is a problem for mobile rsleevi?

virginie: important question - what are boundaries of code so you sign appropriate information?

<ekr> I don't have a problem with assigning a code point for SEED, but I hardly think it's appropriate to recommend it.

virginie: @@

<rsleevi> hhalpin: Requiring SEED won't work, but I am 100% supportive of specifying how SEED should behave IF a UA implements it

<hhalpin> I guess what I'm trying to figure out is should we add SEED to the API as an option, although not in the minimum required set.

mountie: interesting in JS functions - JS validation, require complex design. How protect js code?

<rbarnes> hhalpin: i didn't know we had a minimum required set

<rsleevi> hhalpin: And I'm saying yes, we should. Mountie has made a proposal to the list to do just that, and I have no objection to it

<ekr> rbarnes: I don't think so.

<rbarnes> in fact, i thought we explicitly said we *weren't* going to have any required algorithms

hhalpin: want to be clear about what can and can't do
... digital signature component might be part of this

rsleevi: web crypto is a component part of any solution that is meaningful to Korean use case

<ekr> seed is an alternative to AES

hhalpin: not quite sure where in the flow seed is at

rsleevi: support adding seed -- any algorithm that is meaningful

<hhalpin> However, would adding SEED actually help this use-case?

rsleevi: there are things that can't be done in JS, but Web Crypto is well positioned to do.

<ekr> ROT13

<hhalpin> We could add SEED as a matter of principle, but having a use-case would help.

<ekr> Actually, we should do triple-ROT13. It's more secure

ekr: no problem adding SEED
... any algorithm that is plausibly defined
... I would have problems with very weak algorithms
... certificate thing- very marginal case for any application I have seen yet
... that brings us down to signed JS -- that belongs in sysapps
... SEED should be optional, not recommended

<ekr> my point is that certificates should be a tertiary feature

<wseltzer> tlr: many countries with similar requirements and similar flaws; opportunity to get together to understand the requirements better

<wseltzer> ... among implementers, country-based participants

<wseltzer> ... window of opportunity to understand this set of markets and their needs

<hhalpin> one way to operationalize this, off the top of my head, would be to detail out the use-case

<wseltzer> ... W3C could help to provide a forum, CG or BG; we'd need help from implementers and contacts

<hhalpin> and then seeing if we need to drag in other WGs from both IETF and W3C

<wseltzer> virginie: Arun compiling use-cases

<wseltzer> rsleevi: as implementers, we've been having these conversations, we think it's important

<wseltzer> ... as far as timing, start with the places API can be ussable now

<hhalpin> and then if that goes through, there's always the possibility of a W3C workshop in the future on this particular topic, not just for Korea but for similar countries

<hhalpin> So I think I am hearing we get an action to add SEED as an option?

yes

<wseltzer> ekr: Certificates are a tertiary feature

<rsleevi> +1

<hhalpin> rsleevi, you happy with an action to add SEED?

<rsleevi> @hhalpin: Yes

<wseltzer> virginie: we'll work on the use cases.

<wseltzer> ... Thank you, mountie

<hhalpin> ACTION: rsleevi to add SEED to WebCrypto API [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action04]

<trackbot> Created ACTION-64 - Add SEED to WebCrypto API [on Ryan Sleevi - due 2012-11-09].

<wseltzer> selfissued: that video looks very complicated. How many Korean users can get through it?

<wseltzer> mountie: Korean users are well-experienced clicking-through

<JonathanJ1> mountie's demo is very normal case in korea.

<wseltzer> rsleevi: there are many moving parts here, we want to get it right

<wseltzer> [break]

<wseltzer> ScribeNick: wseltzer

Wrap Up

virginie: I was planning a summary, but my brain is fried
... take-aways:
... address a few logistics issues

<hhalpin> notes that we also had a request to change meeting times

virginie: next F2F. I'm used to 4x/year, but W3C tends towards less frequent.

rsleevi: I'd suggest East Coast; estark, rbarnes

rbarnes: I could look at Boston options

ddahl: Mozilla Toronto

<rbarnes> … or dc

mountie: We could host in Korea

virginie: Looking at March dates

rbarnes: IETF is March 10-15

[Orlando, Florida]

<hhalpin> March 9-17 is SXSW

virginie: I'll organize a poll for where/when

<hhalpin> We can be flexible, we don't have to meet exactly every 4 months, but a few weeks in or out should be fine

virginie: Next, conference call timing; old action item to look for time that's better for Asian participants
... What about 8AM San Francisco; 11 Boston; 1600 France; midnight Korea

hhalpin: 8 is possible but early for west coast

<hhalpin> It does not sound early but I have noticed last time that I tried to do a WG with this proposal people fell off.

<JonathanJ1> I think we can host next F2F meeting in Seoul.

<JonathanJ1> we were already hosted many W3C WG meeting. DAP WG, Media Annotation, MWBP WG ...

<ddahl> JonathanJ1: yay!

<hhalpin> I think its important people are realistic about their attendance at very late or very early hours

mountie: midnight or 1 am would be possible

<hhalpin> Not just possible, but something that can be done weekly

<hhalpin> I'd like to hear from the rest of the participants outside of Mountie if possible?

virginie: progress. high-level API to come back in one month with timeline
... priority in conference call; low-level API and use-cases; then in one month, change to high-level
... Dec., check status for next working draft

<hhalpin> 3 month heartbeat requirement puts us around new years

virginie: by Christmas we'll need another draft.

mountie: other volunteers in China; midnight better than 1 am

virginie: thanks to the scribes

<ddahl> wseltzer: +1

virginie: next Monday's meeting is canceled
... Next meeting: Nov. 12 at usual time 1900 UTC.

<JonathanJ1> how about make a questionary for next F2F schedule decision ?

virginie: I've noted that on my 25-item action list

thanks to Virginie, Ryan, editors

[applause]

trackbot, end meeting

- DRAFT -

Web Cryptography Working Group Teleconference

02 Nov 2012

Attendees

Contents

Agenda bashing and review

High level API

security framework

Global Unique Identifiers

WebCrypto API & Korea

Wrap Up

Summary of Action Items

Scribe.perl diagnostic output