Support for ECB

I'm not sure how controversial this will be, so I figured I'd take a quick
poll before filing an ISSUE or adding it to the spec.

It seems to me that supporting ECB, while dangerous, will be desirable to
support polyfill. For example, an implementation that doesn't support
GCM/CCM can polyfill them atop an ECB implementation. Likewise, an
implementation of CTR where the block counter was in the high-order bits,
or that used a LSR, could polyfill their CTR implementation atop ECB.

Likewise, if an implementation needed to support alternative padding
schemes, or modes such as CTS, may need ECB to accomplish this.

However, ECB in and of itself is trivial, since it's essentially 'naked'
AES.

So how does the WG feel about adding ECB? Is it too dangerous to even
mention, or are the benefits for polyfill implementations enough to merit
specifying how it behaves? I'm not trying to suggest that it be advocated,
but providing the implementation does seem at least somewhat meaningful.

Of course, ECB mode can be used to negate tainting, since an implementation
might have a key flagged as ECB, but content script could then implement
CTR, CBC, CCM, etc atop that single mode. I'm not sure how strong a
negative that is.

The counter-argument is that an implementation "could" always implement
ECB/GCM/CBC etc by bootstrapping the AES tables. This is what is done by
CryptoJS and SJCL. However, such a scheme negates whatever key storage
properties are supposed to be afforded by this API.

Reactions?