Re: [Cfrg] What crypto algorithm is referenced most in RFCs?

Jon Callas <jon@callas.org> Thu, 16 June 2011 17:11 UTC

Return-Path: <jon@callas.org>
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 CC10111E8190 for <cfrg@ietfa.amsl.com>; Thu, 16 Jun 2011 10:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 hCOCwLPZ7+l8 for <cfrg@ietfa.amsl.com>; Thu, 16 Jun 2011 10:11:02 -0700 (PDT)
Received: from merrymeet.com (unknown [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7C311E814C for <cfrg@irtf.org>; Thu, 16 Jun 2011 10:11:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id E04692E0B3 for <cfrg@irtf.org>; Thu, 16 Jun 2011 10:14:08 -0700 (PDT)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17146-04 for <cfrg@irtf.org>; Thu, 16 Jun 2011 10:14:06 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id E7D182E061 for <cfrg@irtf.org>; Thu, 16 Jun 2011 10:14:06 -0700 (PDT)
Received: from [192.168.100.101] ([166.250.33.170]) by keys.merrymeet.com (PGP Universal service); Thu, 16 Jun 2011 10:10:46 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 16 Jun 2011 10:10:46 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Jon Callas <jon@callas.org>
In-Reply-To: <4DF8627B.1030702@Strombergson.com>
Date: Thu, 16 Jun 2011 10:10:43 -0700
Message-Id: <B50EC09D-5012-4C12-A340-39E7823149C5@callas.org>
References: <4A7C9D3B-70C6-4D14-A5D8-F54D84DBBEA9@cisco.com> <4DF6FCAD.1000704@Strombergson.com> <4DF7E236.3060603@ieca.com> <CF0765AF-383F-423F-A8CC-10AEB4A3E348@callas.org> <4DF8627B.1030702@Strombergson.com>
To: cfrg@irtf.org
X-Mailer: Apple Mail (2.1084)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard
Subject: Re: [Cfrg] What crypto algorithm is referenced most in RFCs?
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: Thu, 16 Jun 2011 17:11:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 
> Jon, I'm sorry for not being more clear. What I was implicitly referring
> to was the lists of active drafts, not RFCs. I agree that for RFCs it is
> more important to look at implementations.
> 
> But the drafts has not yet become the map. Fixing errors in the map to
> be before it is printed isn't that better than waiting until it has been
> printed and in use?
> 
> We basically have two different problems:
> (1) Help implemementations to migrate from algorithms we don't trust
> anymore to the algorithms we trust, algorithms specified in updated
> versions of the map.
> 
> (2) Help map developers avoid specifying use of the bad algorithms so
> that new implementations don't end up using bad algorithms in the first
> place.

Absolutely!

These days it's very easy to pick a good set of building blocks. There are also plenty of things that are mostly okay, but you shouldn't use for new protocols. In the protocol process, it's relatively easy to make sure you're only using the good ones, and for anyone who isn't, we can point out what to do.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFN+jkWsTedWZOD3gYRAhbPAKDIPfun9JMoLcvFpipR7Zr7cQa+AgCgwECs
mx3l7q0yjofbfBkz+0Bx4TE=
=a+WE
-----END PGP SIGNATURE-----