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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 26 July 2015 21:26 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419BF1A032D for <saag@ietfa.amsl.com>; Sun, 26 Jul 2015 14:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzVVdm76zRiD for <saag@ietfa.amsl.com>; Sun, 26 Jul 2015 14:26:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4067C1A0242 for <saag@ietf.org>; Sun, 26 Jul 2015 14:26:21 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A2D2282FB1; Sun, 26 Jul 2015 21:26:20 +0000 (UTC)
Date: Sun, 26 Jul 2015 21:26:20 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150726212619.GD4347@mournblade.imrryr.org>
References: <55A938F1.9090404@cs.tcd.ie> <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/GxXgRsfuOEw4BeYSPWUrf72F174>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2015 21:26:24 -0000

On Sat, Jul 18, 2015 at 10:30:19AM +0200, Kathleen Moriarty 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.

What fits into OS is due consideration of interoperability constraints.
When clear text is sufficient, encryption is "desirable" and
authentication is "icing on the cake", it is a shame to resort to
cleartext, (or hard fail and ultimately lead the user to abandon
OS as too much pain for too little gain) just because encryption
might involve the use of tarnished algorithms.

What that all boils down to, is that with existing application
protocols, that are already doing OS (be it by another name), one
should be willing to tolerate tarnished algorithms that are "the
best" that some non-trivial fraction of peers can support at any
given time.

No tarnished algorithm needed for interop should be kept on
life-support in perpetuity.  The expectation is that over time
(somewhat lagging similar changes in mandatory security protocols)
tarnished algorithms also disappear from opportunistic protocols.

For example, opportunistic TLS in Postfix (by default) no longer 
includes support for "export" ciphers, SSLv2, SSLv3 or 1DES.

If and when OS is introduced in new applications or protocols, with
no legacy installed base setting interoperability constraints, no
tarnished algorithms should be accepted.  New protocols should,
if possible, start with a clean slate.  That is, from inception
start by satisfying as many as possible of:

	TLS 1.2 or higher (of course no SSLv2/SSLv3)
	No "export" ciphers
	No 1DES, RC4, IDEA, RC2, ...
	No MD5 or SHA1,
	...

Then as the protocol ages, and more things are deprecated,
interoperability constraints may at a later date mean that
newly tarnished crypto is kept around longer with OS than
otherwise, but only long enough to allow for an orderly
phasing out of the algorithm to the point where negligibly
few peers require continued support.

-- 
	Viktor.