- From: Harry Halpin <hhalpin@w3.org>
- Date: Sat, 16 Mar 2013 00:22:21 +0100
- To: Ryan Sleevi <sleevi@google.com>
- CC: kmigoe@gmail.com, public-webcrypto@w3.org, "David McGrew (mcgrew)" <mcgrew@cisco.com>
- Message-ID: <5143AD2D.90402@w3.org>
On 03/15/2013 08:18 PM, Ryan Sleevi wrote: > > Harry, > > What you refer to as "broken crypto" is *not* a universal. For > example, MD5 hashing is problematic, but HMAC-MD5 is not (though not > recommended, its hardly "broken"). > > Likewise, modes like AES-CBC by itself is problematic, but when > combined with a MAC (and when properly using encrypt-then-mac), CAN be > used securely. > > These are just two examples of the many, many nuances that we *SHOULD > NOT* be specifying. Nor is it reasonable, I think, to insist that we > hold publication until such a time as another group takes on that > Sisyphean task. Further, I would even go as far as to suggest that > doing so, in this API (directly or even as an informational reference) > would be *actively harmful* to the development community, as it would > be seen as an endorsement for the design of new cryptographic > protocols by unskilled cryptographers. > Yes, of course per-algorithm security considerations are complex, but some algorithms have very well-known weaknesses and are not recommended in general by the cryptographic community. The email from CFRG did a good job bringing some particular issues with some of the algorithms in our spec up. Again, I am not saying we hold publication for such a per-algorithm security document to exist. However, if such a document did exist, it would be an informative document of great value and pointing to it would satisfy the CFRG review of the WebCrypto API and the other folks in the Twitterverse who are complaining about this issue. Until such a document exists, the Web Crypto WG can not obviously respond to "please don't release known broken crypto" critique from CFRG and others. > > This API *must* support the use case of allowing existing protocols to > be implemented, and flexible enough to allow implementations of new > protocols like JOSE, but we must not pretend like we are encouraging a > free for all or naively trying to suggest that if you just knew X and > Y, you could design some new and arbitrary protocol and have it be > secure. This is exactly the message I feel your proposal will send, > because it will be by definition incomplete, which is why I continue > to object to making this a requirement. > I think pointing to documents pointing out weaknesses does a much better job of preventing a "free for all" than not addressing per-algorithm security considerations without an informative link. Naive WebApp programmers *will* use this API whether we encourage them to or not in some informative text, and thus it is a good thing to at least have a pointer to a place they can ask questions and have questions answered. Developers are *already* asking this question about the API [1]. The only problem would be if the informative document linked to from the spec was incorrect and/or not maintained, which is why a long-lived group such as CFRG might be a good group to take this on, if they have time/energy. All informative documents will be incomplete in some sense of course, but we can limit its incompleteness by asking the CFRG not to maintain such considerations for all algorithms, but only for those listed in the WebCrypto API Rec. Right now, that's a finite list - and some ala SHA-1 that are in our spec do have quite known per-algorithm security considerations. Thus, we can respond to Tibor Jager (who already volunteered to help write text) by saying "Yes, please write some text on the WebCrypto algorithms, do in a separate CFRG doc and we'll link to it informatively in the API" rather than saying "thanks for the feedback, but only cryptographers who already know these details should use the API." [1] http://crypto.stackexchange.com/questions/3850/is-rsassa-pkcs1-v1-5-a-good-signature-scheme-for-new-systems > On Mar 15, 2013 1:10 PM, "Harry Halpin" <hhalpin@w3.org > <mailto:hhalpin@w3.org>> wrote: > > On 03/15/2013 06:06 PM, Ryan Sleevi wrote: > > On Fri, Mar 15, 2013 at 10:02 AM, Harry Halpin <hhalpin@w3.org > <mailto:hhalpin@w3.org>> wrote: > > On 03/15/2013 05:52 PM, Ryan Sleevi wrote: > > David, > > I understand you weren't able to make it to the > Security Area Activity > Group (SAAG) meeting at this past IETF 86 in Orlando, > where I gave a > presentation on the W3C Web Crypto API - > https://datatracker.ietf.org/meeting/86/agenda/saag/ . > The minutes for > SAAG are not up yet, but this will include copies of > the presentation > given, which discusses the present API, the problems > it presently > tries to solve, and some of the concerns and > non-concerns with the > API, as well as active points of discussion within the WG. > > Harry's point of including security considerations on > a per-algorithm > level is, respectfully, not one I agree with. While I > am certainly > passionate for better security, I think that the set > of API security > considerations, which this group is tasked with > delivering, are very, > very distinct from a set of algorithm considerations. > Further, in my > experience, it has never been sufficient to simply > understand > individual algorithm considerations, but it must be > examined how the > overall protocol works and combines algorithms, and > the assumptions > made and attacks anticipated. This is why I view > Harry's request as > not being a reasonable request - there are too many > combinations and > protocols that may be used, and their security only > comes from > understanding the overall goals of the system. The > expectation that > including individual considerations leads to better > code is, in > practical terms, not realistic. > > > Note that I am not asking for a complete security guide - > that's obviously > unreasonable. However, I also think it's equally > unreasonable to hand-wave > about security concerns without giving users of the API a > place to even go > to for answering their questions about security concerns.. > Giving WebApp > developers the right set of links to learn more is useful > and a service to > the vast majority of web app developers who may want to > use crypto. > > The official CFRG review said "please don't ship broken > crypto." I agree > with Ryan that determining security considerations on a > per algorithm basis > is both 1) complex and 2) out of scope for the Web Crypto > WG. However, if > another group like CFRG wished to tackle this, I think it > would be good to > point to such a CFRG document. While sometimes things are > complex, sometimes > (ala hashing functions MD5,SHA-1, not rocket science) they > are not. The > feedback from CFRG already went into in the algorithms > available in the API, > but that was not a public and maintained document. > > Again, Ryan - please do not mix this up - I am *not* > asking for the security > considerations to be done in the Web Crypto Spec. > Security considerations > should *not* be done in the Web Crypto API document itself. > > Respectfully, I disagree. Our spec MUST deliver security > considerations - but of the API. > > > That is a separate topic from the per-algorithm considerations, > but yes, if someone feels they can draft that adequately, I'm sure > no-one in the WG would disagree with having something included > about algorithm considerations. > > > Security considerations about algorithms should not be in the > spec, I > think we both agree. However, I think normatively referencing > other > documents is a bad idea, because there is no comprehensive set. It > would be as if WebGL attempted to normatively reference > performance > guidelines for 3D operations, or the HTML spec for forms > attempting to > describe CSRF. > > > I was not talking about "normatively" referencing other specs, but > *informatively*. That was mentioned earlier in email and makes a > big difference. Right now we say "please look at wider > cryptographic literature" :) > > Normatively referencing something that can change is not a good > idea, so thus we won't do it. Informatively referencing is in > general a good idea and relatively easy to do. > > > > That is, I view the security of algorithms to be a piece of domain > specific knowledge relevant to the development of > applications, and > NOT an intrinsic property or requirement of the API to deliver or > reference. > > > Again, this is very domain specific but there are well known > "broken crypto" that our API is supporting as the CFRG noted in > their review, and thus being clear about this in a link to > informative document I think is enough to satisfy their review and > that relatively common criticism. I hope :) > > > Instead, we > could point to another document that can be kept > up-to-date by *another* > group, if such a group can be fund that has the time and > energy. So far, it > is pretty clear such a document does not exist and thus we > cannot be blamed > for not pointing to it as an informative reference. > > > > This view of combinatorial complexity - and how > security concerns > apply to both combinations and individual algorithms - > is a similar > view that was expressed by a number of participants > during the IETF > JOSE WG during IETF 86, in the discussion of using > AES-CBC + HMAC in > an AEAD mode, as well as the discussion of KDFs. > Understanding > algorithms in isolation is useful, but security > considerations really > come through their combination - and this API allows > for a number of > combinations - out of necessity of supporting a number > of applications > and security considerations. > > A full treatise of the topic begins to look something > like Ross > Anderson's excellent "Security Engineering" book ( > http://www.cl.cam.ac.uk/~rja14/book.html > <http://www.cl.cam.ac.uk/%7Erja14/book.html> ), in > which whole systems are > examined - and then broken down by their attacks and > weaknesses. And > begins to look as thick - and as complex. > > On Fri, Mar 15, 2013 at 9:31 AM, David McGrew (mcgrew) > <mcgrew@cisco.com <mailto:mcgrew@cisco.com>> > wrote: > > Hi Ryan and Harry, > > On 3/15/13 11:35 AM, "Ryan Sleevi" > <sleevi@google.com <mailto:sleevi@google.com>> wrote: > > In discussions with others at IETF, this is > not something that the > CFRG tries to provide. > > That is, the CFRG helps provide input and > design, particularly around > the design of *new* protocols. This is not a > suitable overlap with > what you want - which is development guidance > for the use of > particular algorithms. > > The CFRG cipher catalog, which you have > previously requested to > reference, is entirely in the context of > discussion of ciphers *in use > by standard protocols*. You do not, for > example, see discussions of > OTR/mpOTR. > > Focusing on ciphers defined in IETF documents, or > referenced in IETF > documents, was a good way to keep the scope of the > cipher catalog > document > from getting too big. > > Respectfully, a "how to be a cryptographer" is > not a good activity. > > On Fri, Mar 15, 2013 at 8:10 AM, Harry Halpin > <hhalpin@w3.org <mailto:hhalpin@w3.org>> wrote: > > If so, it may be useful to discuss with > them their feedback (via Zooko) > to > the API. > > I have thought, and this came up in an > OECD discussion with the IETF > chair, > that per-algorithm security considerations > *in a separate RFC* might be > a > good idea. Note this is a separate > conversation than the registry, but > would > address their comments by putting the ball > back in their court, so to > speak. > > Then our API can point to their RFC, which > they can then keep updated > as > long as the CFRG runs. Did the CFRG > discuss this, or the API, at all? > > As CFRG co-chair, I would welcome input and > questions from webcrypto, > either as a presentation to an upcoming meeting, > or as an internet draft. > We need to keep things scoped, of course, but > discussion of crypto APIs > seems worthwhile to me. At least, it seems to me > that it should be > possible to come up with a presentation/discussion > on that topic that > would be of broad interest to the Internet crypto > community. What do > you > think? > > In my opinion, it would be useful to have an API > for authenticated > encryption that is higher level than RFC5116, > which hides as many > implementation details as possible from the user. > This effort could > potentially be aligned with the CAESER submissions > http://competitions.cr.yp.to/ I am not sure how > well this lines up with > the needs of webcrypto, though. And for sure it > just focuses on a small > subset of the API security issues. > > Copied Kevin (CFRG co-chair). > > David > > cheers, > harry > > > >
Received on Friday, 15 March 2013 23:22:32 UTC