Re: [TLS] Is there a way forward after today's hum?

[Jeffrey Walton <[e-mail]>]

On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton <[e-mail]> 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