Re: [Cfrg] how can CFRG improve cryptography in the Internet?

dan@geer.org Tue, 11 February 2014 05:09 UTC

Return-Path: <dan@geer.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD311A07EB for <cfrg@ietfa.amsl.com>; Mon, 10 Feb 2014 21:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNnKuSe3FG5G for <cfrg@ietfa.amsl.com>; Mon, 10 Feb 2014 21:09:03 -0800 (PST)
Received: from palinka.tinho.net (palinka.tinho.net [166.84.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CFB071A0794 for <cfrg@irtf.org>; Mon, 10 Feb 2014 21:09:03 -0800 (PST)
Received: by palinka.tinho.net (Postfix, from userid 126) id 5D2022280AE; Tue, 11 Feb 2014 00:09:02 -0500 (EST)
Received: from palinka.tinho.net (localhost [127.0.0.1]) by palinka.tinho.net (Postfix) with ESMTP id 5852B2280AA; Tue, 11 Feb 2014 00:09:02 -0500 (EST)
From: dan@geer.org
To: Rob Stradling <rob.stradling@comodo.com>
In-Reply-To: Your message of "Mon, 10 Feb 2014 15:15:57 GMT." <52F8ED2D.4060502@comodo.com>
Date: Tue, 11 Feb 2014 00:09:02 -0500
Message-Id: <20140211050902.5D2022280AE@palinka.tinho.net>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Feb 2014 05:09:05 -0000

 > No-longer-deemed-secure algorithms aren't the only security problems 
 > facing out-of-date cryptographic software.  So why not go one step 
 > further and make the cryptographic software itself expire?


Might I extend this to crypto-in-hardware-in-embedded-systems?

In other words, absolutely all embedded systems must either have a
remote upgrade capability or a not-to-exceed pre-defined lifetime.

Both options are ugly.

--dan