Ilari Liusvaara <ilariliusva...@welho.com> writes: >More serious problem is servers returning too small modulus due lack of >negotiation. Which was the reason why Chrome disabled DHE.
Why not reject the handshake if the modulus is too small, rather than disabling all DHE suites on the off chance that the server returns a value you don't like? >- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with > RSA or DSS certificate (good luck getting DSS certificate, and even > more luck getting clients to accept it). >- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only > RSA certificates are supported. >- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are > supported. Wouldn't matter much anyway, suport for those is practically nonexistent (CCM, Aria, Camellia, ChaCha20, and so on, I mean). OK, "practically nonexistent" may be too optimistic, I've never heard of anything supporting those. Having said that I don't know of every SCADA device in existence, maybe some Korean devices somewhere do Aria. DSA certs aren't a problem since they're all from non-commercial CAs (in-house or self-signed), but I only know of a few systems using DSA. Can't remember why they did that... oh yes, because keygen was faster/more efficient for DSA, just a single modexp and no requirement for lots of CPU and memory. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
