On Sun, Jan 01, 2017 at 12:43:06PM -0500, Hugo Krawczyk wrote: > There is more than one way to "backdoor" the use of DH (i.e., to not > enforce forward secrecy) and some of these ways are completely undetectable > (in particular, they would not repeat DH values). One has to be careful not > to give a false sense of security by the illusion that not detecting DH > repetition guarantees forward secrecy (FS). The value of a MUST NOT that > cannot be enforced is debatable even though it may serve as a strong > message to implementers that FS is an important property to comply with > (which is the domain of SHOULD). Another consideration is that there are > applications where FS is of little value, e.g. anything where the > requirement is authentication and not secrecy or where the secrecy > requirement itself is ephemeral.
My understanding of this matter is that this proposal isn't so much about forcing FS, but ensuring that servers don't _accidentially_ screw up FS, as many TLS 1.2 servers do, even when using ECDHE cipher- suites. Those servers cache ECDH keys and apparently have no facily to roll over ECDH keys as those use the same ones weeks or months over. If such ECDH key gets compromised on still-live server, you don't just get attacks where past connections have confidentiality compromised, but also attacks where _future_ connections have confidentialty and _integerity_ compromised. Yes, you can undetectalby undermine FS (and concrete methods of doing that have been proposed in discussions within this WG), but implementing that is nontrivial work, compared to just generating ECDH key on startup and reusing it for lifetime of the process. Also, when considering confidentiality, there is not just cofidentiality of information itself, but also confidentiality of access of information. I have seen lots of arguments against encryption that completely ignore that. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
