Web Cryptography Working Group -- 14 May 2012

<Channy> Hi, all. I'm only on IRC because it's 4am in Korea :)

<ddahl> hi Channy - thanks for waking up!

<christopherkula> calling from 510-387-xxxx

<virginie_galindo> hi all, solving few problems of connection with wendy. will be there in a minute

<wseltzer> zakim has been having trouble lately

Web Cryptography Meeting Convened

<scribe> scribe: hhalpin

Introduction

virginie: let's have a quick overview of all the topics we need to address
... and then go over some of the logistics to make sure we are all at the same place.

<MitchZ> Harry, I'm here! -MitchZ

<tjr> tjr - Tom Ritter, iSEC Partners. I'm on the phone.

<wseltzer> kaepora: is that Nadim?

<tjr> Yes

<sdurbha> sdurbha: Seetharama Durbha, CableLabs

Asad from Gelmato, SDurbha from Cabelalbs, Karen from Gemalto, Richard Barnes (BBN), Ryan Sleevi (Google), Christopher Kula (indepdnent), Fluffy (Cisco), PhilipG (Cisco), Virginie (Gemlato), SMC (Shawn McGregor - Oregon State University) ,Emily Stark (MIT), Wan-Teh Changg (Google, Eric (RRTM), McDondan (?? - may not on phone), Kaepora (?? - maybe not on phone), Tom Ritter (iSec partners - IEs), Channy (?? maybe) , tl1 (Tom Lowenthal David (Phone), David

<kaepora> Hey guys

http://www.w3.org/2004/02/Process-20040205/groups.html#good-standing

http://www.w3.org/2004/02/Process-20040205/policies.html#coi

David Hooley (Cablelabs Gate)

<JimD> Jim Davenport (MITRE) here

Jim Davenport (MITRE)

public-webcrypto@w3.org

<wseltzer> Bugzilla

<wseltzer> we'll have a separate public-webcrypto-comments list

use-cases

Brief reminder of usecases for primary features

virginie: what we have seen is that the use-cases behind the primary features are under debate last week
... I propose we have a wiki-page where we store the use-cases

ekr: the primary use-cases are too vague

<Channy> I just summarized some of features in community wiki. http://www.w3.org/community/webcryptoapi/wiki/Use_Cases It's very starting page.

ekr: we need to be a lot more detailed than the list of things, largely because of the requirement of key isolation
... we hvae to list them excruciating detail

richard: if we have a requirement that the javascript layer can't handle the key
... then we need to have explicit functions for derived key

ekr: every single protocol, as there's a zillion different key derivation functions

karen: I also think we define the scope and the level
... most of the messages do not seem aimed at high-value use-cases

<ekr> Particularly, it needs to say stuff like JOSE, FIPS 800-108, etc.

<kaepora> , I'm in the conference call (I'm Nadim Kobeissi)

wtc: I suggest that we need to sharpen the editors draft in the use-case

<tjr> I proposed some use cases way back in December: http://lists.w3.org/Archives/Public/public-identity/2011Dec/0058.html I can revisit those and flesh them out if desired.

<tjr> (Some of those are clearly outside the scope now.)

<rbarnes> tjr: probably would be helpful

<ekr> tjr: these seem like the right kind of thing.

<ekr> (not necessarily saying I agree that they are exactly right)

<kaepora> I think it's definitely to be interpreted as key isolation

<kaepora> What else would you do with secret key material?

<kaepora> How can I put myself on the speaker queue?

ddahl: let's consider key material still open at this point
... in some cases we'll need it

<JimD> good Zakim guide here: http://www.w3.org/2001/12/zakim-irc-bot

<MitchZ> Isn't the complexity around key isolation really two things: (1) how you derive / access the key or (2) how may crypto APIs you want in the generic case, whether you support key isolation or not?

<MitchZ> We don't need to add all crypto algorithms under the sun in version 1 of the APIs, do we?

<ddahl> MitchZ: no, we should not

kaepora: the charter should be interpreted as key isolation
... no other thing that is actually helpful

<MitchZ> can the speaker please introduce himself?

ekr: I'm not sure why this a surprise for people, its important to distinguish between two different kinds of key isolation
... one form that I effectively trust JS with Key 0, but I'm worried about key theft at a later point
... the other case is where you consider the browser is a trusted platform, and I'm not even allowed the access the keys

<ddahl> JimD: ekr is talking

ekr: we should distinguish them, most of security rationales are about the first, not the second

MitchZ: Our concerns around key protection have to be about writing more and more web applicaitons in HTML5, XSS attacks
... what is we are pulling down stuff from location we though we were (ala TLS) that may work in some cases
... as applications being arbitrarily deployed, our concern is concern is for the user
... if they want to take the keys to different application or a browser, we are worried about rogue attacks and non-renewable firmware

ekr: I'll be honest if we have XSS attacks, then we a problem and you need to figure out reseed their applications

<kaepora> Good distinction: browser/devices

MitchZ: that may be true in browser world, but things may be very different in devices where the keys are hidden from anything but secure OS
... usually the keys are hidden in HSM is becoming more common and necki

<timeless> s|good Zakim guide here: http://www.w3.org/2001/12/zakim-irc-bot||

<MitchZ> I keep hearing "Eckert"

<MitchZ> Are people referring to "ekr"?

<rsleevi> Yes

<MitchZ> If so, apologies, Eric.

<MitchZ> Of course I know you ;)

