On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote: > In our tests, we see significant drop in handshakes/sec on a busy TLS > server with ephemeral DH share reuse time < 1 sec.
hm, thinking about this optimization approach, i would really like to
know what implementations are doing this. It occurs to me that client
implementations as well as server implementations could be doing this
"for efficiency reasons".
If both sides do it, and two connections are established within the
window before the "ephemeral" keys are disposed of, then you could end
up in a scenario where you actually have a "Handshake Secret" and
"Master Secret" that are reused across a connection, and this would be
entirely observable by a passive monitor.
That leaves the only defense against direct key reuse for encryption on
the wire the entropy in:
* ClientHello and ServerHello (for
{client,server}_handshake_traffic_secret)
* ClientHello and server Finished (for
{client,server}_application_traffic_secret_0 and
exporter_master_secret)
* ClientHello and client Finished (for
resumption_master_secret)
Seems like risky business... we're leaning heavily on HKDF-Expand-Label
to keep a passive observer from being able to identify how the actual
traffic keys across sessions are related to one another. Or am i
missing something? I'd love for someone to correct me here.
Maybe i'll add a section to the draft explicitly forbidding clients from
ever taking this "optimization" step as well.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
