https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
specifies that (EC)DH values must be fresh for both parties in TLS
1.3.
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/
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
