<trackbot> Date: 30 September 2013

<jimsch> zakrim, [ipcaller] is jimsch

ok

scribe

<MichaelH> Question: Is neither Editor online?

<virginie> http://www.w3.org/2013/09/16-crypto-minutes.html

<wseltzer> scribenick: kodonog

<MichaelH> +q

minutes from 16 September 2013 approved

<jimsch> wendy, when are minutes going to get posted to the website?

<jimsch> yes

Dan's comments...

<hhalpin> The minutes are always sent out over the mailing list

<hhalpin> but nonetheless, we can try to do that before TPAC 2013.

<virginie> Dan comment are available under http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0054.html

Section 5 - security considerations

5.2 3rd paragraph, keys might be accessible to end user, end user might have access to plain text data in addition to keys

<virginie> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security-developers

surprised that there is no consideration of the platform itself... add a paragraph talking about the need for strong randomness,

<hhalpin> Yes, I would raise issues for this, at least stating it in an informative way.

<MichaelH> ack

Virginie: we had discussion about strong random, most of the randomness is strong but it isn't stated in the spec

Dan: security considerations is where this could go

Sec 9, no mention that the random generator might fail

<hhalpin> I'll go after Israel, as this is an implementation issue

Wendy: we should add issues into the tracker for each of these points

<Zakim> wseltzer, you wanted to ask, should we raise issues for any of these?

Harry is happy to raise the issues in the tracker since he asked for the review

Israel: How is this statement different than any plaintext that you would store in the browser? Perceived expections of the end user

Dan: The developer may have some expectation that when he decrypts ciphertext on the end point it isn't visible to the end user, but that isn't the case.

<wseltzer> +1 re warnings on entropy failure

Bigger issue is the question of entropy and the fact that the random number generator might fail

Harry: We can't make entropy guarantees... should we provide more of a warning...

Dan: they fail when their entropy state is too low.

Harry: both these issues could be dealt with informative notes

<virginie> commenting now section 13 https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface

<MichaelH> +q

Dan: Section 13 - (see comment in email) suggestion is to expand the symmetric encryption encrypt interface and add two additional argument (nonce and associatedData)

<mete> +1 to nonce and associatedData

moving onto... associatedData is not an algorithm parameter should be an input

Israel: you aren't saying it isn't workable just that it looks odd given the semantics of the data that is being passed

Dan: true, it is workable, but I'm concerned it will confuse the developers and result in insecure implementations

<MichaelH> +q

MichaelH: there is nothing to guarantee that with the nonce being passed in, that they will change it...

<wseltzer> Dan: as-worded, risks suggesting that developers re-use nonce, resulting in insecure implementation

Dan: that's true, but at least if it is being passed in it would suggest to the developer that the nonce would be changed

Section 17: there are algorithms listed there that really should not be used!

<arunranga> Maybe we could break out backward compat as a separate section.

Understand that some algorithms are needed for backward compatibility, but it needs to be really clear that these algorithms should not be used in general.

Mike Jones: agree we should be passing the nonce parameter in (backing up to the previous issue)

Dan:

DF and ECDF are basically the same and should be treated as such, only difference is the parameter (prime and curve)

<hhalpin> sounds sensible to me.

move closer together and make the descriptions the same

Harry: we've had real difficulty in how to separate out those algorithms that are included for backwards compatibility

what specific warnings should we give developers about choosing algorithm... per algorithm informative warning note?

<MichaelH> Deprecated!

options: put known bad algorithms in a specific box or create per algorithm warning

<hhalpin> The term "deprecated" might be the best

<hhalpin> +1

Basic issue is that recommended algorithms are not all really recommended

Perhaps add a sentence about deprecated algorithms at the end

<wseltzer> Dan: specifically, don't recommend AES-CBC

Mike: AES-CBC can be used with an integrity function

<jimsch> McGrew draft is encrypt then mac

Dan: encouraging developers to create their own combinations of AES-CBC with integrity is almost guaranteed to create insecure implement ions...

Dan'

<wseltzer> Dan: of the 7 ways to use AES-CBC with authentication, 6 are wrong

