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

[Daniel Kahn Gillmor <[e-mail]>]

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