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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 25 August 2015 16:55 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 EEC3B1A9071 for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 09:55:42 -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 l14KtNvwreJT for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 09:55:41 -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 5172E1A9064 for <saag@ietf.org>; Tue, 25 Aug 2015 09:55:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3422F284B69; Tue, 25 Aug 2015 16:55:40 +0000 (UTC)
Date: Tue, 25 Aug 2015 16:55:40 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150825165539.GL9021@mournblade.imrryr.org>
References: <20150728053035.GR4347@mournblade.imrryr.org> <CAHbuEH7B3_G9vAhw=U2tuz-Uh8mKMUfL6s=H+BOG96FDZaACig@mail.gmail.com> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55DC961A.903@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/7dVFGVUzwhms35y2XNgm6xbqHlo>
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: Tue, 25 Aug 2015 16:55:43 -0000

On Tue, Aug 25, 2015 at 05:21:46PM +0100, Stephen Farrell wrote:

> > In any case, whether it is RC4 now, or some other deprecated
> > ciphersuite in the futre, with opportunistic security one needs to
> > pay more attention to what interoperates than what is unequivocally
> > strong.  The goal is as much security as can be realistically had,
> > not "all or nothing".  I like to make an analogy with vaccination,
> > we're protecting the infrastructure as a whole, rather guaranteed
> > security for a particular flow.
> 
> Do you agree though that there are at least two points in time
> involved when considering weakened or suspect ciphers?
> 
> There is the time you're discussing of when the bad algorithm
> can be turned off without damaging interop of ciphertext form
> packets.

Yes.

> But there is also the time after which one considers that all
> such ciphertext will in a short while be almost the same as
> plaintext for a capable attacker.

That could happen.

> And the latter can happen before the former.

Possibly.  More realistically I see multiple milestones (in some
order):

    1. Cipher becomes known weak.
    2. Cipher known not much stronger than cleartext.
    3. Cipher no longer required for interop.
    4. Cipher is not MTI and is rarely used.

With OS in Postfix, I'm willing to deprecate some ciphers once we
have 3 and 4, in some cases even before 1 and 2.  For example, I'm
considering by default not enabling DSS, fixed DH and fixed ECDH.
And have already posted a best-practice guide to the users list
advising users to do that.

> My argument (for which I still think I'm in the rough) is that
> when we get to that 2nd point in time, one ought no longer use
> a cipher even in OS mode.

Introducing negotiation failures in OS, and requirement to support
cleartext fallback in is problematic.  Even if some ciphersuite is
effective a NULL cipher, it is better to negotiate that without
introducing a fallback dance.

> And yes, that does mean that some packets will be sent in
> clear that would otherwise not be, but it also means that some
> software will be updated sooner and hence other packets will be
> sent as better ciphertext.

The nasty part is that cleartext fallback is not always desirable
or available.  Sendmail IIRC does not fall back after STARTTLS
handshake failure.

> (And btw: In the specific case of RC4 the IETF does have consensus
> to deprecate that already [1], even if the mail community let that
> go by while pretending it wasn't happening:-)

We're aware of the RC4 deprecation, and use of RC4 is declining,
we're just going to take a couple of years longer to get there.

-- 
	Viktor.