[minutes] Re: W3C Web Crypto WG - agenda for 1st of october call

Here <http://www.w3.org/2012/10/01-crypto-minutes.html> and below are
the minutes from today's call.

--Wendy


                               - DRAFT -

             Web Cryptography Working Group Teleconference

01 Oct 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/10/01-crypto-irc

Attendees

   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

   Regrets
   Chair
          hhalpin

   Scribe
          emily

Contents

     * [3]Topics
         1. [4]FPWD
         2. [5]ECB
     * [6]Summary of Action Items
     __________________________________________________________

   <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
   [7]http://www.w3.org/2012/09/24-crypto-minutes.html as minutes
   from Sept 24

      [7] http://www.w3.org/2012/09/24-crypto-minutes.html

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

      [8] http://www.w3.org/2012/09/24-crypto-minutes.html

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> [9]http://www.appsecusa.org/

      [9] http://www.appsecusa.org/

   karen: an OWASP conference in north america

   <hhalpin> [10]http://www.appsecusa.org/

     [10] 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:
   [11]http://lists.w3.org/Archives/Public/public-webcrypto/2012Ju
   l/0119.html ]

     [11]
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: [12]http://www.w3.org/2012/10/TPAC/

     [12] 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

Summary of Action Items

   [End of minutes]
     __________________________________________________________

Received on Monday, 1 October 2012 20:17:21 UTC