Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Require that (EC)DHE public values be fresh. #840
This change requires that (EC)DHE public values be fresh, for both parties, in every handshake.
For clients, this is standard practice (as far as I'm aware) so should make no difference. For servers, this is not always the case:
Springall, Durumeric & Halderman note that with TLS 1.2:
Since this defeats forward security, and is clearly something that implementations of previous versions have done, this change specifically calls it out as a MUST NOT. Implementations would then be free to detect and reject violations of this.
This does have a cost because it also excludes the reasonable practice of amortising public value generation over all connections for a few seconds. The draft could attempt to specify a precise, maximum duration for reuse but that is more complex and no value is clearly optimal.
Also, this cost doesn't seem too high: 85.6% of servers don't reuse values and manage fine today. The generation of (EC)DH public values is also a fixed-based operation and thus can be much faster than DH key-agreement.
Lastly, some have proposed (EC)DH reuse as a mechanism for enabling TLS connections to be decrypted and monitored by a middlebox. TLS is not designed to be decrypted by third-parties—that's kind of the point. Thus anyone doing this should not be surprised to hit a few MUST NOTs and, potentially, to have to configure implementations to allow such a deployment.
Regarding the detection, it seems that it's impractical to detect reuse in general.
Consider the following setting. Use ECC as an example.
The text in this diff alludes to the detection of F(x, Q, i) == Q, i.e. the straightforward reuse with memcpy.
Consider a simple enhancement to F, e.g. F(x, Q, i) = (x + i)G. A peer would implement such an F by adding a G to the previous Q it has sent. It's slower than memcpy, but faster than a fresh generation. It's not forward-secure.
The reuse detection problem boils down to making statements about the entropy in the private key based on the public key, which is a hard problem.
@brainhub yes, there are limits to what level of dumb we can detect. This is more about helping those who aren't thinking too much about it. We know that sites have gotten it wrong with TLS 1.2 because, presumably, they didn't mean to configure a forward-secure cipher suite and then invalidate it by keeping the same public-value for weeks.
But an actively hostile server can always just encrypt their entropy seed in the server nonce or so and we would never know.
-- Brian Sniffen
On Dec 29, 2016, at 2:59 PM, Adam Langley ***@***.***> wrote: @brainhub yes, there are limits to what level of dumb we can detect. This is more about helping those who aren't thinking too much about it. We know that sites have gotten it wrong with TLS 1.2 because, presumably, they didn't mean to configure a forward-secure cipher suite and then invalidate it by keeping the same public-value for weeks. But an actively hostile server can always just encrypt their entropy seed in the server nonce or so and we would never know. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
AGL seems to have disowned this proposal in:
Accordingly, in the interest of keeping the tracker clean I am closing this PR. We can re-open it if consensus changes.