Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 14 April 2015 00:37 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C71B2B98 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 17:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6] autolearn=no
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 UmJA-YG_yxWx for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 17:36:59 -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 9B5261B2B96 for <tls@ietf.org>; Mon, 13 Apr 2015 17:36:59 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A5841283031; Tue, 14 Apr 2015 00:36:58 +0000 (UTC)
Date: Tue, 14 Apr 2015 00:36:58 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150414003658.GB17637@mournblade.imrryr.org>
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <CAK3OfOgPbADQ1CvOs=8T7ee6f_T+bi3F6GCdBtxufQpznzYbQA@mail.gmail.com> <201504021257.09955.davemgarrett@gmail.com> <CAOgPGoDJTcLn4j90wNu=mhCZJnb2WUuAvM5TN6KOO7RdC==qHQ@mail.gmail.com> <551DE914.4010804@nthpermutation.com> <CAFewVt6jKaQh9Z-ySQJr_9PWsBvn41RNk6PNXMdouLwywn8-wA@mail.gmail.com> <CABkgnnXoBmSfoK5Ht5x7jqf3zGB-mDntcVRMVzKgr2wfsixgNg@mail.gmail.com> <m2r3rnzqfi.fsf@localhost.localdomain> <AAC2BF7D-C528-42A0-8BAD-74CA451DAEBE@gmail.com> <m2mw2bzkkk.fsf@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2mw2bzkkk.fsf@localhost.localdomain>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YTH64oLv7cCA-kC3Vq2PkhKrSdA>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 00:37:00 -0000

On Mon, Apr 13, 2015 at 04:15:39PM -0700, Geoffrey Keating wrote:

> > Why?  There?s nothing invalid about using Curve25519 key exchange
> > with an RSA certificate and GOST symmetric ciphers, so TLS should
> > not provide this. Requiring all three things to be GOST is a policy
> > decision that can and should be part of server (and perhaps client)
> > configuration.
> 
> It seems like that would be an interoperability issue if the server
> and client disagree on the policy to apply.

If a client or server is willing to do non-GOST algorithms along
some axis of the cipher-suite parameter space, it should be willing
to accept mixed results.  It is no less GOST-compliant when using
a mixed suite than when using a suite that has no GOST features.

But your point is valid, and can be taken to imply that policies
which disallow valid combinations of parameters are to be avoided,
if a server selects a combination from the choices offered by the
client, the client SHOULD or MUST accept that combination, or else
why were the choices in question offered by the client?

So a key question is whether policies that rule out various corners
of the product space are legitimately required???

-- 
	Viktor.