Ilari Liusvaara <[email protected]> writes: >The basic problem (let's ignore non-cert modes for a bit): > >When choosing the certificate, you need to consider if you have a ciphersuite >that can use some supported group and protection/prf-hash available. > >Similarly, when choosing a group, you need to consider that you have a >ciphersuite that is consistent in other (possible) choices. > >And protection/prf-hash also has to be consistent with other choices. > >The reason these choices couple is because the client can send pretty much >arbitrary combination of oters that depends on each considered factor.
OK, so that's pretty much the same stuff I ran into. What makes it really ugly is that you can no longer decide, based on a cipher suite offered, whether you can actually continue with that, but then have to tunnel down into the extensions that follow the suites to see what's there. If there's nothing appropriate you go back to the cipher suites and find the next-best match, try that against the extensions, and so on. Mostly things appear to work now because virtually everything supports the de facto standard of P256 + SHA-256 with ECDSA and ECDH (which is why TLS-LTS specifies it as one of its two suite choices), but once you start veering away from that de facto universal standard you run into problems. Rather than spend forever trying various poke-and-hope strategies, my code looks for the default form (P/SHA-256) and if that's not found falls back to DHE + RSA. That seems to work well enough, and I don't have to debug weird failures with oddball combinations. Peter. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
