<trackbot> Date: 01 October 2012

<selfissued> Somebody just joined with lots of static on the line

<sdurbha> +1.303.661.aaff is sdurbha

<mzollinger> phone sounds terrible

<haavardm> I don't hear anything

<haavardm> I'm håvard Molland from Opera software

<rsleevi> Glad to have you, haavardm!

<rbarnes> huh?

<asad> yes

<mzollinger> yes, things are good

<rbarnes> i was already muted

<rbarnes> i am muted

<rbarnes> but i was muted before

<hhalpin> Meeting of Oct 1st 2012

<hhalpin> scribenick: emily

<hhalpin> scribe: emily

hhalpin: any objections to last meeting's minutes?

<hhalpin> PROPOSED: approve http://www.w3.org/2012/09/24-crypto-minutes.html as minutes from Sept 24

<hhalpin> RESOLVED: http://www.w3.org/2012/09/24-crypto-minutes.html as minutes from Sept 24

FPWD

rsleevi: still having meetings over the course of the week, that is not an area we've received substantial feedback on
... feedback from various blogs, twitter, research, but not much engagement from js community
... that's still an area that needs to be looked at

hhalpin: can we ask for formal reviews from webapps?
... anyone else from webapps here?

<karen> +q

<hhalpin> AppSec USA?

karen: at the end of oct, there will be appsec usa, webapps security conference

<rsleevi> http://www.appsecusa.org/

karen: an OWASP conference in north america

<hhalpin> http://www.appsecusa.org/

<hhalpin> looks very relevant!

karen: I'm trying to find people to get people interested in reviewing
... there will be a talk on webcrypto by Travis H
... I sent him an email asking him to review it
... he's going to talk about the failure of web crypto
... he said he will review it
... I've asked him to mention the API in his talk, but he hasn't responded to that yet
... I will try to chair that session, and maybe I can announce it in the session

<hhalpin> Javascript community

JimD: Ryan said he didn't see specific comments from js community, and why would you expect only comments from js community as opposed to crypto/AI community, etc.?

rsleevi: it's a w3c spec, predominantly looking at webidl bindings implemented by user agents, and since js is de facto language for user agents, we want to make sure API is intuitive, consistent
... with DOM bindings, etc. that are expressed in webidl, bound through js
... want API to fit in with existing/ongoing APIs: File API, etc.
... not to say that crypto feedback isn't valuable, but we also want to know if this is natural for JS developers

<hhalpin> from HTML5 and WebApps

hhalpin: I wrote a draft blog post

<hhalpin> 1. Malleability of JS environment (CSP)

<hhalpin> 2. "Broken" crypto in the API

hhalpin: outlining that it is a component of a larger security model, what is the threat model we're actually going after

<hhalpin> 3. Why is it so low-level?

hhalpin: these are the 3 main criticisms we've gotten
... any others left out?
... One we can kind of punt on (JS env), two we've decided to label
... we don't have a silver bullet response to why we're allowing broken crypto

<rbarnes> 2: backwards compatibility and polyfill

<karen> +q

<rsleevi> ^ what rbarnes said

<rbarnes> +q

karen: One of the arguments is that many existing apps are using broken crypto
... SHA1, for example
... for example, HMAC-SHA1 is being used by several cloud providers
... use SHA256 as well, but also support SHA1

<zooko> Zakim aakk is zooko

rbarnes: Backwards compatibility is one reason

<selfissued> I presented a detailed table of what tools currently implement what algorithms at the last F2F

<karen> +q

rbarnes: we're not going to implement every mode or algorithm, so exposing unsafe things allows people to use them in safe ways
... eg CTR mode from ECB

mikejones: at the last F2F, I presented a detailed table indicating what is implemented by tools that are actually deployed
... and there was strong support for tailing algorithm recommendations to things that libraries actually implement
... for interoperability

hhalpin: we should beef up our response if necessary

<selfissued> Data on what algorithms are implemented in libraries that are actually deployed should drive our algorithm recommendations

