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

Viktor Dukhovni <> Mon, 27 July 2015 21:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6DBE31B3478 for <>; Mon, 27 Jul 2015 14:14:45 -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 GrdWdD1FfCtj for <>; Mon, 27 Jul 2015 14:14:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D021B345E for <>; Mon, 27 Jul 2015 14:14:43 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 06190282FB1; Mon, 27 Jul 2015 21:14:42 +0000 (UTC)
Date: Mon, 27 Jul 2015 21:14:42 +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 21:14:45 -0000

On Mon, Jul 27, 2015 at 09:48:08PM +0100, Stephen Farrell wrote:

> Put another way, if we all agreed that rc4 can likely be routinely
> deciphered in N years and if we further agreed that there are a lot
> of plaintexts that will still be sensitive in N years, then there is
> no great difference today between sending cleartext and rc4
> ciphertext, when we consider highly capable adversaries who record
> ciphertext, and we know those exist even if we do not know quite
> how much ciphertext they record, for how long.

There are two differences.  

    1. It seems unlikely that recovery of every captured RC4 stream
    will become practical, even if recovery of targetted streams
    becomes practical.

    2. After STARTTLS, failing to negotiate RC4 when the peer only
    supports RC4 requires "fallback", not just staying with cleartext
    (which happens when STARTTLS is not offered).  Not all peers
    support "fallback", and we want to avoid that anyway.  So if
    dropping (say) RC4 from OS leads to enough undeliverable email
    to make OS unattractive to users, we win the battle, but lose
    the war.

Fallbacks are bad, complicate code, and lead to various new downgrade
attacks.  It is better, to have an interoperable TLS stack, than
one that sets the bar too high, and then tries to recover by moving
it lower (often much lower than necessary and sometimes under

Avoiding "fallback" to cleartext (as opposed to not trying to do
encryption in the first place) is I think a greater priority than
avoiding weak algorithms when one happens to be encrypting.