On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith <[email protected]> wrote:
> Adam Langley <[email protected]> wrote: > >> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <[email protected]> >> wrote: >> > That is, it seems it would be better to use HKDF-SHA512 instead of >> > **HKDF-SHA256**. >> >> I assume that you mean for TLS 1.3 since you mention HKDF? > > > No, I mean for all versions of TLS. > Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else? > So, the current code points are probably SHA-256 now. I don't object >> to adding more if people want SHA-384 too. Although, since the hash >> function is only used in key derivation with these cipher suites, > > > I don't think it would be a good idea to add more code points to negotiate > SHA-512 in the PRF while still leaving code points for negotiating SHA-256 > in the PRF. It should be one or the other. > > >> I'm >> not sure that a slower, software implementation of SHA-256 would be a >> big problem. > > > It just seems really unfortunate to mandate SHA-512 for Ed25519 and then > mandate SHA-256 for ChaCha20-Poly1305 in TLS. Mandating the same algorithm > for both seems like a better idea. > Can you explain what resource you're trying to conserve here? The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and All the AES-GCM ciphers already require SHA-256 or SHA-384, so it seems like the vast majority of implementations are going to require at least one of these algorithms in any case. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
