Adam Langley <a...@imperialviolet.org> wrote: > On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <br...@briansmith.org> 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. > I updated > the draft recently because David Benjamin noted that the names didn't > include the PRF (which they should these days) and that OpenSSL, at > least, used SHA-256, so might as well make the spec match reality. > The version of OpenSSL that implements these cipher suites is not released yet. They updated that implementation just 9 days ago, so it seems pretty malleable still. > 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. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
