Watson Ladd wrote on 27.05.2014 15:47: > 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,
I absolutely agree. > 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. > the Signature Algorithm extension is neither about HMAC nor about certificates, its about signatures on key exchange messages, in case of PFS the signature of the ephemeral DH keys. > (I don't understand why MD5 was still included as an option in any RFC > after 2004) > +1 >> >> 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. True, but I'm not sure if we can assume that this is not the case. -- Johannes _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