<MitchZ> We need to do lunch again soon...

ekr: in exactly the case in MitchZ is talking about exposure of ephermeral keys is not so bad, but exposure of permanent keys is terrible
... a design where every key has to be hidden may be impossible
... not an all or nothing issue

<ddahl> hhalpin: i think this is an open issue that cannot be viewed as an all or nothing situation. I can see some API methods that allow you to create accessible key material, but the default main usage will be via keyID

<ekr> so, for instance, if you said that you couldn't access certain long-term keys, but you could export symmetric keying material, the whole KDF problem goes away

MitchZ: it is true that in many cases session keys can be revoked and renewed, so maybe XSS isn't a huge issue

<ddahl> ekr: we should create some psuedo-code examples that better explain when we might want have access to the secret key material

MitchZ: we have examples of how third parties take those keys and abuse them in interesting ways, and we have internally implemented things were session keys are inaccessible

<ekr> I'm not suggesting that there is *no* benefit to protecting keys ever.

MitchZ: its not a religious standpoint
... should have a either-or design

rsleevi: lets look at high level, low level, normal
... PCKS11 gives you option, and you see thats common with other API

<rbarnes> rsleevi: +1 to this approach

rsleevi: look at the "refer to by handle" but you can export it potentially in Crypto API and Next Gen Crypto API from Microsoft
... you have things and consistently refer to them by handles

<ekr> Where things get really messy is whether the application of a key to a piece of data taints the output of that operation.

rsleevi: but as some of this is implenmtatnion dependent, we can get them

<ekr> So, say I have an RSA key and I do X=RSA_decrypt(K, msg)

rsleevi: but if we go low-level like PKS11 for JS we're going to have a very trickty time

<ekr> Should I be able to see the output of X?

rsleevi: padding schemes, encrpytion modes,
... we should allow implemention dpeendent
... import/export out of key material

rbarnes: I'd like more info on use-caes before making decision on use-cases

<ekr> This becomes especially difficult if some of the operations reveal information about the keys.

Virginie: A need for us to write the use-cases down and transform them into functional requirements

<ekr> So, for instance, it's generally safe to operate an RSA decryption oracle as long as I'm not allowed to do raw output of PKCS#1 non-compliant data

<ekr> but it's *not* necessarily safe to output the results of DH key agreement compuations

Virginie: the multiple levels approach is a proposal

<kaepora> Someone mentioned earlier that W3Crypto would be used on Bluray devices – could someone expand on that? Examples?

<fluffy> I'm having a hard time hearing Virginie

<kaepora> New idea to me

<ddahl> kaepora: There is a netflix use case for this... http://www.w3.org/wiki/NetflixWebCryptoUseCase

<virginie_galindo> to fluffy : hearing of understanding my frenc accent ? ;-)

<kaepora> *Crickets*

<ddahl> hhalpin: i will if no one else does

<ekr> so, I don't generally understand the problem that people think they are trying to solve. I know how I would design a system :)

<rbarnes> ddahl: i can help

<MitchZ> i'll volunteer to work with ddahl

<ddahl> rbarnes++

<ddahl> MitchZ++

