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

Yoav Nir <> Thu, 10 March 2016 22:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DB5312DC63 for <>; Thu, 10 Mar 2016 14:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2uBArTpeTdIt for <>; Thu, 10 Mar 2016 14:19:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE7DB12D93B for <>; Thu, 10 Mar 2016 14:19:46 -0800 (PST)
Received: by with SMTP id n186so6025075wmn.1 for <>; Thu, 10 Mar 2016 14:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=BHrBD4B4PIoiYM22d5vi3/krNHfAzOAoFrhZlMJZqR4=; b=IsuPsekZ1mTg3yi86FgF/34LfVcLWbWtLAMmsilp5VW0IFKLSasxtW9XyUbYtCSyJK d+vUNSaC2ybIAKa6vlKtqsqEbxDCPrPIw3MsMfqUzeCAxSRzNxJPADFJXeoSOWR4Ho19 76y1IBHi40jhxIBbfFrxbudXcLQ00MkHXhMAKgcbomzqA8YIlP9zeEPA7iDLOuLCqZdg extQ6U3YH6hMhNkQfRjJCIBbo+uGCoCUAJu9LV+GTjBHmBZvzJkBtWnixKtlaHXuJdVK j1QvnV2z5zWWO5Rs7lIiZbaC1C3Y13gnN/MY91J6OhQd/SUYpDdwBqkVewhWsrrrq7di NzgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=BHrBD4B4PIoiYM22d5vi3/krNHfAzOAoFrhZlMJZqR4=; b=hlSohoUARDJjUPMNgUv7r8xMIUKELgs1FEsk7QiuNG/6cK6hnztL4XMHdMKPbAPrjy /Ui2cDSJ+UyKC74vvQN1tliHe/i0HxdirVR3AtWscg/kI9dNhfJyoLSiFUfPy/POUFys w9aVpqIbQa9qQzjquMJnMezuHUCsKVdXBwfssj1D/fW5Y01L18Lt2I9tb8g/HIOV3QN0 E5Ps0t577uQIl+Yx9dMXtKHKDwOyM0gZKz/XvLptJ2VW0SbH5C0tdkQZ0wY8Wzql/jP7 oG+7mwPyaoPL32Z1zHfQEl+0uNdHLwgfsG+GLTcIDNz+2/hhg5zKKXh2aL/iXP6pYyls /w7A==
X-Gm-Message-State: AD7BkJLPLcnFCzrxY0lS9YC9REWXotMF/IXBTOj7Iv+cZeQUMGC6/cBwtd+2LyV3ZAwnhg==
X-Received: by with SMTP id e11mr6281135wjs.79.1457648385127; Thu, 10 Mar 2016 14:19:45 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id vw2sm5463849wjc.43.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 14:19:44 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_79622F30-E65C-42C7-9006-E5EC5A4BC389"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir <>
In-Reply-To: <>
Date: Fri, 11 Mar 2016 00:19:41 +0200
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Mar 2016 22:19:49 -0000

I agree with Viktor and Dave.

RSA with keys greater at least 2048 bit is a good requirement that can be made of old and new implementations. Even if for some reason you’re stuck with OpenSSL 0.9.6 and thus with TLS 1.0 and 3DES, you can conform to this requirement. I think it would be a shame to make that requirement only of implementations while they’re using ChaCha.

And yes, there’s nothing more wrong with using ChaCha with 1024-bit RSA then there is with using AES with it.


> On 10 Mar 2016, at 9:41 PM, Stephen Farrell <> wrote:
> 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.
> _______________________________________________
> TLS mailing list