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

Stephen Farrell <> Mon, 27 July 2015 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CBAAA1B3278 for <>; Mon, 27 Jul 2015 14:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEin8iEYT978 for <>; Mon, 27 Jul 2015 14:41:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7163B1B3275 for <>; Mon, 27 Jul 2015 14:41:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D24FBE98; Mon, 27 Jul 2015 22:41:13 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0mD93C79H2Dd; Mon, 27 Jul 2015 22:41:12 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 07BFCBE87; Mon, 27 Jul 2015 22:41:12 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1438033272; bh=UVBXLP30D7kBJLBoGnPAarvfzM3LVAcvjciAYsFfUbk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=z4W5p+Fsjyj8BdO3ZJ+EG190xJu3gIk9PqB0Hc1+E6L+2zx0XJLs7gPlBO2+yo1SM 5GdDoWpPZQAKGm8C7Nn5dHZklbaKDOZq+/cp2FZ9FeztjLvnSwZdiibSVvZ1AXsCx5 T++E+SZkLfm1Sn5XMIkhHoPxGy4nfnHT9A7+85vo=
Message-ID: <>
Date: Mon, 27 Jul 2015 22:41:11 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Nico Williams <>
References: <> <> <20150727194020.GD15860@localhost> <> <> <> <20150727210616.GC29423@localhost> <> <20150727212905.GD29423@localhost>
In-Reply-To: <20150727212905.GD29423@localhost>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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:41:16 -0000

On 27/07/15 22:29, Nico Williams wrote:
> 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?

My concern is that workfactor will be small enough in a few
years that mail traffic encrypted today will be essentially
treatable as cleartext by the most capable adversaries. While
the rc4 encryption will add some cost, I'm concerned that'll
be too small (again, in a few years).

>> 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.)

I don't disagree with you that OS ought not enable logjam.


> Nico