Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Ilari Liusvaara <[e-mail]>]

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