Re: [Sks-devel] ECC HTTPS certs for HKPS

[Pete Stephenson]

On Mon, Apr 3, 2017 at 8:45 AM, Kristian Fiskerstrand
<address@hidden> wrote:
> On April 2, 2017 9:10:10 PM GMT+02:00, Pete Stephenson <address@hidden> wrote:
>
>>
>>True, but RSA-4096 is *slow*. 3072 is a bit less so (but there's no
>>openssl speed option for testing it).
>>
>>My server, a cheap VPS at Scaleway, can only do 25.4 RSA-4096 private
>>key operations per second. It can do 192 RSA-2048 operations per
>>second.
>>
>>With ECC, it can do 2190 ECDSA P-256 signatures per second and 1430
>>P-384 signatures. It can do 1190 and 382 P-256 and P-384 ECDH key
>>exchanges per second, respectively.
>>
>>That said, it's not a huge concern at present, as during peak times my
>>server only handles 3-5 TLS connections/second. Still, it seems that
>>some clients are particularly heavy-use (in particular, some German
>>and Finnish IP addresses using a user-agent of "okhttp/3.5.0" --
>>anyone know what those are? Reverse DNS shows no particular clues:
>>some are DSL/cable connections, some are public hotspots, etc.) and
>>make periodic bursts of 10+ queries in a second, almost exclusively
>>for keys that don't exist. This means they're opening many
>>simultaneous, separate HTTPS connections with a fresh key exchange on
>>each. If they ramp up the number of connections they make (or there's
>>many new clients doing the same thing), this could pose scaling
>>problems.
>>
>>In the past there's been at least one corporate mail server that
>>queried the pool for each inbound email to see if the sender had a
>>public key. That caused a sustained increase in queries for a while,
>>but I don't see them anymore.
>>
>
>
> This part I find quite interesting to continue discussing,
>
> (i) it is likely of the more relevant as to whether to go ecc route.
> (ii) might raise question of need for setting minimum criteria for servers to 
> be added to hkps pool etc.
> (iii) changes to usage patterns and preparation for more traffic
>
> As for (iii) we might be able to meet by adding more servers to hkps pool to 
> get more distribution of load in addition to (ii) and (i) , but curious if 
> others have identified interesting behavior from certain clients.

Indeed. The load isn't a problem by any means, and the server is able
to handle the burst queries without issues. The load average of the
server is ~0.01, so it's extremely lightweight. The worst I can
foresee is that a huge burst of queries ends up with the server
getting a little slow processing the key exchanges and queries are
delayed by a few hundred milliseconds to a second or two. This
shouldn't be a huge deal for clients in most cases.

Still, it'd be nice for clients that know they're going to be doing
many queries (such as refreshing a whole keyring, or a gateway
expecting to do many queries) to use keep-alives to keep connections
alive for a few tens of seconds to minimize the number of new
connections and key exchanges. I don't think we have much control over
that, though.

> As for gateway solutions , as far as I'm aware at least Symantec Encryption 
> Server (former PGP Universal) only check LDAP (and not that either by 
> default), but peripdic keyyring refreshes etc is natural behavior/usage 
> anyways.

Interesting.

The systems I'm routinely seeing making bursts of queries seem to be
ordinary endpoints with dynamic IP addresses. They're not Tor exit
nodes, and essentially 100% of the queries they make result in a 404
response -- it doesn't seem like someone refreshing a keyring with
keys that are known to exist. They're all using the same user-agent
too.

I have zero problems with routine keyring refreshes, even large ones:
I have 200Mbps of unmetered bandwidth, and can easily scale the server
(or spin up other servers) on short notice to meet increasing demand.
I'm just curious as to what is causing this distinctive, strange
behavior.

-- 
Pete Stephenson