On Mon, May 26, 2014 at 2:18 AM, Johannes Merkle <[email protected]> wrote: > I had suggested two additions, for which there has been no decision yet. I > would like to see more discussion on these. > > 1. Usage of Extension SignatureAlgorithms by client to signal minimum > required hash functions. Ralph's feedback on that > suggestion was that we need more data on the extend of SHA-2 support by > current and future implementations. But I think > it's not just about migrating to SHA-2 it could also be useful to prevent > usage of MD5.
MD5 in TLS 1.2 should not be used anymore. There are some real clever tricks that can be played. We need a secure hash every time. However, the ciphersuite, not the SignatureAlgorithms, determines which hash to use. If we are talking about certificates, then I think this is the correct thing, but I don't know. (I don't understand why MD5 was still included as an option in any RFC after 2004) > > 2. When re-using keys for ECDHE (which is the default behavior in some > implementations, e.g. OpenSSL) or when using > non-ephemeral ECDH, the validity of the received public DH-key should be > checked to avoid non-group attacks. That is, it > should be checked that the received point P is on the curve (unless point > compression was used). Small subgroup checks > could even be recommended for classical DH. Something in the spirit of RFC > 6989. This is a problem for ephemeral DH as well due to Triple Handshake. We might as well throw this in: it doesn't hurt. However, if you aren't doing it already, odds are you aren't capable of implementing TLS correctly, because you don't understand the issues associated with implementing cryptography. Sincerely, Watson Ladd > > -- > Johannes > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