<scribe> ACTION: ddahl amd MtichZ to help collect use-cases around key isolation [recorded in http://www.w3.org/2012/05/14-crypto-minutes.html#action01]

<ddahl> hhalpin: don't forget rbarnes

Brief presentation of editor's draft API (by editors)

s/and MitchZ/ and MitchZ and rbarnes

Brief presentation of editor's draft API

ddahl: This is just a starting point for conversation on the API

<ddahl> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

ddahl: I've expanded on DomCrypt work

<MitchZ> w.r.t. to ekr's question on the RSA decrypt, i believe that what is described does not work b/c... the initial message from client -> server does not contain any sort of acknowledgement that the exchange has the eventual purpose of key exchange with key hiding

ddahl: the big change is we've moved to event driven model

<ekr> sorry, I don't understand your point.

ddahl: that's the largest change from DomCrypt
... I'd like to see if this event-driven model makes more sense

<MitchZ> DH has the benefit of the SS creation happening under the covers, so it's obvious how this would work w/ DH

ddahl: no such thing as call-back driven DOM interface as event-driven is cleaner, allows multiple listeners
... seems to be "what the web expects"

<MitchZ> but an RSA "for hidden key exchange" could certainly be possible, but it isn't regular RSA encrypt/decrypt

ddahl: as far as key isolation, everything is what I think of as "high-leveL'
... what appears to be high-level could be low-layer from a different layer

<ekr> Mitch: well, as I said, I'd like to see a threat analysis that explains why it's desirable to hide the RSA output.

ddahl: I'm a browser engineer, not a cryptographer

<ekr> I don't understand how this API works if I have concurrent key generations.

ddahl: the main other things that have changed is hashing and MAC
... other folks want CMAC

<ekr> how do I distinguish them?

ddahl: so some other things have came up
... this is a starting point
... I have tried to add as much example code as possible

<ekr> can't we use hg?

<ekr> That's what WebApSec is using.

<ekr> perhaps the hub of git. :)

<kaepora> The question I'm planning to ask: will adding DRM a-la-Netflix be worth modifying our spec, or is it not enough of a priority?

<MitchZ> ? Netflix' involvement in this has nothing to do with DRM?

<MitchZ> So, I'll be curious to hear your question.

virginie: we want to address as much as we have
... so let's stick to discussion on mailing list rather than raising new version

<ekr> ddahl: how do you handle concurrent async operations?

<kaepora> MitchZ: http://www.w3.org/wiki/NetflixWebCryptoUseCase specifies "DRM license exchanges"

ddahl: we will try to create constructors

ekr: I'm not have callback vs events
... but we need to have concurrent operations

ddahl: what will happen is that you'll create a constructor and isolate it via constructor

<rsleevi> ddahl: That was the motivation for the object-based approach discussed on the mailing list - so that different objects may have different events, and for the use via Workers

kaepora: API to grant license exchange, we would modify the charter

<ddahl> rsleevi: indeed, that was another thing that Mozilla platform engineers recommended - a synchronous API in parallel that only runs in Workers

<kaepora> Whew, great news

MitchZ: I'll remove the DRM acronym from use-case document now, our protocol has to do with device and user-authentication

<kaepora> MitchZ: That's wonderful news, thanks.

MitchZ: the DRM question confuses

<kaepora> Yeah, I was a bit frazzled by the mention of DRM ;-)

PhilipG: I wonder about higher level stuff

<MitchZ> kaepora: thanks for input on use case doc.

secondary use-cases

<ddahl> hhalpin: i think there might be a question from karen

<kaepora> MitchZ: Thanks for the reassuring answer, I'd hate this spec to be DRM-oriented.

<MitchZ> me too :)

karen: for the API itself I don't quite understand where is the ciphertext is

ddahl: the ciphertext shows inside of the function handler that is run after things are encrypted

wtc: a few minor typos

karen: keystore of cryptoprovider
... is that in-scope?

browser could provide key operations

scribe: but could smartcard?

rsleevi: looking at different levels of keys, looking at persistent keys on smartcards
... some of its contigent on use-cases that come in

<tjr> Is this meeting capped at ending in 30 minutes, or is expected to run indefinetly?

wtc: what I have in mind is that the website use very high-level criteria, similar to TLS
... specifying the set of acceptable criteria to find key in right key container

gathering secondary feature use-cases

<wseltzer> phone troubles here for virginie and wendy

<kaepora> I have a pretty elaborate use-case

