W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2013

Re: Dan Boneh's comments

From: Harry Halpin <hhalpin@w3.org>
Date: Tue, 22 Oct 2013 18:51:14 +0200
Message-ID: <5266AD02.6060002@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Dan Boneh <dabo@cs.stanford.edu>

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?


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).
Received on Tuesday, 22 October 2013 16:51:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:19 UTC