Re: [Cfrg] general guidance for web programmers?

"David McGrew (mcgrew)" <> Mon, 08 October 2012 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50E981F0C54 for <>; Mon, 8 Oct 2012 14:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.722
X-Spam-Status: No, score=-109.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CdT5KWJ8IFW2 for <>; Mon, 8 Oct 2012 14:47:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 589B21F041F for <>; Mon, 8 Oct 2012 14:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6138; q=dns/txt; s=iport; t=1349732820; x=1350942420; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=er6Kpia508It2Er802NZED4Ni+SThbMrmVFgt1vIHgU=; b=TJ8zW42kbG7rLemzgHEPDFhPaJUcLS1/Rat3CS3jBqfzZTwA1mSxttl0 mi61z/5siNq0CKrQEinG5rvnnd0YdC2FrGOJUK8TUldm9YbEp2miEcjbT 0MO3kwZGAB8azVYyEe+J9D2knIim7p7yjKtbUwr0ZTyor7Jv0tNM1Rpc8 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129550728"
Received: from ([]) by with ESMTP; 08 Oct 2012 21:46:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q98Lkx95013214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 21:46:59 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 16:46:59 -0500
From: "David McGrew (mcgrew)" <>
To: Zooko Wilcox-O'Hearn <>, "" <>
Thread-Topic: [Cfrg] general guidance for web programmers?
Thread-Index: AQHNpZWJ0Fd1zjMn5EOOtQSd77Gl2JewAncA
Date: Mon, 08 Oct 2012 21:46:59 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--50.685500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="euc-kr"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Cfrg] general guidance for web programmers?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Oct 2012 21:47:01 -0000

Hi Zooko,

On 10/8/12 4:43 PM, "Zooko Wilcox-O'Hearn" <> wrote:

>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.

I saw your proposal in the WC WG, and I think it is a good idea.

>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

I like the idea of publishing well-reviewed crypto advice in the form of
RFCs like the cipher catalog.

To my thinking, what is striking about cipher catalog is that it is fairly
limited in scope, yet at the same time it is fairly large.  That suggests
that we need to carefully scope this work and not bite off more than we
can chew.   A comparison of modes of operation seems like it could be its
own RFC.   I think it would be reasonable to include encryption,
authentication, and authenticated encryption modes for block ciphers, as
well has HMAC (which could be thought of as a mode of operation for a hash
function, and at any rate seems to belong in a comparison of
authentication modes).   I would even offer to review this document.

>(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?

Public key algorithms would be another great topic.

Speaking as CFRG co-chair, I would be in favor of these RFCs as long as
each one had a team of authors/contributors, and we can get some people
signed up as reviewers.

>Thanks very much for any help you can offer.

Thanks for the suggestion and the explanation of the WebCrypto WG issues.


>Cfrg mailing list