karen: I agree with mike, and broken or not-broken depends on the context
... for example there's no harm in using ECB for a short string

<wseltzer> [Mike Jones's reference at F2F: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jul/0119.html ]

<hhalpin> ?

<rsleevi> ECB as a mode is always dangerous :)

<haavardm> I agree with rsleevi here :)

rsleevi: Disagree with karen and mike on the premise of interoperability
... these are algorithms that have detailed specs, so if we decide to specify an algorithm, there's no concern about interoperability in terms of inputs, outputs, how it behaves
... I think the argument should be made with regards to what protocols are being used

<zooko> Hi folks, I'm sorry I'm late.

rsleevi: there are some protocols that have existed for 15 years, so their algorithm selections reflect security 15 years ago

<zooko> It has been quite a day here...

rsleevi: ex: SSH, TLS1.0, GPG
... so if you want to allow API to be used with those things, then API needs to specify what those algorithms are

<zooko> +q

rsleevi: decision of strong vs. weak is a decision of use cases that we do or don't want to support
... if we want to allow existing use cases, then we need low-level API with existing algorithms, even if they have known issues
... so the question is whether the API should steer people to particular implementations
... especially important for some of the secondary features, government signing and things that are done through activex currently
... so it's a question of use cases, not what implementations support

sdurbha: from a API perspective, prescribing what is right/wrong is very limiting
... we have discussed before that what is not broken today is broken tomorrow, and maintaining this list of recommendations is not something we want to do
... we don't need the API to steer developers into the right design, it's up to them
... there's a lot of legacy stuff, if we block them by taking a stance, it will be very hard to use the API

<asad> +1 on what sdurbha is saying

rbarnes: agree with ryan about backwards compatability
... also forwards compatability
... Don't want this group to be responsible for documenting/implementing every mode of every algorithm out there

zooko: agree with rbarnes, there's a lot of crypto out there and we odn't have to specify all of it
... a bare AES function is necessary to much of the crypto that's out there
... ECB mode is not necessary to implement that same crypto

<rbarnes> +1 to distinguishing between bare algorithm and ECB

zooko: I would put ECB in a class by itself. There's a lot of crypto like SHA1 which is weak or potentially weak, but is widely used and may be strong enough for some use cases
... but ECB is not widely used, and any use of it except for the case where input <= 16 bytes is not safe for encryption at all
... so it's not just a weak algorithm, it's really a separate class, it's not an encryption mode
... because it can't take more than 16 bytes of plaintext

mikejones: Responding to Ryan's comment. I wasn't saying that we shouldn't support legacy algorithms. I was trying to make the case that support for legacy algorithms is critical for many use cases
... for example, we may need older algorithms, and to the ECB point, we decided on the last call we were going to include it

<rsleevi> Apologies for the misinterpretation of your point - yes, I agree, 'legacy' support is important for our use cases

<hhalpin> We decided *unless* we are convinced in the next argument :)

ECB

<haavardm> But ECB is not a legacy algorithm.

<rsleevi> I'm more concerned for the general case of "support for X algorithm" is going to be an existential crisis about whether or not X is "secure enough" for the API

<zooko> Yeah, that could be a big can of worms.

<zooko> I think of ECB mode as an outlier.

hhalpin: two ways of looking at it: by nature, ECB is not secure, or are there use cases for it
... is that crucial for implementers?

<zooko> That's a good question.

<zooko> The question of whether it is that crucial to implementors.

mikejones: Microsoft has use cases for ECB, in application scenarios where it's secure

<zooko> I'm sorry that I missed this list of uses of ECB by Microsoft.

<zooko> ☹

<zooko> +q

mikejones: richard has already described the use of ECB as a building block for modes like GCM
... so I don't think there's any question that it'll be used

zooko: ECB is not necessary for implementing GCM, a bare or vector AES function can be used instead
... can I see a list of uses by Microsoft for ECB?

<hhalpin> I think they're in the archive, I'll look.

