On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton <wil...@isoc.org> wrote: >... > If I am analysing this correctly, there are two "tampering events" involved > here. > > The first is: has someone tampered at the protocol/notification level to > prevent the client from being notified that static DH is in use? > > The second is: when the client decrypts traffic using whatever has resulted > from the key exchange protocol, can it tell whether the DH key that was used > is a static one or not? > > I don't know enough about your proposed extension to judge whether it's > reasonable to assume that the finished message processing would detect > either of those or not (but I freely admit, that's my lack of knowledge).
In my mind's eye, and stepping back to 10,000 feet, the security engineering problem you are witnessing is: * The security community has advised "DH for perfect forward secrecy" * RSA key transport was deprecated because it does not provide PFS * The proposal does an end-around, and it breaks expectations/security properties The security community created the "reasonable expectation" of PFS when using Diffie-Hellman. A typical developer who follows best practices will expect it. It was pounded into heir heads. Cf., https://www.imperialviolet.org/2013/12/03/forwardsecretforjournalists.html and https://www.imperialviolet.org/2013/06/27/botchingpfs.html. The typical developer will not be able to make the distinction between Diffie-Hellman Ephemeral and Static Diffie-Hellman modulo key vaulting so traffic can be decrypted later. In the typical developer's eyes, they have been told to do something because it has certain security properties but it no longer holds. The signalling indicates the loss of the security property typical developers and users have come to expect. Jeff _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
