> What kind of load are we talking about?
~2500 full handshakes per sec, basic workstation HW.
> Which server implementation?
HTTP.SYS/IIS.
> If the amortization is spread across, say, all handshakes within 2 seconds,
> is the performance impact still significant?
In a specific quick test that I did, there was no significant perf impact with
key reuse time > 1 sec. And I could probably get it down to sub-seconds on my
HW. But HW specs differ between TLS servers; our current "ephemeral" key
lifetime is a generous 30 sec., mainly because we saw no reason to push for a
lower key lifetime.
> So it's conceivable that truly malicious servers would do this, of course,...
"Truly malicious" is perhaps an overstatement for this easy workaround
explicitly permitted by the "Enterprise TLS" spec:
"In some essential circumstances, the visibility information field may be
omitted."
Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
connections to "enterprise TLS" servers would probably qualify as "essential
circumstances", at least to some operators.
Cheers,
Andrei
-----Original Message-----
From: Daniel Kahn Gillmor <d...@fifthhorseman.net>
Sent: Thursday, December 6, 2018 12:25 PM
To: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org
Subject: RE: [TLS] ETSI releases standards for enterprise security and data
centre management
Hi Andrei--
On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will
> cost servers some perf:
>
> "Given the concerns in Section 2 and the necessary client mitigations
> in the subsections above, servers need to avoid giving the appearance
> of using non-ephemeral DH. Servers MUST NOT reuse ephemeral DH
> shares."
>
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.
interesting, i'd love to see more details on those tests if you can share them.
What kind of load are we talking about? Which server implementation?
The cost here is in the fixed-base operation, iiuc, which is the cheapest part
of the handshake -- DH share reuse allows you to skip this one step per
handshake (or rather, to amortize the one step across multiple handshakes).
You mention a cutoff of 1 second. If the amortization is spread across, say,
all handshakes within 2 seconds, is the performance impact still significant?
If the draft's server guidance were to be amended to suggest avoiding DH reuse
for more than 2 seconds, and the guidance for clients to track added a buffer
of 2 seconds before rejection, would that satisfy your concerns about
performance under load?
> Also, won't the "enterprise TLS" server just create a bunch of static
> DH shares and send different ones at different times, thereby avoiding
> detection by most clients?
I don't think that the intent of the ETSI spec is to encourage non-visible use.
They've specifically stated visibility to clients as a primary goal, and
acknoweldged that "Annex A" servers would be in violation of their own goals.
So it's conceivable that truly malicious servers would do this, of course, but
they might also just publish the master secret on twitter too, and the client
wouldn't know how to detect that inband either. But for the misbehavior that
we *can* detect in-band, a responsible client should be aware of it and avoid
it, right?
--dkg
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
