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

Yoav Nir <> Tue, 14 April 2015 06:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 83D5D1B33FB for <>; Mon, 13 Apr 2015 23:03:34 -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 eZ45XcWHvK8a for <>; Mon, 13 Apr 2015 23:03:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE2D01B33F9 for <>; Mon, 13 Apr 2015 23:03:32 -0700 (PDT)
Received: by wgso17 with SMTP id o17so103534984wgs.1 for <>; Mon, 13 Apr 2015 23:03:31 -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=LodH8Wyu4hBhhDCF1G2oweA5utBeBGE721MS/Gy3xT4=; b=BjvCRwnI34kJogHIQVwqrnPBNFnWKO1opFBumH67CMBEL9z8rgHoOHnJXU0g93ujne JLlVdpp89pdUpOAsNfRsGddU2szdwIc8QrUxFkMFZSLbc9UoXZcIROnmvzMsPFKynyBG wQImzxX1+MBhX0uhKfmxh9Z03AEi7ybtVjaM2OMpv7rNjyABOdVjrySaFMpEO3mDwSES PsLmHYedm5352BbV62Jr0Er89s1QvzekOp6gEe1z5X70NCD9MoGzA2KSCxtazyHwVk3p da/NpqAzjvPHEpUilnomv++E4wJU8Gvnd6HFfO+XkcjQRcmNseLX69LiTrOULiM2hsnh uhlQ==
X-Received: by with SMTP id jt4mr11251907wid.21.1428991411712; Mon, 13 Apr 2015 23:03:31 -0700 (PDT)
Received: from ([]) by with ESMTPSA id mc20sm1191279wic.15.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 23:03:30 -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: <>
Date: Tue, 14 Apr 2015 09:03:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <m2r3rnzqfi.fsf@localhost.localdomain> <> <m2mw2bzkkk.fsf@localhost.localdomain> <> <>
To: Daniel Kahn Gillmor <>
X-Mailer: Apple Mail (2.2098)
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 06:03:34 -0000

> On Apr 14, 2015, at 6:02 AM, Daniel Kahn Gillmor <> wrote:
> On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote:
>> So a key question is whether policies that rule out various corners
>> of the product space are legitimately required???
> Here's one (granted, contrived) policy:
> * i'm willing to talk to US Government peers (they all want Suite B)
>   and Russian Government peers (they all want GOST).  so my policy is
>   that I want either an all-GOST collection or an all-suite-B
>   collection.  a la carte would suggest that i'd be OK with GOST key
>   agreement combined with suite B symmetric crypto, though i would not
>   consider that OK.

IKE has a complex structure of multiple “proposals”, each a collection of several “transforms”, where a “transform” is one algorithm and you can have more than one algorithm of the same type in a single proposal, so you could have for example:

 - proposal #1: GOST signature, GOST DH group, GOST encryption, GOST MAC
 - proposal #2: AES-128-CGC, AES-GCM-128, HMAC-SHA-1, HMAC-SHA-256, 2048-bit DH group, P-256, RSA certificates.

I haven’t found this construct to be particularly useful, and my implementation only ever emits one proposal (but can be configured with multiple algorithms).

Back to TLS: Your contrived policy can be implemented in the server. Your server (or Rich’s hosting) can be programmed to select only certain combinations depending on SNI, and that does not require any special support in the protocol.

For a client it is more difficult. Do we have a use case where a client connects to some site, and is fine with either GOST certificates and GOST encryption, or with AES-GCM and ECDSA, but not a mix?  If we accept that such policies should be enforced by servers, I think the problem goes away.