Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

Hubert Kario <> Tue, 22 December 2015 12:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 780C01A891F for <>; Tue, 22 Dec 2015 04:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AxREKKFcbpPa for <>; Tue, 22 Dec 2015 04:53:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 738A11A891D for <>; Tue, 22 Dec 2015 04:53:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id C1A7A42E5CE; Tue, 22 Dec 2015 12:53:30 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id tBMCrREY013804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2015 07:53:30 -0500
From: Hubert Kario <>
Date: Tue, 22 Dec 2015 13:53:22 +0100
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.2.7-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1801479.mcPsWBGueE"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Cc: Adam Langley <>
Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Dec 2015 12:53:34 -0000

On Monday 21 December 2015 14:54:23 Brian Smith wrote:
> Eric Rescorla <> wrote:
> > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses
> > HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512
> > and that TLS 1.2 use SHA-512 with HKDF, or something different?
> I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that
> TLS 1.3 should use SHA-512 with HKDF.
> > Nobody should pay attention to what the MTI cipher suite for TLS 1.2
> > is,> 
> >> because it's obsolete; in fact, one would be making a huge mistake
> >> to
> >> deploy it now if one's application didn't have legacy backward
> >> compatibility concerns. And, we should change the MTI cipher suite
> >> for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a
> >> lot of problems. For example, they remove any question of any need
> >> to implement rekeying, they avoid the weird IV construction hacks
> >> that are necessary for 128-bit cipher suites like AES-GCM, and
> >> they can be implemented efficiently in a safe way, unlike AES-GCM.
> > 
> > This seems like a separate question.
> You are the one that brought the MTI stuff into this, not me.
> > SHA-256-using cipher suites are widely deployed and not going away
> > any time soon, so what resource are you trying to conserve here?
> I'm trying to minimize the number of algorithms (amount of code)
> necessary to implement ChaCha20-Poly1305 using x25519 for key
> agreement and Ed25519 for signatures. The different between needing
> or not needing SHA-256 matters most for very small computers (AVR and
> Cortex-M0), but doesn't really matter much for larger computers where
> SHA-256 has an advantage.
> In particular, since there seems to be a notable amount of hardware
> that is or will soon be released that optimized for
> ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would
> be nice to take advantage of that for TLS.
> Besides that, the inconsistency regarding why these new
> 256-bit-encryption-key cipher suites are currently defined to use
> SHA-256 in the PRF whereas all the existing 256-bit-encryption-key
> cipher suites use SHA-384 seems strange. Even if an application wants
> to use AES-GCM cipher suites, it would be able to avoid needing
> SHA-256 if it implemented the AES256-GCM cipher suites instead of
> AES128-GCM.

I'm not convinced about SHA-512, but yes, they probably should use 
SHA-384 at the very least. And given that the algorithm for SHA-384 and 
SHA-512 is essentially the same, using just different IVs, that should 
be usable for highly restricted hardware, wouldn't it?

I would be against SHA-512 as that would be the very first cipher that 
uses SHA-512 PRF in TLS1.2, making its addition/implementation much more 
invasive to the underlying library, OTOH, we have multiple ciphers which 
use SHA-384 PRF. I think I just need to remind the delay after which NSS 
added support for SHA-384 compared to introduction to AES-128-GCM TLS 
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic