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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 10 March 2016 19:42 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 A87E712DC4E for <tls@ietfa.amsl.com>; Thu, 10 Mar 2016 11:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 nl4UwH6m9CmM for <tls@ietfa.amsl.com>; Thu, 10 Mar 2016 11:42:36 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07DC12DC46 for <tls@ietf.org>; Thu, 10 Mar 2016 11:42:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6847BBE51 for <tls@ietf.org>; Thu, 10 Mar 2016 19:42:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq0IkMcvH0Qu for <tls@ietf.org>; Thu, 10 Mar 2016 19:41:59 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99158BE50 for <tls@ietf.org>; Thu, 10 Mar 2016 19:41:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457638919; bh=k1deJXRF5edFjiarnMXGvrLxEKUfVdCbBXoOyu6nJAg=; h=To:From:Subject:Date:From; b=bdrW9spjOibUs10u1eeqLaIkPH+jr0foNTHIe4JuOtzkX2wfalcVa6lcnyEid1pKv gvk98fx+MERn2TTLTW6G+PtGOAJXBkUUbvqK818duFJDSRfoB9/jvlXWPdvWd4J+bT 5TCYhfru91UBJ9O35WnmsA5vLRt8EabVW0KgRyfs=
To: "tls@ietf.org" <tls@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56E1CE06.3020705@cs.tcd.ie>
Date: Thu, 10 Mar 2016 19:41:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070401040009050904070609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QAtW22-V3C-ISUr4RWDIBvIHOw0>
Subject: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 10 Mar 2016 19:42:38 -0000

Hiya,

This is ready to go but I've one question. Sorry I don't
recall if this was discussed previously, if it was, then
just say and I'll move this along to IETF LC.

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. Etc etc.  Getting all that agreed might
take a wee while, so if the answer is "nah, no thanks, we don't
want to do that here," that's fine and I'll just start IETF
LC.  I guess another way to handle that might be to say that
these ciphersuites REQUIRE that all relevant restrictions
from BCP195 be enforced. That'd maybe ensure the public key
stuff is all at good strength, but doing so might not be so
effective, in terms of trying to ensure these ciphersuites
aren't used with e.g. short RSA keys.

Whatchacha think?

Cheers,
S.