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

[Hubert Kario <[e-mail]>]

On Monday 21 December 2015 14:54:23 Brian Smith wrote:
> Eric Rescorla <[e-mail]> 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 
ciphers...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic