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

Viktor Dukhovni <> Tue, 14 April 2015 00:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA1C71B2B98 for <>; Mon, 13 Apr 2015 17:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UmJA-YG_yxWx for <>; Mon, 13 Apr 2015 17:36:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B5261B2B96 for <>; Mon, 13 Apr 2015 17:36:59 -0700 (PDT)
Received: by (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 <>
Message-ID: <>
References: <> <> <> <> <> <> <> <m2r3rnzqfi.fsf@localhost.localdomain> <> <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: <>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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???