Wasn't the argument for using ECB to implement CTR or GCM for efficiency, not for necessity?

<hhalpin> \me this is Tony Nodalin speaking

Tony Nadalin: for bitlocker, and for keys

scribe: which falls within the 16 bytes

zooko: bitlocker is not using ECB, it's using an AES function

<haavardm> ECB mode is when you encrypts many blocks of data...

zooko: the uses I have heard of, as far as I've seen, those would be satisfied just as well by an AES function
... the terminology that I've seen in the crypto literature refers to it as AES and not ECB
... I don't mean to fixate on the terminology, but it's a significant distinction and the spec has to address what you do when someone passes a > 16 byte message
... can either fail in some way, or you can apply the AES function with the same key to each block
... the latter option divulges secret to any eavesdropper
... so these behaviors have very different security consequences
... of the use cases I've seen, either of the behaviors will work

rsleevi: the CTR mode example... I'm more concerned that we need to figure out how algorithms are specified
... MD5, AES-CBC without integrity, all have their issues
... MD5 is broken, HMAC-MD5 is not as broken
... necessary for a number of protocols like SSH and GPG
... so to me the ECB or raw AES function should be consistent with other algorithms
... equally important to consider MD5, 3DES, or any other algorithm that might exist that is problematic, it's most important that API has consistent expectation
... we agree that we want an ECB function, so I think it should look the same

<wseltzer> scribenick: wseltzer

<hhalpin> i.e. not specify vectorization or parameters (i.e. # of byte limits)

rsleevi: proposal is what's in the spec, disagree with a vectorized operation or limitation on the bytes

<rsleevi> Proposal: As spec'd, just possibly renamed to not call it "ECB"

hhalpin: would that be acceptable to use cases (selfissued, rbarnes)?

@@: it would be awkward

<rsleevi> synchronous would be unacceptable at all for the API on the main thread

selfissued: I'd have to review the spec to answer
... agree with Richard that we need to be able to implement other modes;
... not thrilled with limitation to single round

<rsleevi> both NSS and OpenSSL do their GCM atop the raw AES function, which is what the ECB mode is just a pointer to

selfissued: NRI JSON Web Token library uses ECB, I believe

<rsleevi> Which take full fledged variable length-but-blocksize inputs

<haavardm> +q

hhalpin: Any other comments on ECB?

<ddahl> hhalpin: I would have to defer to bsmith @ mozilla on this subject

haavardm: Confused by the ECB discussion and the API; usually low-level functions are wrapped in encryption modes
... how would ECB mode encrypt 18 bytes?

<zooko> I agree with rsleevi and others that ECB mode -- or some such multiblock API -- could be an optimization for precomputation, SIMD, etc.

rsleevi: example, in counter mode, you can pre-compute the counter

<zooko> I also agree with haavardm and rsleevi that there aren't really *other* uses of ECB than that.

rsleevi: whether we call it "raw AES" or "ECB", provide raw functions that implementations can use to optimize

<zooko> +q

rsleevi: don't prevent the implementation from doing optimization, as putting block-restrictions would.

zooko: Concern about ECB is empirical; lots of insecure apps because programmers see list of modes, use one
... ECB has a simpler API (no IV); it's commonly used, and apps are commonly vulnerable
... concerned that if we include this mode, we should mark it as not an encryption mode
... because it doesn't maintain confidentiality of large blocks
... don't offer it as "like CBC"

<rsleevi> Poor security is an inescapable reality. As mentioned on the list, even a high-level API can demonstrably lead to security failures when the threat-model is not considered. I do not see value in attempting to prevent stupidity, because you can't fix stupid - the ingenuity of idiots undermines any "fool" proof system

selfissued: I'm fine putting it in a different list, just not excluding ECB

hhalpin: hearing don't exclude ECB

zooko: propose that the spec specify an AES function
... defined on 16 byte inputs, type-error if you pass something else
... classify things by what they do (e.g. authenticated encryption mode, unauth., not an encryption mode)

<zooko> Proposal: we specify a simple AES function which is defined only for 16-byte message inputs (because that is familiar to low-level implementors from asm and C world),

<zooko> Proposal, ongoing: we specify an ECB mode

<haavardm> +1 zooko.

<rsleevi> As mentioned, I cannot support a 16-byte limit. The rest is fine and merely a game of semantics, as long as the API itself is not changing, but the 16-byte limit is troubling, especially if (as proposed earlier), it's synchronous

<zooko> Proposal, ongoing: we avoid classifying algorithms as strong/weak/broken, but we do classify them for "what they do": OCB and GCM are authenticated encryption modes, CBC and OFB are unauthenticated encryption modes,

<zooko> and ECB is not an encryption mode, as it doesn't preserve confidentiality of the message.

<rsleevi> -1

<hhalpin> Any objections to Zooko's proposal?

<rbarnes> -1

<haavardm> +1

<hhalpin> Ryan? It is just the 16 byte limit?

rsleevi: 2 concerns, 16-byte limit, synchronicity

<zooko> Let's agree that the API has to be asynchronous.

rsleevi: unimplementable in Chrome

<rbarnes> +1 to async; i withdraw my prior mention of synchronous

rsleevi: in the context of the main thread

<zooko> ... at least on the main thread.

rsleevi: if we said that ECB could only be used on workers, that might be tenable
... 16-byte is a problem for performance, where you want to be specific to the processor

zooko: 16-byte would only be for the implementor who wants safety-check

rsleevi: concerned that we not recommend a poor-performing implementation

hhalpin: would we accept the proposal asynchronous, without 16-byte limit?

<zooko> "primitive" is a good word for this, as opposed to "encryption mode".

rsleevi: No problem calling it something else, highlighting it e.g. as "primitives,"
... but don't compromoise the performance options

zooko: withdraw the part of my proposal for lenght-checked simple AES
... @@

selfissued: need a concrete proposal
... hear consensus that we need to include ECB in some form

rbarnes: enough consensus that we need some way to access primitives
... hash out details on the list

<hhalpin> Did I disappear?

<rsleevi> Proposals for agenda for TPAC "soon"

<hhalpin> let me dial back in

<hhalpin> But keep discussing please!!

TPAC: http://www.w3.org/2012/10/TPAC/

<rsleevi> Thanks to Harry, Wendy, and Emily for chairing/scribing

<rsleevi> and thanks haavardm for joining :)

