New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require that (EC)DHE public values be fresh. #840

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@agl

agl commented Dec 29, 2016

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:

  • 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more than a day.
  • 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.

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.

Require that (EC)DHE public values be fresh.
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[1] that with TLS 1.2:
  ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
    than a day.
  ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.

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[2] (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.

[1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
[2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Dec 29, 2016

Contributor

@agl: can you please propose this on the list. It's clearly a substantive change and we have a conflicting PR that is based on the assumption that reuse is permissible

Contributor

ekr commented Dec 29, 2016

@agl: can you please propose this on the list. It's clearly a substantive change and we have a conflicting PR that is based on the assumption that reuse is permissible

@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Dec 29, 2016

Contributor

Ah, I see you have. Thanks

Contributor

ekr commented Dec 29, 2016

Ah, I see you have. Thanks

@agl

This comment has been minimized.

Show comment
Hide comment
@agl

agl Dec 29, 2016

@ekr: mail has already been sent. I think the mailing list machine is grinding away.

agl commented Dec 29, 2016

@ekr: mail has already been sent. I think the mailing list machine is grinding away.

@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Dec 29, 2016

Contributor

@agl: so I see. Maybe it had to generate a fresh DH share :)

Contributor

ekr commented Dec 29, 2016

@agl: so I see. Maybe it had to generate a fresh DH share :)

@brainhub

This comment has been minimized.

Show comment
Hide comment
@brainhub

brainhub Dec 29, 2016

Regarding the detection, it seems that it's impractical to detect reuse in general.

Consider the following setting. Use ECC as an example.

  • a peer generates a key pair (x, Q=xG),
  • he reuses it with some function Q_i = F(x, xG, i), where i={0, ... n} is a sequential index

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.

Regarding the detection, it seems that it's impractical to detect reuse in general.

Consider the following setting. Use ECC as an example.

  • a peer generates a key pair (x, Q=xG),
  • he reuses it with some function Q_i = F(x, xG, i), where i={0, ... n} is a sequential index

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.

@agl

This comment has been minimized.

Show comment
Hide comment
@agl

agl Dec 29, 2016

@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.

agl commented Dec 29, 2016

@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.

@briansniffen

This comment has been minimized.

Show comment
Hide comment
@briansniffen

briansniffen Dec 29, 2016

@ekr

This comment has been minimized.

Show comment
Hide comment
@ekr

ekr Jan 21, 2017

Contributor

AGL seems to have disowned this proposal in:
https://www.ietf.org/mail-archive/web/tls/current/msg22285.html

Accordingly, in the interest of keeping the tracker clean I am closing this PR. We can re-open it if consensus changes.

Contributor

ekr commented Jan 21, 2017

AGL seems to have disowned this proposal in:
https://www.ietf.org/mail-archive/web/tls/current/msg22285.html

Accordingly, in the interest of keeping the tracker clean I am closing this PR. We can re-open it if consensus changes.

@ekr ekr closed this Jan 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment