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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 28 July 2015 01:30 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 1913B1A1B82 for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 18:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8IDsTRh1rk5 for <saag@ietfa.amsl.com>; Mon, 27 Jul 2015 18:30:22 -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 0ED691A1B7B for <saag@ietf.org>; Mon, 27 Jul 2015 18:30:22 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D3412282FB1; Tue, 28 Jul 2015 01:30:20 +0000 (UTC)
Date: Tue, 28 Jul 2015 01:30:20 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150728013020.GO4347@mournblade.imrryr.org>
References: <55A938F1.9090404@cs.tcd.ie> <CD936D80-BEA2-4918-828C-E3A392761EC5@gmail.com> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55B6D36C.70105@iang.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/E9MzzwZ7S03r-Qu3UBixoLjE8P0>
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: Tue, 28 Jul 2015 01:30:24 -0000

On Tue, Jul 28, 2015 at 01:57:16AM +0100, ianG wrote:

> >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}.

I agree on the theory, but the practice is a bit more nuanced post
Logjam.

I think it is fair to say that Logjam falls into the class of
protocol weaknesses.  in this case lack of a means in TLS to
negotiate FFDH parameters, and clients not having the code or UI
to check for unreasonably server-chosen DH groups).

Since it is difficult to predict exactly how protocol issues interact
with weak cipher suites, it makes sense to adjust the practice to
reduce the attack surface to just what's needed in practice.

So these days, OS software developers should strive to give their
users sensible defaults that omit needless options (whose absence
no longer requires cleartext fallback to interoperate with a
non-negligible set of peers).  Administrators of systems running
less than up-to-date software, may need to make appropriate
configuration adjustments to disable algorithms that are past their
use-by date in more recent software releases.



> 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 point.

But leaving useless crud enabled, that does not enhance interoperability
is also unwise.  So the middle ground is to find the right balance.
And without difficult to perform full internet scans (for IPv4
still somewhat viable) it becomes a matter of judgement as to when
algorithm seems sufficiently disused to warrant dropping support
in an OS context.

I am doing the best I know how to give Postfix users sensible
default configurations.  Many other MTAs just punt all such decisions
to users.

So the essential take-aways from this sub-thread of relevance
to draft under discussion are I think:

    * OS for new applications should be legacy-free at inception.
      If there's no legacy installed base, specify the use of
      only the latest-greatest protocol versions, ciphers, ...

    * For widely deployed applications, support legacy algorithms
      and protocols while they are needed for interop, but not much
      longer.

    * Application developers (not just crypto toolkit providers)
      need to play a role in defining sensible default configurations
      that are appropriate for OS.  The crypto toolkit does not know
      about the requirements of the installed base for particular
      applications.

    * Administrators or downstream release engineering teams
      delivering the application to end-users, need some knobs to
      be able to adjust the algorithm and protocol selection at
      some point after the developer's default settings are chosen.
      Such knobs should be as simple as possible (difficult to mess
      up) since likely the the administrators or release engineers
      are neither application experts nor crypto experts.  They'll
      just follow some best-practice guide (with luck not a misguided
      one) that tells them what adjustments to make.

-- 
	Viktor.