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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 13 April 2015 07:14 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6661B2E8A for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 00:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoa_sNYx8BhB for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 00:14:49 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1201B2E88 for <tls@ietf.org>; Mon, 13 Apr 2015 00:14:49 -0700 (PDT)
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 77C7BF984 for <tls@ietf.org>; Mon, 13 Apr 2015 03:14:46 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id BBC521FF48; Mon, 13 Apr 2015 02:14:45 -0500 (CDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: tls@ietf.org
In-Reply-To: <201504130201.53432.davemgarrett@gmail.com>
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <CAHOTMVJG_uDj5P6D0C_P=mp-Zi-msFj84WR+L1yYGJ0NNjFJpA@mail.gmail.com> <20150407063133.GA5877@LK-Perkele-VII> <201504130201.53432.davemgarrett@gmail.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Mon, 13 Apr 2015 03:14:45 -0400
Message-ID: <87sic4v6sa.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ooJE42C24RUVAeALgl_uycWapPo>
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2015 07:14:50 -0000

On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote:
> On Tuesday, April 07, 2015 02:31:33 am Ilari Liusvaara wrote:
>> Also, the certificate format negotiation is supposedly both via
>> ciphersuites and an extension. And when you have the same thing in
>> two places, the relevant question is "which is definitive?".
>
> Here's a different idea for fixing the combinatorial mess: For TLS
> 1.3+, only use cipher suites to negotiate symmetric ciphers. Rely
> entirely on the extensions for the handshake.

This is the cleanest and most backward-compatible suggestion i've heard
yet for a la carte algorithm selection in TLS.  If we decide to do a la
carte algorithm selection, this seems like a variant i could be
comfortable with.

> For the handshake, mandate usage of the "supported_groups" extension
> (née "elliptic_curves") and the “signature_algorithms” extension for
> all connection attempts. (reject connection if not present and valid)
> If TLS 1.3+ is negotiated, then the DHE/ECDHE will be selected based
> on the highest preferred supported NamedGroup and RSA/ECDSA/etc will
> be selected based on the highest preferred
> SignatureAndHashAlgorithm. Assign points to NamedGroup and
> SignatureAlgorithm to negotiate PSK usage via the
> extensions. (e.g. NamedGroup=0 for plain PSK)

I'm not convinced that we want to use 0 for PSK (this may be purely
aesthetic: it makes PSK sound like the "default", and if we later find
other non-DH key exchange we want to stuff in this registry, it'd be
nice to group them together, and there are no available neighbors close
to 0).  I think i'd be ok using some other currently-unallocated
codepoint, though.

> The server would then ignore everything in proposed cipher suites
> other than the symmetric cipher suite components. (e.g. all of the
> following would be considered equivalent for TLS 1.3+:
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) New ciphers that are
> supported via TLS 1.3+ would only need to define something in the form
> of TLS_EXT_WITH_x_y_z with variations of symmetric parameters (for
> OCB, there'd be only 2 suites). New ciphers that wish to support TLS
> 1.2 but without adding the litany of combinations of suites could
> simply allow negotiation of any of the new suites to assume DHE_RSA
> unless the necessary extensions are used to say otherwise. (though,
> just requiring the extensions to use them is not unreasonable)

We could also say that TLS 1.2 implementations that know about a new
symmetric cipher must be able to negotiate key exchange choice
independently via the supported_group ("supported_key_exchange"?)
mechanism when that cipher is selected.

        --dkg