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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 July 2015 21:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBE31B3478 for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 14:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrdWdD1FfCtj for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 14:14:44 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D021B345E for <saag@ietf.org>; Mon, 27 Jul 2015 14:14:43 -0700 (PDT)
Received: by mournblade.imrryr.org (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 <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150727211442.GM4347@mournblade.imrryr.org>
References: <55A938F1.9090404@cs.tcd.ie> <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com> <20150727194020.GD15860@localhost> <55B68C8A.3080006@cs.tcd.ie> <20150727203136.GL4347@mournblade.imrryr.org> <55B69908.2030803@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55B69908.2030803@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/VUiJaHeSlob8XSMw0epfv53CW0Y>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=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
spuriously).

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.

-- 
	Viktor.