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

Nico Williams <nico@cryptonector.com> Wed, 26 August 2015 05:52 UTC

Return-Path: <nico@cryptonector.com>
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 230231A01FA for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 22:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level:
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 JsIedn9cQFu1 for <saag@ietfa.amsl.com>; Tue, 25 Aug 2015 22:52:46 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52F481A001D for <saag@ietf.org>; Tue, 25 Aug 2015 22:52:43 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D662BB8094; Tue, 25 Aug 2015 22:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=g1i6ocmp+cXdgp mzT/tkujmWdJM=; b=BldvqHvQ6pT1frIfWPIj1G3Tc9z0UOq0otcVyBXihZya8Z 0ahTC01rBvY68RAtwa4ZW6dD2NYId4fn8EWg0k0vyEP3VnbIkLISAfg1NpDstHnR OaZDulB8gXr0lllA3jiD/bBTsvquWoEvo//yBmiDqJJ/oMDiwIS4T4Q4SVBu0=
Received: from localhost (unknown [38.125.52.165]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 72065B8086; Tue, 25 Aug 2015 22:52:42 -0700 (PDT)
Date: Wed, 26 Aug 2015 00:52:41 -0500
From: Nico Williams <nico@cryptonector.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20150826055240.GD13302@localhost>
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.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/WO5SCg5YR-Qby0VR7U452XP8Ipk>
Cc: saag@ietf.org
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
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: Wed, 26 Aug 2015 05:52:53 -0000

On Tue, Aug 25, 2015 at 05:21:46PM +0100, Stephen Farrell wrote:
> On 25/08/15 17:06, Viktor Dukhovni 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.
> 
> 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.
> 
> And the latter can happen before the former.

We've been pwned, so we want that to stop, and the way we're choosing to
make it stop is to shoot ourselves in the feet.

Less rhetorically:

We know RC4 is weak and we want to use something else that's better
instead.  Clearly, we can ban RC4, but that isn't a magic wand that
makes everyone start using AES or what have you.  Still, we plow on
because hey, some TLS implementors will understand the SMTP OS situation
and won't break that application.  But! if we merrily write text telling
TLS implementors to remove RC4, many of them will, and in the process
they will make security/interop for SMTP demonstrably worse (as Viktor
has shown).

It seems we can't be moderate in how we approach cipher obsolescence,
perhaps because... we're embarrassed to have obsolete ciphers around so
long after they became obsolete?  That's not a good excuse for throwing
a big switch.  A good excuse for throwing the switch is any case where
merely offering weak crypto introduces a downgrade attack, but that's
not the case here.

"Look ma'!, we banned the bad thing" is clever marketing.  For a short
while.  "Look ma'!, we're getting off the old thing and onto the new,
and we're giving people time so we don't make things worst in the
short-term" is a mouthful and ma' will have to think about it before
deciding that we're doing the right thing, but it is the right thing.

We totally can live with an outright ban on RC4.  That not all TLS
implementors will adhere to.  Or accept the loss of security/interop for
SMTP.  If implementors willfully diverge from the spec, then the spec is
probably wrong.  If implementors faithfully implement a spec, and as a
result applications break, the spec is probably wrong.  The only hope
for an outright ban is that breakage causes people to go fix it.  But
with SMTP OS it's not always clear to users that there's breakage, and
when it is clear (mail won't flow) it isn't always easy to go fix it.

Nico
--