nadim: I might want to volunteer for that document if no-one else does
... I'd need to be briefed
... I have an elaborate use-case for encrypted IM using HTML5
... porting to Android to iOS using PhoneGap
... it would benefit from such an API
... secret key storage would be very useful
... the project is already running so we can use it for a testbed

<Channy> There is secondary feature use-cases from Korea too. http://www.w3.org/wiki/KoreaWebCryptoUseCase

<JimD> I'll volunteer to assist nadim with secondary use-cases

<kaepora> Link to my project (Cryptocat)

nadim: move from Stanford Library to W3C library

<kaepora> https://project.crypto.cat

<kaepora> https://crypto.cat

<ekr> rsleevi: do you mean just erasing it on the client or a message to the server?

ryan: we really want to fix the TLS session stuff, but as its in charter, that's one we are very interested in Google, could be done independently but could happen here
... browsers each do it differenty
... we will put together a strawman

<rsleevi> ekr: API for the client to 'forget' its session ID

<rsleevi> ekr: invaliding the (client) session ID cache

<ekr> rsleevi: why doesn't the server do it

<ekr> ?

<scribe> ACTION: JimD and Nadim to start a wikipage to start collecting the use-cases for secondary features [recorded in http://www.w3.org/2012/05/14-crypto-minutes.html#action02]

<ekr> Isn't it kind of a problem to have the session cache hanging around on the server?

<kaepora> JimD: Please email me so we can get started: nadim@nadim.cc

Test Suite

virginie: We will want to address test suite

<christopherkula> Interested in possibly helping Nadim on secondary use cases

<rsleevi> ekr: Browser behaviours actively thwart effectively managing it at the server. I can provide more details on the list of previous discussions where this has arrived (eg: the W3C CG for WebID catalogued these pretty well)

feedback from public call

<ekr> I'm not disagreeing with that, but it seems like a security problem to have it exist on the server

the definition of use-cases of primary features

Group life

<rsleevi> ekr: The expressed desire for log out has less to be about security issues, and more about the general usability of SSL client certs within browsers

<ekr> rsleevi: ah

lets have a face-to-face meeting during the summer

can't have something earlier than 8 weeks

<kaepora> That's a great idea

end of july would be earliest

we could do near the IETF meeting in Vancounver

<ekr> what is the proposed time?

<Channy> @hhalpin I want to join job of secondary feature use-cases

<ekr> IETF is already *really* long

<rbarnes> hhalpin: +1 to IETF colo

<wseltzer> IETF is July 29-Aug 3 in Vancouver

<kaepora> Vancouver would be cool

<rsleevi> wseltzer: July 29, you mean, right?

https://www.ietf.org/meeting/upcoming.html

<tjr> That overlaps with Black Hat July 23-26

ekr: its a problem to schedule stuff right before IETF
... I probably already have somethig then
... if you are trying to capture then, it will increase conflcits rather than decrease

PROPOSAL: meet at Vancouver last week of July, need to decide by next WG meeting

<JimD> Next Meeting: IETF 84, July 29-August 3, 2012 (from www.ietf.org)

virginie: we will also deifnitely meet at TPAC

<kaepora> Alright everyone, I must be on my way

<kaepora> Very much appreciated this meeting

<kaepora> Will be in touch with JimD regarding our new editing responsibilities

<kaepora> Thank you

<Karen> It is better to do it 4 hours earlier.

<JimD> Yes, Can make it 2 or 4 hours earlier

<PhilipG> can't do 4 hours earlier

<Karen> If it is 2hr earlier, it will be midnight in asia

<tjr> +1 doodle

<Channy> +1

RESOLUTION: Meet next Monday 2 hours earlier

<scribe> ACTION: virginie to send out Doodle with a range of meeting times [recorded in http://www.w3.org/2012/05/14-crypto-minutes.html#action03]

<wtc> How long will the next meeting be? 1 or 1.5 hours?

we will try to keep them to 1 hour typically, but they will tend to go over in the beginning of the WG life to 1.5 hours

people in general should feel to OK with dropping after the first hour

Summary: Two new wikis over primary and secondary use-cases, need decision re Vancounver f2f by next meeting, the test-suite and liason topics need to be visited next meeting, next meeting 2 hours earlier with a Doodle for new meetings

virginie: we need better consistency
... in following up points on mailing list

Meeting Adjourned

<wseltzer> Meeting: Web Cryptography Working Group

- DRAFT -

Web Cryptography Working Group

14 May 2012

Attendees

Contents