Re: [Cfrg] Ed448 hash choice

[Ilari Liusvaara <[e-mail]>]

On Wed, Oct 21, 2015 at 03:26:17PM -0400, Quynh Dang wrote:
> Hi IIari,
> 
> On Wed, Oct 21, 2015 at 3:12 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> >
> > If you are talking about fixing TLS 1.3 PRF-hash to SHA-3, then I
> > regard fixing that a _very_ bad idea. TLS is very vulernable to
> > breakage of the prf-hash. Replacing it is horrible enough, but
> > if it takes a version bump, we are utterly screwed.
> >
> 
> In TLS 1.2, PRF depends on cipher suite, but default is HMAC with SHA256.
> This default could be a SHA3 (no HMAC and no many rounds to generate keys).

No ciphersuite that works with TLS 1.3 has default PRF. All the
ciphersuites have explicit PRF hashes.

The reason for this is that TLS 1.2 grandfathered SHA-256 PRF for old
ciphersuites but required explicit PRF for new ones. But none of these
old ciphersuites are AEAD, and thus none work with TLS 1.3.
 
> Everything is built from a Keccak permutation including a possible
> (potential) authenticated encryption function in the future and this would
> be efficient!

Well, I don't think TLS WG would mind too much a draft specifying
ciphersuites with all symmetric parts based on Keccak (e.g. SHA3-256
PRF-hash and some Keccak sponge AEAD).

Unfortunately, it doesn't look like you can replace HKDF or even HMAC,
since those are seemingly fixed in the specs.


-Ilari