Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 29 June 2015 09:06 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 F335C1A8833 for <tls@ietfa.amsl.com>; Mon, 29 Jun 2015 02:06:08 -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_34=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 SBJzu4Yq3N8u for <tls@ietfa.amsl.com>; Mon, 29 Jun 2015 02:06:08 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC66B1A8772 for <tls@ietf.org>; Mon, 29 Jun 2015 02:06:07 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9160C1A267B for <tls@ietf.org>; Mon, 29 Jun 2015 12:06:04 +0300 (EEST)
Date: Mon, 29 Jun 2015 12:06:04 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20150629090604.GA14692@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <CAF8qwaAkBAXDkhd3zU=uO1t-dv7iu0bhb9bH28JHROrWp98SEA@mail.gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost> <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <14e3e898220.276b.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz>
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/L7qfm3TY3wp0ul4sQQwh795WR4I>
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: <https://mailarchive.ietf.org/arch/browse/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, 29 Jun 2015 09:06:09 -0000

On Mon, Jun 29, 2015 at 08:58:11AM +0000, Peter Gutmann wrote:
> Nico Williams <nico@cryptonector.com> writes:
> >On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote:
> >
> >>"Chinese menus" with coupled choices are classical source of interop
> >>problems.
> >
> >It's worked for SSHv2.
> 
> It worked for SSH because implementations use algorithm groups in highly
> stereotyped ways, so you have a de facto interop profile. Try negotiating
> e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly
> the wheels fall off.

Also, regarding kex+auth in SSH2, the authentication is interactive, so
choosing something bad most likely just gives an error and client trying
something else. Definitely not the case in TLS.

And record protections in different directions aren't even coupled choice
(all pairs should technically work).


-Ilari