Re: [saag] AD review of draft-iab-crypto-alg-agility-06

Viktor Dukhovni <> Mon, 27 July 2015 20:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 61C291B33A3 for <>; Mon, 27 Jul 2015 13:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g8V0VCClwG4a for <>; Mon, 27 Jul 2015 13:31:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A918A1B3391 for <>; Mon, 27 Jul 2015 13:31:37 -0700 (PDT)
Received: by (Postfix, from userid 1034) id B0087282FB1; Mon, 27 Jul 2015 20:31:36 +0000 (UTC)
Date: Mon, 27 Jul 2015 20:31:36 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <20150727194020.GD15860@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2015 20:31:39 -0000

On Mon, Jul 27, 2015 at 08:54:50PM +0100, Stephen Farrell wrote:

> According to the above, 1DES and export ciphers would be completely
> out of the question. And rc4 is getting really really close.

The good news is that we don't need to agree on why they should no
longer be supported.  They are weak, and it is not supporting them
has no practical downside.  So they can go regardless of the

I expect that by the time an algorithm supports practical
general-purpose offline plaintext recovery (which is a stronger
attack than the RC4 recovery of fixed plaintexts at fixed message
offsets sent millions of times) it will generally no longer be in
wide use, or will be in the process of rapid retirement.

So one way to put your argument is that if an algorithm goes from
safe to broken unexpectedly quickly and is not already in the
process of being phased out, it should be rapidly supplanted by a
better algorithm, allowing the broken algorithm to be rapidly phased
out, and as it is no longer needed for interop, it can be dropped
by OS clients.

So while we may disagree about what to do with RC4 in OS email
today, I agree that we'd let "export" and SSLv2 stick around longer
than necessary, and so in Postfix we've dropped these and 1-DES
and SSLv3, because we can and therefore should do so in a reasonably
timely manner.