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

Yoav Nir <> Mon, 13 April 2015 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE34B1A902C for <>; Mon, 13 Apr 2015 14:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1ggwbpRVZRtL for <>; Mon, 13 Apr 2015 14:57:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7AA71A9022 for <>; Mon, 13 Apr 2015 14:57:40 -0700 (PDT)
Received: by wizk4 with SMTP id k4so90501672wiz.1 for <>; Mon, 13 Apr 2015 14:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jl41WzCyubLdOBUT25pDLk4RSUy6Q19i4E0AcE133Xk=; b=inJwSeRLdzj4sWK2eJ+dBO2h+rqsNp/byRGQcM9gakkqDbzVirLJ/zvarznAxiSo+5 eTmZJPDoaNYKGbAh51hHe62VKA+juDBhzNFYF0s1b4jMFj/CkZ0jq7NI5cHu1xBxiTsb hMTZLs5BWXu9Ln2u/JhH6BF1d7mMkntHV9e6oNJBvu6P/qyf9IaG9uY0DEQq9A8KpdLE cyxf7Hct6e6V72YOfySMRB/mXCEnLqwP45fc7ULPemfHYh+aJlXECORlbQx+7fAqpRbA N2pQu+JuvaLCKr73e0ZeLHvUbqZ0i9LNXqQZNhc1/qn4+H6ZiJlvq84gZf3s5k1SRlYe 7PgQ==
X-Received: by with SMTP id ft11mr26241630wic.0.1428962259556; Mon, 13 Apr 2015 14:57:39 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id fs9sm13202243wjc.34.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 14:57:38 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <>
In-Reply-To: <m2r3rnzqfi.fsf@localhost.localdomain>
Date: Tue, 14 Apr 2015 00:57:36 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <m2r3rnzqfi.fsf@localhost.localdomain>
To: Geoffrey Keating <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: "<>" <>
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: Mon, 13 Apr 2015 21:57:42 -0000

> On Apr 14, 2015, at 12:09 AM, Geoffrey Keating <> wrote:
> Martin Thomson <> writes:
>> On 3 April 2015 at 17:05, Brian Smith <> wrote:
>>> I don't think the current mechanism is problematic
>>> enough (at all, really) to justify that effort.
>> I think that I've the same view.
>> Then you have to consider interaction problems where some
>> implementations have hardware for certain things, and software for
>> others.  Not only does that produce strong preferences for some things
>> over others, it also can lead to holes in support tables, making a la
>> carte selection tricky.
>> That was always the clincher for me.
> I agree.  In particular I don't think we've simplified anything if
> implementations have to have a list of invalid combinations, or have
> to know that certain ciphers are to be used only with matching key
> exchange algorithms (for example, use the GOST key exchange with the
> GOST symmetric cipher).

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.

If some standard in Russia demands that GOST algorithms be used for all three, that should be configurable on the server. If OTOH the Russian authorities decide that they are fine with ECDHE for key exchange, but demand the GOST symmetric ciphers and authentication, that is also easy to get working with a la carte, but now it’s impossible until someone specifies such ciphersuites in a new document.

Unless some combination creates an insecurity when each of its components is secure when combined with other components, I don’t think we have an issue.