[Cfrg] general guidance for web programmers?

"Zooko Wilcox-O'Hearn" <zooko@zooko.com> Mon, 08 October 2012 20:43 UTC

Return-Path: <zooko@zooko.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4AECC11E80F3 for <cfrg@ietfa.amsl.com>; Mon, 8 Oct 2012 13:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.118
X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id H6OCZfPlwOn7 for <cfrg@ietfa.amsl.com>; Mon, 8 Oct 2012 13:43:05 -0700 (PDT)
Received: from zim.maski.org (zim.maski.org []) by ietfa.amsl.com (Postfix) with ESMTP id F381611E80E6 for <cfrg@irtf.org>; Mon, 8 Oct 2012 13:43:04 -0700 (PDT)
Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zooko) by zim.maski.org (Postfix) with ESMTPSA id E3FA323364 for <cfrg@irtf.org>; Mon, 8 Oct 2012 20:43:03 +0000 (UTC)
Received: by mail-ea0-f182.google.com with SMTP id c10so240981eaa.13 for <cfrg@irtf.org>; Mon, 08 Oct 2012 13:43:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id s1mr24701397eeo.24.1349728982598; Mon, 08 Oct 2012 13:43:02 -0700 (PDT)
Received: by with HTTP; Mon, 8 Oct 2012 13:43:02 -0700 (PDT)
Date: Mon, 08 Oct 2012 14:43:02 -0600
Message-ID: <CANdZDc6wTeJbXU7Z8RxPJNVefTiJ9PYsX7XW9RKiNkEtBmqhrQ@mail.gmail.com>
From: Zooko Wilcox-O'Hearn <zooko@zooko.com>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: [Cfrg] general guidance for web programmers?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2012 20:43:06 -0000

Dear people of CFRG:

I'm participating in the W3C working group on Web Crypto. (By the way,
thank you very much to those who replied to my earlier request for
feedback on the WebCrypto draft.)

An issue facing the W3C working group is how and to what degree we
include guidance about which algorithms are recommended or which are
known to be flawed. The first issue that we face is what to say about
ECB mode. I propose ¹ that the WebCrypto standard include some text
warning that ECB mode is *not* an encryption mode, like CBC and CTR
modes, which can be used to encrypt arbitrary sensitive plaintext.

Others on the WebCrypto Working Group are very reluctant to start
writing down advice of this kind ² , because where will it end? It can
get very complicated. Why should we be the ones who have to explain to
programmers to use SHA-2-256 instead of SHA-1, and how to avoid
length-extension attacks if they're going to use SHA-2-256, and how to
safely use RSA PKCS#1 v1.5, and how to generate nonces, counters, and
IVs correctly, and how strong integrity really is almost always
necessary in addition to confidentiality, and so on.

Anyway, we're not necessarily the experts on all those details, and
new attacks are coming along all the time that we would have to
scramble to integrate into our advice.

So, we have conflicting desires here. On the one hand, we don't want
to attempt to explain everything that needs explaining, but on the
other hand experience shows that simply providing a bare API without
documentation really does lead to the deployment of insecure systems
that compromise people's safety. (See my post to the web-crypto
mailing list ¹ for an interesting recent example in which the design
of the crypto API made the difference between secure and insecure web

Okay, so here's a good solution: the WebCrypto spec can refer to
documents published by some other experts, such as CFRG, which guides
programmers on which algorithms are recommended, as well as what are
the requirements for the use of a given algorithm to secure. I very
much like section 3 of the cipher catalog ³, and I wonder if it would
make sense for the WebCrypto standard to refer to that.

The use of ECB mode itself isn't addressed in the cipher catalog. Are
there other similar publications from CFRG that would address that

(As an aside, I rather like the pithiness of OWASP's take on the
subject ⁴: “This mode should not be used under any circumstances.”.)

What about the dangers of RSA PKCS#1 v1.5? Or at least, a catalog of
public key algorithms which advises one to use safer algorithms in
place of that one?

Thanks very much for any help you can offer.



¹ http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0018.html

² http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0188.html

³ http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-00http://owasp.com/index.php/Glossary#Electronic_Code_Book_mode