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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 04 April 2015 15:52 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 4501A1B2BDA for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 08:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6] 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 zDvKaCvXGSIg for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 08:52:20 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC531B2BD2 for <tls@ietf.org>; Sat, 4 Apr 2015 08:52:20 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ACA9B283032; Sat, 4 Apr 2015 15:52:18 +0000 (UTC)
Date: Sat, 4 Apr 2015 15:52:18 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150404155218.GO17637@mournblade.imrryr.org>
References: <20150401201221.163745c2@pc1.fritz.box> <CAFewVt6jKaQh9Z-ySQJr_9PWsBvn41RNk6PNXMdouLwywn8-wA@mail.gmail.com> <CAHOTMVLohRLPw=WwmEhqVrE91+F_nuM9Z9w0=NtzypN1J0xKoA@mail.gmail.com> <201504032121.07726.davemgarrett@gmail.com> <551F6E22.1040207@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <551F6E22.1040207@azet.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/g_C1l_QhfpQqAh-040HNgLPrAks>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Sat, 04 Apr 2015 15:52:21 -0000

On Sat, Apr 04, 2015 at 06:52:50AM +0200, Aaron Zauner wrote:

> I actually really like the idea. But there're a couple of open questions
> to that;
> What happens to existing ciphersuites?

Those that are strong enough to survive into TLS 1.3 are subsumed
by the new ala-carte choices.

> And given we switch to a
> model of asymmetric and symmetric ciphersuites: (how) do we document all
> the implicit ciphersuites that are defined once a new symmetric or
> asymmetric algorithm is defined?

There's no need to document the "cross-product", just document the
inputs.  Making it a cross-product fills in gaps, for example,
there are at present no AECDH (key agreement) plus AEAD (symmetric
bulk crypto) ciphersuites.

Note that digests play a role in both the handshake and in the bulk
crypto MAC.  

For the handshake, there's the digest used in certificates (which
seems odd to negotiate as it is I think rare for either end to have
multiple variands of a given certificate chain with different
digests).  There's also the digest used for key derivation.

If the leading proposal is to go with 2 axes for the cross-product,
then I would fix the key-agreement PRF in each handshake type, and
use the supported digests extension as a "hint" to the peer to aid
in certificate selection.  I say "hint", because the peer will do
its best to send a suitable chain, when it has more than one, but
typically such "hints" are not particularly effective, and the peer
may as well use whatever it has.

For example, with DANE-EE(3) the signature of the peer certificate
is never checked and is irrelevant.

-- 
	Viktor.