W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: feedback from CFRG

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 20 Sep 2012 16:04:44 -0700
Message-ID: <CACvaWvZeKjJ99syx-LwHkOhwy0_tK9ZLaFaZo4SoiW6iV8L1ug@mail.gmail.com>
To: Zooko Wilcox-OHearn <zooko@leastauthority.com>
Cc: public-webcrypto@w3.org
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 Thursday, 20 September 2012 23:05:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2012 23:05:15 GMT