Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 10 March 2016 20:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793D012DCC6 for <tls@ietfa.amsl.com>; Thu, 10 Mar 2016 12:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=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 goq2HZB-pCly for <tls@ietfa.amsl.com>; Thu, 10 Mar 2016 12:18:50 -0800 (PST)
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 1241C12DC87 for <tls@ietf.org>; Thu, 10 Mar 2016 12:12:35 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4E2F0284F26; Thu, 10 Mar 2016 20:12:29 +0000 (UTC)
Date: Thu, 10 Mar 2016 20:12:29 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20160310201229.GG10917@mournblade.imrryr.org>
References: <56E1CE06.3020705@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <56E1CE06.3020705@cs.tcd.ie>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UcyrfFnf4GcgB4WYhHlyjbXVIz4>
Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <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: Thu, 10 Mar 2016 20:18:51 -0000

On Thu, Mar 10, 2016 at 07:41:58PM +0000, Stephen Farrell wrote:

> My question is: Should the WG take the opportunity to more
> tightly define the key exchange parameters for these
> ciphersuites?
> 
> For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could
> REQUIRE RSA keys with >=2048 bit moduli and one could go
> further and say that this also REQUIRES use of specific
> integer DH groups.

I think that enforcing such a requirement for just new cipher-suites
would be counterproductive.

If a server has a 1024-bit RSA certificate or is configured with
1024-bit DH parameters, should it not offer CHACHA20, and restrict
the client to AES or 3DES which don't have that contraint?  What
does that achieve?  Or should the server go ahead with CHACHA20
and then the client refuse?

I think it makes more sense to set such floors on a per-protocol
basis (TLS 1.3, ...) than a per-cipher-suite basis.

-- 
	Viktor.