Re: Dan Boneh's comments

Dan,

Can you look through this response to your comments from the Editor (see 
below)? Would you be available for another telecon to discuss on the 
28th if needed?

    cheers,
      harry

On 10/16/2013 03:05 AM, Ryan Sleevi wrote:
> 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 
> <mailto: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).
>