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

ianG <> Tue, 28 July 2015 00:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24E491A1AE1 for <>; Mon, 27 Jul 2015 17:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jjBka2AjKr_A for <>; Mon, 27 Jul 2015 17:57:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4303F1A1ADF for <>; Mon, 27 Jul 2015 17:57:19 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id 766DA6D7C4; Mon, 27 Jul 2015 20:57:17 -0400 (EDT)
Message-ID: <>
Date: Tue, 28 Jul 2015 01:57:16 +0100
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <20150727194020.GD15860@localhost>
In-Reply-To: <20150727194020.GD15860@localhost>
Content-Type: text/plain; charset=windows-1252; format=flowed
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: Tue, 28 Jul 2015 00:57:21 -0000

On 27/07/2015 20:40 pm, Nico Williams wrote:
> On Sat, Jul 18, 2015 at 10:30:19AM +0200, Kathleen Moriarty wrote:
>>> On Jul 17, 2015, at 7:18 PM, Stephen Farrell <>; wrote:
>>> 2.9: I'm not really a fan of blessing weaker algs for OS, but I lost
>>> that argument before. I wonder if we would get consensus if this
>>> said that weak algs are better than no encryption but still MUST be
>>> deprecated as soon as feasible?
>> I don't think we've really debated this enough to get consensus.  I
>> don't think weaker algs fit into our agreed definitions for OS.  I
>> just recall your debate with Pete on another draft, but think a wider
>> debate is needed to see what the consensus is.  I don't think weaker
>> algorithms should fit into the definition.
> If OS means "upgrade from cleartext when you can" (it does), then
> failing to use weak crypto -> fallback on cleartext.

Right.  Dumb.  In popular parlance, cutting off your nose to spite your 

> Even using 1DES is better than cleartext: because if everyone were using
> 1DES then the cost of massive eavesdropping (gather ciphertexts,
> cryptanalyze) goes up significantly.
> The key thing is that weak crypto must not lead to real-time exploitable
> downgrade attacks.

(I don't see that how that is possible?  Only weak protocols - with 
complexity or config or confused sysadms - can lead to a downgrade attack.)

> Now, perhaps OS should mean "upgrade from cleartext when you can, but
> fail if weak crypto is selected" (i.e., no fallback on cleartext).  But
> then we have to have two OS definitions, one for SMTP, and one for other
> protocols: because after all we do want [some, e.g., to postmaster]
> e-mail to flow no matter what.  And even so, remember that the user
> would gladly use no crypto if none is offered, so I don't think this
> makes sense.

Right.  Much as we might be offended at weak crypto like DES1, it is 
better than plaintext.  And it makes no sense to ban DES1 in an OS 
system when the alternates are a binary of {nothing,full}.

If an OS system can be attacked with an MITM because it is, at the end 
of the day, OS, then trying to force unbreakable crypto is missing the 

> Think of OS as a migration strategy.  If we make the jump from cleartext
> to encrypted too difficult/expensive, then we'll fail to complete the
> migration.  Spurious failures resulting from attempting to upgrade could
> mean failure to migrate: because users will simply turn off OS.  Yes, OS
> could be required-to-be-enabled, thus preventing this social failure
> mode, but we're still far from that.

It is much easier to upgrade weak crypto to strong crypto than to 
upgrade plaintext to any crypto.  It is much easier to first upgrade to 
OS, and then as a second step upgrade to stronger protocols such as 
non-OS with non-weak crypto.

> Permitting weak crypto (with the above downgrade caveat) with OS is
> rather necessary then.  We can only forbid weak crypto in OS
> applications when the market share of such crypto is negligible.

Even then, the only reason to ban an algorithm is to reduce support 
costs.  It's not like say full scale TLS where we are making a claim 
that the stuff is strong, and properly implemented, there are ZERO 

If OS is always a half-way house, we don't care that much about which 
wall falls down - the crypto or the auth.  Let market forces push the 
upgrade to newer versions.