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

Viktor Dukhovni <> Tue, 25 August 2015 17:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 330311AC3B1 for <>; Tue, 25 Aug 2015 10:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ro_73aC1thiE for <>; Tue, 25 Aug 2015 10:39:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F1751AC39E for <>; Tue, 25 Aug 2015 10:39:41 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7BD9A284B56; Tue, 25 Aug 2015 17:39:40 +0000 (UTC) (envelope-from
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: text/plain; charset=us-ascii
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Tue, 25 Aug 2015 13:39:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Kathleen Moriarty <>
X-Mailer: Apple Mail (2.2104)
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: Tue, 25 Aug 2015 17:39:43 -0000

> On Aug 25, 2015, at 12:26 PM, Kathleen Moriarty <>; 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.
> I'm not sure we have consensus and would like to see more opinions as
> to what we collectively think the statements on OS should include.

I thought we reached "rough" consensus on this point during the rather
intensive/extensive last-call discussions of the OS draft.  Specifically,
that even weaker ciphers are better than cleartext, and may need to
continue to be used if that's what it takes.

> I don't think anyone is saying that bad crypto isn't better than no
> crypto, but how we define OS and continue to use the definition may
> matter for algorithm and cipher suite deprecation efforts.  It's long
> been a practice for legacy systems to continue to use deprecated
> protocols, algorithms and cipher suites, but we've said they are not
> in compliance with RFCXXXX.  Do we really want to start down a path of
> saying it's okay because it falls under OS?  I'd rather not.  We would
> get to about the same result, but perhaps we could have more success
> with deprecation transitions if these older options are not 'blessed'.

How to position deprecation is more of a marketing than a technical
question.  I agree that we don't want to dilute the message that
deprecated ciphers should be phased out as quickly as possible.
OS is not a license to indefinitely ignore deprecation.

The key issue is what "as quickly as possible" means.  For OS, it is likely
to mean that the process takes longer, because the relative priorities of
interoperability and security are different than with non-OS designs.

So by all means, publish unequivocal deprecation of RC4, ... but expect
that OS applications will take some time to act on such publications and
rightly so.