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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 07 April 2015 06: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 D0BB71A033A for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 23:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 DpnTiK1NPAdK for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 23:31:36 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5CE1A0338 for <tls@ietf.org>; Mon, 6 Apr 2015 23:31:36 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id A486069A4C; Tue, 7 Apr 2015 09:31:33 +0300 (EEST)
Date: Tue, 07 Apr 2015 09:31:33 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Tony Arcieri <bascule@gmail.com>
Message-ID: <20150407063133.GA5877@LK-Perkele-VII>
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <CAK3OfOgPbADQ1CvOs=8T7ee6f_T+bi3F6GCdBtxufQpznzYbQA@mail.gmail.com> <201504021257.09955.davemgarrett@gmail.com> <CAOgPGoDJTcLn4j90wNu=mhCZJnb2WUuAvM5TN6KOO7RdC==qHQ@mail.gmail.com> <551DE914.4010804@nthpermutation.com> <CAFewVt6jKaQh9Z-ySQJr_9PWsBvn41RNk6PNXMdouLwywn8-wA@mail.gmail.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> <CAHOTMV+j2VECFme_iizE_9UnPfebSGETnfx0Cwv7BZQ-Oc902w@mail.gmail.com> <CAFewVt4OB1fHEytDnrnWgZfpwoLxTqjNFs1bK2LputxAmz8p+w@mail.gmail.com> <CAHOTMVJG_uDj5P6D0C_P=mp-Zi-msFj84WR+L1yYGJ0NNjFJpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHOTMVJG_uDj5P6D0C_P=mp-Zi-msFj84WR+L1yYGJ0NNjFJpA@mail.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/pHEn2fG0-t2nDZwQKQpN-Q0WrRM>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] 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: Tue, 07 Apr 2015 06:31:38 -0000

On Mon, Apr 06, 2015 at 11:18:12PM -0700, Tony Arcieri wrote:
> On Mon, Apr 6, 2015 at 10:51 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> > This is about UI, not about wire format.
> >
> 
> On Mon, Apr 6, 2015 at 11:09 PM, Brian Smith <brian@briansmith.org> wrote:
> 
> > As far as I understand, that problem doesn't have much to do with the
> > syntax of cipher suites in the ClientHello, because that problem is
> > about describing to your web server software which cipher suites to
> > enable on the server.
> 
> 
> I think some are trying to argue that the problem is deeper than just the
> user interface, but you're both correct in saying that's where the problem
> starts.

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?".

Also, consider if new signature algorithm needs to be added (e.g.
CFRG picks something EdDSA-like for new signature algorithm).

Also, it is not like existing TLS stacks don't have tables mapping
ciphersuites into their component algorithms, since otherwise
there would be plenty of code duplication.


As for "components are fine but combination is insecure", that would
likely require very odd algorithms, and would likely point to TLS
key derivation being bad anyway.


-Ilari