Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 12 June 2015 08:31 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 CD41C1A88C7 for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 01:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 og4qhBflpZSx for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 01:31:57 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1AA1A88A0 for <tls@ietf.org>; Fri, 12 Jun 2015 01:31:56 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id F09779023B; Fri, 12 Jun 2015 11:31:53 +0300 (EEST)
Date: Fri, 12 Jun 2015 11:31:53 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150612083153.GA24990@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <201506111558.21577.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0e-1044ZpwpkfM9N5EmD__BEYF4>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
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: Fri, 12 Jun 2015 08:32:00 -0000

On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote:
> Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list.
> 
> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

Interesting...
 
> TL:DR:
> * Deprecate all suites with any of: DH, DHE, ECDH, RSA, DSS
> * Deployments may continue to offer deprecated suites for TLS 1.0-1.2 negotiation.
> * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK.
> * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorithms" extensions.
> * No change to bulk cipher negotiation.
> 
> To be clear, this would mean a connection could negotiate usage of a ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about DHE+ECDSA yet, but I think that combination is fine if negotiated.
 
AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).

(In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)

The main pitfall I see for unifying DH is that ECDHE nested length
byte (which is insufficient for DHE). One would have to either expand
that to 2 bytes, or better yet, dump it entierely (as it is seemingly
useless).

> Benefits:
> 1) Old DH(E) suites are replaced by a system which only negotiates strong FFDHE groups.
> 2) The combinatorial explosion of suites that need to be offered in a ClientHello is reduced.
> 3) Accidental interop failure due to a missing combination is avoided.
> 4) All TLS 1.3 implementations are expected to be able to handle ECC, but are not required to offer or negotiate it. (at least, here)
> 5) EdDSA can easily be added to the list as a variation of ECDSA without new suites.
> 6) No more confusing double negotiation of signature algorithms. Just extensions, instead of many suites and extensions.
> 7) The default usage of SHA1 for the "signature_algorithms" extension can be removed, as all TLS 1.3 clients would be required to send it.

Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
quite clear about interaction of signature algorithms in ciphersuites
and explicit signature negotiation (explicit negotiation always takes
percedence).

Of course, I wouldn't be surprised if there was fair bit of software
that got those rules wrong...


-Ilari