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

Viktor Dukhovni <> Mon, 24 August 2015 21:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 896551AD0C6 for <>; Mon, 24 Aug 2015 14:29:10 -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 ptArh9vs4wMJ for <>; Mon, 24 Aug 2015 14:29:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39EC21ACDFA for <>; Mon, 24 Aug 2015 14:29:08 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 60ED4284D64; Mon, 24 Aug 2015 21:29:07 +0000 (UTC)
Date: Mon, 24 Aug 2015 21:29:07 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <20150727194020.GD15860@localhost> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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, 24 Aug 2015 21:29:10 -0000

On Mon, Aug 24, 2015 at 04:31:16PM -0400, Kathleen Moriarty wrote:

> The first sentence in this section counters what Viktor is saying was
> intended in the OS RFC (per this thread), that this provision should
> only apply to legacy systems.  When protocols are designed,
> appropriate crypto should be specified.  Then it is better to use
> outdated rather than nothing later on in deployment cycles.  Others
> added in additional caveats to the general statement, so I don't think
> we really have consensus on this set of points.

Yes.  OS is supposed to enable a transparent "upgrade" from cleartext
to encryption (possibly with peer authentication).

With *legacy* protocols, when negotiating unauthenticated opportunistic
encryption, it is important to not exclude recently obsoleted
algorithms that are still needed for interoperability lest failing
to offer them cause communications failure or needless use of

When designing new protocols, it makes sense to set a realistic
floor that excludes already deprecated crypto, and then not supporting
the obsolete algorithms does not risk failure to communicate or
needless use of cleartext.