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

"Blumenthal, Uri - 0553 - MITLL" <> Mon, 13 April 2015 22:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62E851ACE76 for <>; Mon, 13 Apr 2015 15:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D3RonTJIPYYd for <>; Mon, 13 Apr 2015 15:22:19 -0700 (PDT)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id EB68C1AD2A4 for <>; Mon, 13 Apr 2015 15:22:18 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id t3DMMFcT030674; Mon, 13 Apr 2015 18:22:15 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "''" <>, "''" <>
Thread-Topic: [TLS] Ala Carte Cipher suites - was: DSA should die
Thread-Index: AQHQbatVG4ITsjPF1kmCUIQaIRqrT508PbaAgAAJxwCAD3xggIAADY4A///DvVw=
Date: Mon, 13 Apr 2015 22:22:14 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_05:2015-04-10,2015-04-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504130190
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 22:22:29 -0000

Yes. My expectation here is that "good" constructs are composable. "Composable with caveats" are not good, and shouldn't be included in a-la carte selection. 

Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

MIT LL Root CA:  <>

----- Original Message -----
From: Yoav Nir []
Sent: Monday, April 13, 2015 05:57 PM
To: Geoffrey Keating <>
Cc: <> <>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die

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

TLS mailing list