Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Andrei Popov <[e-mail]>]

> 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 <[e-mail]> 
Sent: Thursday, December 6, 2018 12:25 PM
To: Andrei Popov <[e-mail]>; [e-mail]
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