Re: Dan Boneh's comments

Dr. Boneh on bcc, just so he doesn't have to filter through all the
discussion that may evolve on here, but he's welcome to chime in.

Vijay on bcc, specifically for the response tagged MICROSOFT regarding
ECC/brainpool.

Dr Boneh, thanks for the feedback, and apologies that I was unable to make
the call in which you presented your feedback/review.

Assuming Harry has correctly summarized all the points, I've tried to
respond to each of the issues raised.


On Mon, Sep 30, 2013 at 12:44 PM, Harry Halpin <hhalpin@w3.org> wrote:

> He said he'll make the comments in person on the phone.
> -------------------------------------------------------
>
> Section 5:
> ---------------
> Section 5.2, 3rd paragraph:   might be worth mentioning that, in addition
> to secret keys, end-users may also have direct access to decrypted data.
>

I'm not sure the statement about "might / may". They unquestionably will.
This API always attempts to maintain the priority of constituencies
elaborated in
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

In particular, I fear that introducing this into the spec would suggest
that it would be an acceptable design to prevent end users from having
direct access to the decrypted data, which I believe would strongly violate
that priority.

If and when we get to the point where not having access to the data is an
in-scope activity (for example, if a streaming API is introduced, and the
streaming API can be connected to platform objects, and those platform
objects could not expose the underlying decrypted data - aka, DRM, which I
would hope we would not approach), then we could consider introducing such
language, but for now, I fear it would be between disingenuous to dangerous
to call out as a 'may'.


>
> Section 5.2:  Should the section mention that implementations need access
> to unpredictable randomness?   Some user agents may not have sufficient
> entropy.


> Similarly, it might be worth adding a note in Section 9 saying that
> getRandomValues and generateKey may fail with "InsufficientEntropyError" to
> indicate that the generator currently does not have sufficient entropy
> to satisfy the request.
>
>
If a user agent doesn't have sufficient entropy, there's no way it's going
to be making secure connections (eg: TLS).

>From a design perspective, requiring or even suggesting UAs try to
determine how much available system entropy there is seems like a total
failure. The underlying system should guarantee sufficient entropy (eg: by
using a cryptographically strong DRBG seeded from non-deterministic RBG).

That some systems don't offer this guarantee (eg: compare Linux's
/dev/urandom implementation vs *BSD) is a design misstep of the underlying
platform.

I also have trouble with this design because by suggesting entropy is a
precious resource on this system (eg: being directly drained by this API),
the security considerations vastly change - and this is no longer a safe
API to expose to the Web, since it could directly drain entropy and
undermine TLS connections.




>
>
> Section 13:
> -----------------
> The encrypt interface seems to be missing some key parameters.    For
> symmetric encryption I would suggest expanding it to
>
> Promise<any> encrypt(AlgorithmIdentifier algorithm,
>                        Key key,
>                        Nonce nonce,
>                        sequence<CryptoOperationData> associatedData);
>                        sequence<CryptoOperationData> cleartextData);
>
> As is, the Nonce and associatedData arguments are missing.   As a result,
> in several modes the IV and associatedData are given as parameters to the
> algorithms.   I worry that this will confuse developers into thinking that
> the IV and associatedData are set once when the key is initialized and
> never changed again.   But both, especially the nonce, will need to be
> different for every message.


> Similarly, AES-GCM decrypt will need to take as input the ciphertext *and*
> associatedData. Would associatedData always be given as an algorithm
> parameter?   Seems a bit odd to put them there.
>
>
We've discussed this in the WG at length (ISSUE-12 / ACTION-83).

With the current design approach choosing to make encrypt() a generic
encrypt operation, it would be an inappropriate API to suggest that all
modes are capable of processing associated data or utilize a nonce (for
example, the "raw AES case").

If we'd adopted a design which saw concrete objects for algorithms, such as
window.crypto.subtle.aes_gcm, this might have been viable, but we did not.
Additionally, taking a dictionary of dependent parameters is consistent
with the JS generic approach.


>
>
>
> Section 17 (algorithms):
> ----------------
> (1) I know you warned me about this, but the use of the words "Recommended
> algorithms" is somewhat confusing, especially since the list includes
> several weak algorithms.     Any chance the section can be titled
> "Recommended algorithms for backwards compatibility" ?
>

Yeah, that's already a raised issues.


>
> (2)  IDL and operations for DH and ECDH should be almost the same, but
> currently they are quite different.
>

In what way are you suggesting normalizing them?

Is the thought to allow callers the full ability to specify X9.62
Parameters (namely, either EC Parameters OR a named curve?), the former
taking prime modulus, coefficients for a and b, X and Y curve point
coordinates, the order N, and the optional co-factor? Alternatively, taking
M (degree of field), k1/k2/k3 (trinominal/pentanomial basis polynomial
parameters), a, b,, x, y, order, and optional cofactor?

MICROSOFT: This would theoretically allow for out-of-the-box support for
things like the brainpool curves, but the lack of this degree of
specificity was intentional, as some notable APIs (for example: CNG, as
used by Windows) do not support such specifications, and only support the
NIST curves of P256/P384/P521.


>
> (3)  I didn't see access to Raw-AES.   There are cases where that is
> needed, e.g. for implementing unsupported modes such as SIV and FFX.
>

Yes, although efficiency is going to be a real issue here, since it would
require creating a new Promise (and potentially a new Key) for every
operation.

>From a design perspective, if there is interest in some algorithm, then it
should be an exercise to specify the parameters for SIV or FFX. However,
considering that the basic premise of this WGs work is that you can't do
*secure* polyfills of a number of algorithms, I'm a bit mixed on the notion
that a Raw-AES operation would really improve the situation for SIV/FFX.


>
> (4)  It is likely that there will soon be a need to extend the list of
> curves for ECDH and ECDSA.   How would this affect the design?
>

>From a named perspective, it shouldn't.

>From an interop perspective, for the reason tagged as MICROSOFT above, it
seems unlikely that it would be uniformly implemented by user agents.

Still, it "costs nothing" to specify the parameters.


>
> (5) Why is AES-CFB on the list?
>

For the same reasons given for SIV/FFX above.


>
> (6)  For PBKDF2, should some guidance be given as to how to choose the
> number of iterations?    If developers set it too high it may be too slow
> on slow user agents.   If they set it too low to accommodate all user
> agents it will hurt security.
>

I'm mixed on providing implementation guidance, as this has been discussed
at great length on the list.

Without concrete recommendations, we quickly descend into the "You should
understand cryptography before using X", which is the whole point of
window.crypto.subtle to begin with.


>
> (7)  Should signatures with message recovery be supported?    (e.g.
> SR-RSA-PSS)    I'm guessing that answer is no, but wanted to bring it up.
>

Where is SR-RSA-PSS even specified? RFC 3447 only covers the RSASSA-PSS
case, since it's based on the hash function underlying the EMSA-PSS op. Are
you thinking ISO/IEC 9796-2:2002 / 2010? Is there even a freely-available
standard for discussing this mode?


>
>
> Section 19.2:
> --------------------
> I would encourage the authors to not give AES-CBC as example code.   This
> should be changed to AES-GCM.   AES-CBC should not be used for encryption.
>

Fair point, in that it would appear at this time that all implementations
will support AES-GCM (this was actually an open question at time of
drafting the example).