Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

Dave Garrett <> Mon, 13 April 2015 17:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A27E81A8791 for <>; Mon, 13 Apr 2015 10:25:26 -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 qR7VcwkYvuTF for <>; Mon, 13 Apr 2015 10:25:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A2AE1ACF1C for <>; Mon, 13 Apr 2015 10:25:24 -0700 (PDT)
Received: by qkhg7 with SMTP id g7so190572689qkh.2 for <>; Mon, 13 Apr 2015 10:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=/pVeEfFwBgfJhiTih6dKDHVNHwlWMqA/Am7WS+YtQqI=; b=q9It53Tpi5lo+3Rbhjty090nP/Q49ZF2FNOX39HIXSaYTlEI0PRvMWAqCDd3aPgQeE RPYe1zmpPB+00top1yKqLZ2bcQGi2uZ/TvjG+9cnnv7jfbxEMYymqIS78zbPK+VU3aJr XdBvxKIbyYPHan3YNMySDU93V6VDjDxMXftwJbkOG/Um/ubz/J/yqpoUd5IBFesjCQyk hJ9jx1iQuxndybLB5f4rz8AkpXKWxZmWa9/dL5lfBGTQ4lsTV9WE98W1cQzrv72aoHqo Kcn7Fv1f8QgmUQWr3csi+tgZnY/7MHiZwmPrD/b045V0hEwYl3Qwx1EAzzgKZBTzBcjj kisQ==
X-Received: by with SMTP id 12mr30898157qkq.39.1428945921806; Mon, 13 Apr 2015 10:25:21 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id s7sm6293746qgd.4.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:25:21 -0700 (PDT)
From: Dave Garrett <>
To:, Daniel Kahn Gillmor <>
Date: Mon, 13 Apr 2015 13:25:20 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: 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 17:25:26 -0000

On Monday, April 13, 2015 12:49:45 pm Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 12:00:00 -0400, Dave Garrett wrote:
> > The thought process was 0 for N/A in the case of PSK without
> > (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which
> > would make this a non-issue.
> Hm, let's look at the representations of ((EC)DHE_)PSK in the scheme you
> propose.  You've split the suite using these terms and mechanisms:
>  "symmetric" (indicated by ciphersuite list)
>  "handshake" (indicated by known_groups extension)
>  "signature" (indicated by signature_algorithms extension)
> I'd recommend using slightly different terminology, since at least
> "handshake" is already overloaded to mean something broader in TLS.
>   "symmetric" (ciphersuite list)
>   "key agreement" (known_groups extension)
>   "authentication" (signature_algorithms extension)

Yes, this could avoid some miscommunication. The "handshake" includes both key agreement and authentication, so it would be better to be explicit.

In fact, if we're already renaming the extension, elliptic_curves/supported_groups could be better named as key_agreement_algorithms to better align with the signature_algorithms naming and explain its purpose better.

> In this model, ECDHE_PSK would have:
>    key agreement: ECDHE
>   authentication: PSK
> while non-(EC)DHE PSK would have:
>    key agreement: PSK
>   authentication: PSK
> right?


> we'd only need a key agreement codepoint for PSK in the case we have
> non-(EC)DHE, but i have heard some constrained-devices people arguing
> for that in the WG, so that seems like a likely outcome.


Not sure if allowing non-FS is a given, though. If they're really constrained, I think a much better alternative would be to define some (EC)DHE optimized for performance but only providing a minimum reasonable level of forward secrecy, even if not ideal.

> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer
> were to try to negotiate:
>   key agreement: PSK
>  authentication: RSA-PSS
> Do we just say "don't do that"?


> As for placing the known_groups codepoint at 0: it's conceivable that in
> the future someone wants to resurrect SRP or add some other PAKE or any
> other non-DH key agreement scheme (with or without forward secrecy and
> with or without authentication), in which case it would be aesthetically
> nice to have a block of "neighbors" with similar properties -- using 0
> doesn't let us do that grouping.

The codepoint is of course rather arbitrary, so picking some other value for future-proofing is fine. It's a 16-bit space so there's plenty of room.