RE: feedback from CFRG

Dear all,

On Ryan suggestion to avoid listing all the problems associated with algorithms : +1

On Ryan suggestion to write down 'structural clues' in the spec : could you please detail to which extend ? and can we have already a volunteer to write it ?

I am adding a suggestion to have our specification to include a paragraph to tell the reader that there are some great groups which job is to discuss value of algorithms and those one do maintain the state of the art in crypto, and give pointers to those groups.

Regards,
Virginie

Ps : Thanks to zooko for bringing back us great comments :)

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: vendredi 21 septembre 2012 01:05
To: Zooko Wilcox-OHearn
Cc: public-webcrypto@w3.org
Subject: Re: feedback from CFRG

On Thu, Sep 20, 2012 at 8:23 AM, Zooko Wilcox-OHearn <zooko@leastauthority.com> wrote:
> Folks:
>
> Below is the first response I've received from my asking the CFRG for 
> feedback. The authors are accomplished cryptographers with many 
> publications in the field of cryptography, including several 
> publications that take break existing standards by taking advantage of
> PKCS#1 v1.5's weakness. Note well that they offer to write some text 
> for us! I suggest we take them up on that offer.
>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.com
>
> ------
>
>
> From: Tibor Jager <tibor.jager@gmail.com>
> Subject: Re: [Cfrg] call for review: Web Cryptography API
> Date: Thu, 20 Sep 2012 16:14:57 +0200
> Cc: Kenny Paterson <Kenny.Paterson@rhul.ac.uk>,  Juraj Somorovsky 
> <juraj.somorovsky@rub.de>
> To: zooko@zooko.com
>
> Dear Zooko,
>
> we received your request to review the Web Cryptography API Spec. We 
> would like to provide some comments that you may hopefully find 
> helpful.
>
> We noted that the standard contains some legacy crypto algorithms, 
> which have well-known serious weaknesses but are (unfortunately) still 
> widely used. These weaknesses frequently lead to attacks on systems 
> that naively use these algorithms.
>
> For instance, several works [Ble98,BFKST12,JSS12, ...] demonstrate the 
> vulnerability of RSA PKCS#1 v1.5 to variants of Bleichenbacher's 
> attack in various (practical and widely-used) applications. Using
> PKCS#1 v1.5 in a secure way is highly non-trivial and often 
> impossible, in particular in Web-based applications. Moreover, it is 
> known that the pure availability of PKCS#1 v1.5 encryption may also 
> spoil the security of other algorithms, like RSA-OAEP or
> RSASSA-PKCS1-v1_5 signatures.
>
> Similarly, unauthenticated block-cipher modes of operation, like CTR 
> and CBC, have in the past been shown to enable "padding-oracle"-like 
> attacks, for instance in [Vau02,DR'10,DR'11,JS'11,AP'12, ...]. These 
> modes of operation should not be used without additional security 
> measures. An appropiate measure is a message authentication code, 
> which should be computed over the ciphertext and must be verified by 
> the receiver.
>
> Actually we would like to recommend that these legacy ciphers are 
> removed from the standard. While in some special cases countermeasures 
> against the known attacks are possible, implementing these is highly 
> non-trivial and error-prone, thus much harder than implementing new 
> libraries supporting secure algorithms. Even worse, in many examples 
> there exists no countermeasure.
>
> However, we understand that this may be impossible, for instance due 
> to interoperability reasons. If these weak algorithms are not removed, 
> then we recommend that at least a section is added to the spec, which 
> mentions the problems with these legacy schemes and recommends 
> preferable choices of algorithms. This would serve as a code of 
> practice for developers, which are not familiar with the most recent 
> literature on attacks in applied cryptography.
> If you are interested, we could provide a draft of this section.
>
> Kind regards,
> Juraj, Kenny, Tibor
>
>
> [Ble98] Daniel Bleichenbacher. Chosen Ciphertext Attacks Against 
> Protocols Based on the RSA Encryption Standard PKCS #1. CRYPTO 1998.
>
> [BFKST12] Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo 
> Simionato, Graham Steel, Joe-Kai Tsay. Efficient Padding Oracle 
> Attacks on Cryptographic Hardware. CRYPTO 2012.
>
> [JSS12] Tibor Jager, Sebastian Schinzel, Juraj Somorovsky.
> Bleichenbacher's Attack Strikes again: Breaking PKCS#1 v1.5 in XML 
> Encryption. ESORICS 2012.
>
> [Vau02] Serge Vaudenay. Security Flaws Induced by CBC Padding - 
> Applications to SSL, IPSEC, WTLS .... EUROCRYPT 2002.
>
> [DR'10] J. Rizzo T. Duong. Practical Padding Oracle Attacks. Black Hat 
> Europe 2010 and USENIX WOOT 2010.
>
> [DR'11] Thai Duong, Juliano Rizzo. Cryptography in the Web: The Case 
> of Cryptographic Design Flaws in ASP.NET. IEEE Symposium on Security 
> and Privacy 2011.
>
> [JS'11] Tibor Jager and Juraj Somorovsky. How to break XML Encryption.
> ACM CCS 2011.
>
> [AP'12] N.J. AlFardan and K.G. Paterson. Plaintext-Recovery Attacks 
> Against Datagram TLS. NDSS 2012.
>

Thanks for forwarding this along, Zooko.

I feel like this is similar to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18925 , and appreciate their feedback and think we should address it there. While not wanting to reject the offer for assistance, I think it's equally important that we do endeavor to keep the spec readable and maintainable, as I highlighted in http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Sep/0021.html
.

For example, I think we might be able to accomplish some shifting in how algorithms are structured in the document, and move "problematic"
algorithms into a distinct section, but I do not think it would be necessary or appropriate to enumerate all of the individual concerns with the algorithm, nor am I convinced that moving into a special namespace or naming scheme (window.crypto.weak, for example) would be a good thing. If the premise of such text is to protect developers from using algorithms "incorrectly", then I think structural clues should be sufficient to highlight these concerns, and that no amount of explaining *why* it is incorrect will be of further assistance to such developers.

My concern is that I do not believe this draft should become a general catch-all document for algorithm-specific security concerns for every algorithm implemented - I think that's better met by the excellent and ongoing work of the CFRG in
http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-00 . To the extent possible, and no doubt this will certainly be taken out of context, I'd like to try and provide as much as a "value neutral" API as possible, and leave discussions about the values and merits of individual algorithms to the individual protocols and applications (for example: JOSE's discussion of AEAD ciphers, TLS WG's discussions on ciphersuites, CA/B Forum's discussions on signature algorithms and
requirements)


To respond specifically to the suggestion that such algorithms should be entirely removed and not supported, and to address your point about whether or not ECB should be included at all, I will start a separate thread and appropriate issue, so that it can be followed-or-filtered.

Received on Monday, 24 September 2012 08:32:14 UTC