Thoughts, as a random passerby: Of course I quite like the prioritization of (EC)DHE.
I think standardizing on a ciphersuite preference order with the aims of reducing fingerprinting is a worthwhile (although wildly difficult) goal for SSL _libraries_, but less so for browsers - to the point of probably not being a fight worth fighting. A web browser is so incredibly complex it is next to impossible to browse with _soley_ over TLS, and the first HTTP request leaks the User Agent. Even with soley-over-TLS, requests for malware protection, the dynamic favorites RSS feeds Firefox bundles (which I quite hate), and the auto-update checks will leak the browser anyway. Trying to avoid leaking the preference to the network is admirable, and worthwhile in a library I think, but the browser is a mighty beast to tackle. There are lower hanging fruit than the TLS handshake right now. Weak DHE keys are a lurking problem. Someone needs to survey the internet. (Unless there's a paper I'm not aware of...) The Ephemeral ECDH certs is clever... but I feel like that's an awful amount of engineering for the relatively few organizations who their own Intermediate cert. Unless this is a strategic push to encourage Name Constraints. In which case: Hmmmmmm. "Future work: A comprehensive profile for browsers' use of TLS." - In theory, this would be the domain of the relatively-new IETF PKI Operations Working Group, which is being driven by a few browser folks and many CA folks. I would suggest another item for "Future Work" and that is trying to work in protections against TLS downgrades. This has been batted around a few times in the past [0][1] but has never gained much traction or agreement. -tom [0] https://www.ietf.org/mail-archive/web/tls/current/msg08861.html [1] I'm failing to find a link, but Yoav had a trick he added to Opera to prevent downgrade if the server supported secure renegotiation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
