[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [173.230.137.215]) 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 [209.85.215.182]) (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 10.14.209.129 with SMTP id s1mr24701397eeo.24.1349728982598; Mon, 08 Oct 2012 13:43:02 -0700 (PDT)
Received: by 10.14.2.194 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 sessions.) 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 issue? (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. Regards, Zooko ¹ 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-00 ⁴ http://owasp.com/index.php/Glossary#Electronic_Code_Book_mode
- [Cfrg] general guidance for web programmers? Zooko Wilcox-O'Hearn
- Re: [Cfrg] general guidance for web programmers? David McGrew (mcgrew)