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

Nico Williams <nico@cryptonector.com> Mon, 27 July 2015 21:29 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 3BE861A0117 for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 14:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ddXmOU6O4qWv for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 14:29:15 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AE82C1ACD19 for <saag@ietf.org>; Mon, 27 Jul 2015 14:29:15 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 4FB3F2AC081; Mon, 27 Jul 2015 14:29:08 -0700 (PDT)
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id CB79D2AC059; Mon, 27 Jul 2015 14:29:07 -0700 (PDT)
Date: Mon, 27 Jul 2015 16:29:06 -0500
From: Nico Williams <nico@cryptonector.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20150727212905.GD29423@localhost>
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> <20150727210616.GC29423@localhost> <55B69F99.6030009@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55B69F99.6030009@cs.tcd.ie>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/mksKGh-F9vj1mUFH6inf4Jkr2MY>
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: Mon, 27 Jul 2015 21:29:17 -0000

On Mon, Jul 27, 2015 at 10:16:09PM +0100, Stephen Farrell wrote:
> On 27/07/15 22:06, Nico Williams wrote:
> > There is no great difference for _one_ connection.  There is a great
> > difference for _many_ connections.  I.e., even weak crypto makes
> > pervasive eavesdropping significantly more expensive.
> 
> Well, I think there's still room for validly reaching different
> conclusions about something like rc4 when we consider the various
> parameters. (None of which we can really measure.)

Really?  The workfactor to cryptanalyze one RC4 session is so close to
2^0 that it wouldn't make a difference even to a pervasive monitor?

> Of course I fully agree with the OS approach, but I think we ought
> recognise this wrinkle - there are going to be cases where it's
> quite hard to do the evaluation of how to apply the OS design
> pattern. 1DES is easy everywhere now, but rc4 for email is not
> yet easy.

The principle is simple and stated earlier.  Again: don't enable a
Logjam attack, and otherwise allow any weak crypto that doesn't cause a
real-time downgrade attack on clients that could do better.  I.e., it's
all about the handkshake's security, not the application record security
(again, because the application would happily use cleartext).

(One counter-argument might be that it's difficult to analyze what
configurations lead to Logjam attacks, therefore better be safe than
sorry.)

Nico
--