See also: IRC log
<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!
<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
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?
<hhalpin> AppSec USA?
karen: at the end of oct, there will be appsec usa, webapps security conference
karen: an OWASP conference in north america
<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
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
<rsleevi> ^ what rbarnes said
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
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 ]
<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,
... so if you want to allow API to be used with those things, then API needs to specify what those algorithms are
rsleevi: decision of strong vs.
weak is a decision of use cases that we do or don't want to
... 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
... 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 :)
<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
... 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.
mikejones: richard has already
described the use of ECB as a building block for modes like
... 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
... 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
... 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
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
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.
<hhalpin> Any objections to Zooko's proposal?
<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
... 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!!
<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:[End of scribe.perl diagnostic output]