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

Watson Ladd <> Thu, 27 August 2015 20:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 170F51A6EFB for <>; Thu, 27 Aug 2015 13:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bfrQ9NzuZsXY for <>; Thu, 27 Aug 2015 13:37:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7FBC1A1BEC for <>; Thu, 27 Aug 2015 13:37:19 -0700 (PDT)
Received: by wicne3 with SMTP id ne3so3219442wic.0 for <>; Thu, 27 Aug 2015 13:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Bh2D71d8AjdQZatoe+8HEbGe3KJAh9OB7hblbkK5ms=; b=t4PhkEex6cGMOA9tgF5iCdZZdiX6guvTamvNR0/qZ/g/Vtf3UYz85e9R9Cdq+c3N4P nJs7uf1KSC6T4nXAD5Q2cSLOdU78/jJTy9O6lG2g4e4XLAjPXjCA0HIrhPpblidJGUWh P1cTp5xy7Zg3LqvN1pt0yFLg8R8Jko98A5DafX7o8cLDsyFEo8zGL4YTWqFUBJiN/t5a Xu4AOAmYDp723hHyGD7TA4Gwl+c7N0twu8r0UZTUjmqKeyYS9MwbiOGDO3EcSOc0EZfo tV9cu4iLtvwegR1yBgva2YuyvbUQaOVNI+ffF5AspTUYLpKnah07jNkqrSiLUKl19YiK lpUw==
MIME-Version: 1.0
X-Received: by with SMTP id z4mr497549wij.30.1440707838497; Thu, 27 Aug 2015 13:37:18 -0700 (PDT)
Received: by with HTTP; Thu, 27 Aug 2015 13:37:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <20150826055240.GD13302@localhost> <>
Date: Thu, 27 Aug 2015 16:37:18 -0400
Message-ID: <>
From: Watson Ladd <>
To: Stephen Farrell <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
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: Thu, 27 Aug 2015 20:37:22 -0000

On Wed, Aug 26, 2015 at 2:42 AM, Stephen Farrell
<>; wrote:
> Hi Nico,
> On 26/08/15 06:52, Nico Williams wrote:
>> 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.
> I'm sorry but you're entirely ignoring the use of RC4 in the web
> which was a very important part of this. While there may be a rump
> of smtp servers that are broken and that won't upgrade soon, there
> was a very large proportion of the web using RC4 before we deprecated
> it, and now there is far less, with no breakage. (See Richard's
> presentation at saag in Prague.) That change wasn't caused by us, but
> we did the right thing to help it along with RFC7465.

Did we actually disable RC4 across the web? A closer investigation
reveals all the attacks will still work after the latest round of
browser changes: one just needs to forge a single packet to break the
first connection, until the browser incorrectly learns RC4
intolerance. Claims that only a small fraction of connections are
using RC4 miss the mark: the question is how many connections can be
fooled into using RC4.

At what point can we remove the code from OpenSSL? That's the endpoint
we should be aiming for.

> Another of the lessons of OS (or rather, of more seriously considering
> deployment realities) is that we sometimes need to think outside our
> own silos. That goes for mail folks and web folks and others too.
> (I'm not saying you're one or other of those, but your mail was very
> silo-specific.)
> S.
>> Nico
> _______________________________________________
> saag mailing list

"Man is born free, but everywhere he is in chains".