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

[Pete Stephenson]

")On Sun, Apr 2, 2017 at 6:07 PM, Kristian Fiskerstrand
<address@hidden> wrote:
> On 04/02/2017 06:00 PM, Pete Stephenson wrote:
>> Out of curiosity, how would it be less interoperable? The whole point
>> of having the server choose is so that clients that support ECC would
>> get ECC certs, while those that don't would get RSA certs. Servers
>> aren't going to send an ECC cert to a client that doesn't advertise
>> ECC support.
>
> Let me elaborate on this as it is indeed a fair comment. The argument
> would be that, if RSA should not be used but ECC should for some reason,
> we should rather switch to only use ECC and not do dual stack, the main
> purpose would be not to duplicate key management task, so picking
> between the two, using RSA is still more operable than ECC -- hence
> preference for staying with RSA unless there are convincing arguments to
> the contrary. The only argument I can think of offhand is performance on
> embedded devices an implementations that potentially is less prone to
> side-channel attacks, none of which I necessarily believe are strong
> arguments in this particular case of TLS access to keyservers.

True, using a single key type is definitely more convenient for key
management, but key issuance is a once-a-year thing for most servers
(modulo rekeying).

>> Also, what do you mean by "lower security margin"? 2048-bit RSA keys
>> are equivalent to an ~80 bit symmetric cipher. A 256-bit ECC key is
>> equivalent to a 128-bit symmetric cipher. Sure, RSA keys, due to their
>> greater length, will succumb to quantum computers later than the
>> shorter ECC keys, but is that a plausible threat at the moment?
>
> if this is a worry we could use 3072 bit rsa keys (many are already 4096
> bits) and yes, part of the thinking is the quantum computer resistance
> in that consideration.

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.

> But I'm really more curious to arguments to switching to ecc in general :)

A fair question. Better security with better performance is the main
reason for me. The fact that we already widely use ECC in the form of
ECDHE means we're already trusting in the math, so why not use ECDSA
as well?

On the other hand, using ECDHE gets one a big chunk of the performance
improvements already.

Cheers!
-Pete

-- 
Pete Stephenson