<wseltzer> ... use AES-GCM instead

MIke: McGrew's draft progressing in the IETF

Dan: if that is the case, that algorithm should be added to the document (McGrew's draft)...
... the API should provide that implementation, developers should not build that on their own

<hhalpin> that's AES-ESP you'd recommend?

<jimsch> McGrew draft is http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/

<wseltzer> [answer was AES-GCM]

<wseltzer> Dan: add acces to AES block ciphers (

Dan: on the list of ciphers there is no raw access to AES AES block cipher), developers will need this if they are going to use algorithms outside the list

<MichaelH> +q

Dan: AES-CFB shouldn't be on the list

<selfissued> The McGrew draft is http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-02

PBKDF2, different user agents have different computing power, the number of iterations too high might be too much for low computing power devices, and the number to low will impact security. Need some discussion on how to set the number of iterations

<hhalpin> 20,000->200,000?

<hhalpin> What is precise numbers recommended?

Two examples... weak home routers use 2000 iterations, MAC uses 200,000 iterations ... maybe provide three key words (weak, intermediate, and strong with some guidance on what those numbers might be...

<hhalpin> Perhaps as an informative note

<israelh> Is user agent what you meant or devices. You could potentially have the same user agent running on different devices which could affect performance?

hesitant to include numbers in standard because as devices progress numbers that make sense will change

Virginie: would like data or references to help the group

Harry: (??? can't understand him)

<arunranga> Super hard to hear hhalpin

how would you be extensible?

Dan: 90% of the implementations use one of the curves we specify... TLS there is support for using unnamed curves.

<MichaelH> Addition of any new alg/property can be done using 17.3. Defining an algorithm

not suggesting you go that far, but it is very likely within a few months there will be additional curves that will be popular

<jimsch> The recent NSA news has pushed the Brain Trust curves to the forefront for reasons of paranoia

should be prepared, developers will want to use curve 25519 (djb) (from scribe - not sure this ref is correct)

<wseltzer> s/

mechanism for additional curves available via registry... which takes this issue away.

<hhalpin> Where is pointer to registry?

Israel: do you mean user agent or device?

<mete> +q

Dan: I mean the combination of user agent and device
... I was just suggesting that additional information be provided about how to choose the number of iterations (developer has to define this number). Guidance about specific numbers would change over time.

<hhalpin> ok, issues opened

Comparison with webgl... but the difference is that here the number of iterations has to be the same across implementations, whereas webgl moves to lower resolution on lower power deveices

Harry: Dan would you be willing to review again after we've had time to resolve your issues?

Dan: yes

example should be GCM not CBC

<selfissued> My thanks to Dan for his comments

<arunranga> +1 selfissued

<israelh> +1

<wseltzer> thanks Dan, and group!

<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/(//
Succeeded: s/25509/25519 (djb)/
WARNING: Bad s/// command: s/(from scribe - not sure this ref is correct)
Succeeded: s/(from scribe - not sure this ref is correct)//
Found ScribeNick: kodonog
Inferring Scribes: kodonog

WARNING: No "Topic:" lines found.

Default Present: +90533302aaaa, Wendy, mete, +1.540.809.aabb, selfissued, Arun_Ranganathan, +1.512.257.aacc, kodonog?, +1.650.725.aadd, +1.512.257.aaee, Dan_Boneh, +1.617.253.aaff, +1.512.257.aagg, jyates, MichaelH, +1.661.748.aahh, karen, virginie, Sangrae, BryanEyler, jimsch, hhalpin, [Microsoft], israelh, [IPcaller]
Present: +90533302aaaa Wendy mete +1.540.809.aabb selfissued Arun_Ranganathan +1.512.257.aacc kodonog? +1.650.725.aadd +1.512.257.aaee Dan_Boneh +1.617.253.aaff +1.512.257.aagg jyates MichaelH +1.661.748.aahh karen virginie Sangrae BryanEyler jimsch hhalpin [Microsoft] israelh [IPcaller]
Found Date: 30 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/30-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report