<zooko> Thanks everyone!

<hhalpin> I suggest that Zooko send a modified proposal by the mailing list

<haavardm> thanks :)

trackbot, end meeting

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Nodalin/Nadalin/
Succeeded: s/??:/zooko:/
Succeeded: s/@@:/zooko:/
Succeeded: s/@@/rbarnes/
Found ScribeNick: emily
Found Scribe: emily
Inferring ScribeNick: emily
Found ScribeNick: wseltzer
ScribeNicks: emily, wseltzer
Default Present: +1.703.284.aaaa, +1.512.257.aabb, [Microsoft], +1.512.257.aacc, +1.707.799.aadd, ddahl, +47.23.69.aaee, +1.303.661.aaff, +1.978.652.aagg, +1.617.575.aahh, rsleevi?, +1.978.652.aaii, emily, rbarnes, sdurbha?, +1.408.540.aajj, asad, WSeltzer, markw, mzollinger, JimD, hhalpin, karen, haavardm, mitchz, +1.303.543.aakk, zooko
Present: +1.703.284.aaaa +1.512.257.aabb [Microsoft] +1.512.257.aacc +1.707.799.aadd ddahl +47.23.69.aaee +1.303.661.aaff +1.978.652.aagg +1.617.575.aahh rsleevi? +1.978.652.aaii emily rbarnes sdurbha? +1.408.540.aajj asad WSeltzer markw mzollinger JimD hhalpin karen haavardm mitchz +1.303.543.aakk zooko
Found Date: 01 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/01-crypto-minutes.html
People with action items: